Specjalne nagłówki HTTP

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Słowniki i narzędzia

Nagłówki do zmiany lokalizacji

Przepisywanie źródła IP:

  • X-Originating-IP: 127.0.0.1
  • X-Forwarded-For: 127.0.0.1
  • X-Forwarded: 127.0.0.1
  • Forwarded-For: 127.0.0.1
  • X-Forwarded-Host: 127.0.0.1
  • X-Remote-IP: 127.0.0.1
  • X-Remote-Addr: 127.0.0.1
  • X-ProxyUser-Ip: 127.0.0.1
  • X-Original-URL: 127.0.0.1
  • Client-IP: 127.0.0.1
  • X-Client-IP: 127.0.0.1
  • X-Host: 127.0.0.1
  • True-Client-IP: 127.0.0.1
  • Cluster-Client-IP: 127.0.0.1
  • Via: 1.0 fred, 1.1 127.0.0.1
  • Connection: close, X-Forwarded-For (Sprawdź hop-by-hop headers)

Przepisywanie lokalizacji:

  • X-Original-URL: /admin/console
  • X-Rewrite-URL: /admin/console

Nagłówki hop-by-hop

Nagłówek hop-by-hop jest zaprojektowany do przetwarzania i konsumowania przez proxy, które aktualnie obsługuje żądanie, w przeciwieństwie do nagłówka end-to-end.

  • Connection: close, X-Forwarded-For

hop-by-hop headers

HTTP Request Smuggling

  • Content-Length: 30
  • Transfer-Encoding: chunked

HTTP Request Smuggling / HTTP Desync Attack

Nagłówek Expect

Możliwe jest, że klient wyśle nagłówek Expect: 100-continue, a serwer odpowie HTTP/1.1 100 Continue, pozwalając klientowi na dalsze wysłanie ciała żądania. Jednak niektóre proxy nie akceptują tego nagłówka.

Interesujące efekty stosowania Expect: 100-continue:

  • Wysłanie żądania HEAD z ciałem — serwer nie wziął pod uwagę, że HEAD nie powinien mieć ciała, i utrzymał połączenie otwarte aż do timeoutu.
  • Niektóre serwery wysyłały dziwne dane: losowe dane odczytane z socketu w odpowiedzi, klucze sekretne lub nawet pozwalały zapobiec usuwaniu wartości nagłówków przez front-end.
  • Spowodowało to także desynchronizację 0.CL, ponieważ backend odpowiedział 400 zamiast 100, ale front-end proxy był przygotowany do wysłania ciała pierwotnego żądania — wysłał je, a backend potraktował to jako nowe żądanie.
  • Wariant Expect: y 100-continue również spowodował desync 0.CL.
  • Podobny błąd, w którym backend odpowiedział 404, wygenerował desync CL.0, ponieważ złośliwe żądanie wskazywało Content-Length, więc backend wysłał złośliwe żądanie + Content-Length bajtów następnego żądania (ofiary). To desynchronizuje kolejkę: backend wysyła odpowiedź 404 dla złośliwego żądania + odpowiedź dla żądania ofiary, podczas gdy front-end myślał, że wysłano tylko 1 żądanie, więc druga odpowiedź trafia do innego klienta, itd.

Więcej informacji o HTTP Request Smuggling:

HTTP Request Smuggling / HTTP Desync Attack

Nagłówki cache

Nagłówki cache po stronie serwera:

  • X-Cache w odpowiedzi może mieć wartość miss gdy żądanie nie było w cache, oraz hit gdy było w cache
  • Podobne zachowanie w nagłówku Cf-Cache-Status
  • Cache-Control wskazuje, czy zasób jest cachowany i kiedy nastąpi następne odświeżenie: Cache-Control: public, max-age=1800
  • Vary jest często używany w odpowiedzi, aby wskazać dodatkowe nagłówki, które są traktowane jako część klucza cache, nawet jeśli normalnie nie są kluczowane.
  • Age definiuje czas w sekundach, przez jaki obiekt znajduje się w cache proxy.
  • Server-Timing: cdn-cache; desc=HIT również wskazuje, że zasób był w cache

Cache Poisoning and Cache Deception

Lokalne nagłówki cache:

  • Clear-Site-Data: Nagłówek wskazujący, które dane cache powinny zostać usunięte: Clear-Site-Data: "cache", "cookies"
  • Expires: Zawiera datę/czas, kiedy odpowiedź wygasa: Expires: Wed, 21 Oct 2015 07:28:00 GMT
  • Pragma: no-cache to samo co Cache-Control: no-cache
  • Warning: Ogólny nagłówek HTTP zawierający informacje o możliwych problemach ze statusem wiadomości. W odpowiedzi może wystąpić więcej niż jeden nagłówek Warning. Przykład: Warning: 110 anderson/1.3.37 "Response is stale"

Warunkowe zapytania

  • Żądania używające nagłówków If-Modified-Since i If-Unmodified-Since otrzymają dane tylko jeśli nagłówek odpowiedzi Last-Modified zawiera inną datę/czas.
  • Warunkowe żądania używające If-Match i If-None-Match korzystają z wartości Etag, więc serwer wyśle zawartość odpowiedzi jeśli dane (Etag) się zmieniły. Etag pochodzi z odpowiedzi HTTP.
  • Wartość Etag jest zazwyczaj obliczana na podstawie zawartości odpowiedzi. Na przykład ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" wskazuje, że Etag to Sha1 z 37 bajtów.

Range requests

  • Accept-Ranges: Wskazuje, czy serwer obsługuje żądania zakresowe i w jakich jednostkach można wyrazić zakres. Accept-Ranges: <range-unit>
  • Range: Określa część dokumentu, którą serwer powinien zwrócić. Na przykład Range:80-100 zwróci bajty 80 do 100 oryginalnej odpowiedzi ze statusem 206 Partial Content. Pamiętaj też, aby usunąć nagłówek Accept-Encoding z żądania.
  • Może to być użyteczne do uzyskania odpowiedzi z dowolnym odbitym kodem javascript, który w przeciwnym razie zostałby zescapowany. Aby to wykorzystać, trzeba by wstrzyknąć te nagłówki do żądania.
  • If-Range: Tworzy warunkowe żądanie zakresu, które jest realizowane tylko jeśli podany etag lub data zgadza się z zasobem zdalnym. Używane, aby zapobiec pobieraniu dwóch zakresów z niezgodnych wersji zasobu.
  • Content-Range: Wskazuje, gdzie w pełnym ciele wiadomości znajduje się fragment wiadomości częściowej.

Informacje o ciele wiadomości

  • Content-Length: Rozmiar zasobu, w dziesiętnych bajtach.
  • Content-Type: Wskazuje typ mediów zasobu
  • Content-Encoding: Używany do określenia algorytmu kompresji.
  • Content-Language: Opisuje język(i) przeznaczenia dla odbiorcy, co pozwala użytkownikowi rozróżnić według preferowanego języka.
  • Content-Location: Wskazuje alternatywną lokalizację dla zwracanych danych.

Z punktu widzenia pentest ten zestaw informacji jest zwykle “bezużyteczny”, ale jeśli zasób jest chroniony przez 401 lub 403 i uda Ci się znaleźć jakiś sposób, aby uzyskać te informacje, może to być interesujące.
Na przykład kombinacja Range i Etag w zapytaniu HEAD może leak zawartość strony za pomocą żądań HEAD:

  • Żądanie z nagłówkiem Range: bytes=20-20 i odpowiedzią zawierającą ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" powoduje leak informacji, że SHA1 bajtu 20 to ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y

Informacje o serwerze

  • Server: Apache/2.4.1 (Unix)
  • X-Powered-By: PHP/5.3.3

Kontrole

  • Allow: Ten nagłówek służy do komunikacji, jakich metod HTTP zasób potrafi obsłużyć. Na przykład może być określony jako Allow: GET, POST, HEAD, co wskazuje, że zasób obsługuje te metody.
  • Expect: Używany przez klienta do przekazania oczekiwań, które serwer musi spełnić, aby żądanie zostało przetworzone poprawnie. Typowy przypadek użycia to Expect: 100-continue, który sygnalizuje, że klient zamierza wysłać duży ładunek danych i oczekuje odpowiedzi 100 (Continue) przed kontynuacją. Mechanizm ten optymalizuje użycie sieci, oczekując potwierdzenia serwera.

Pobieranie

  • Nagłówek Content-Disposition w odpowiedziach HTTP wskazuje, czy plik powinien być wyświetlony jako inline (w obrębie strony) czy traktowany jako attachment (pobrany). Na przykład:
Content-Disposition: attachment; filename="filename.jpg"

To oznacza, że plik o nazwie “filename.jpg” ma zostać pobrany i zapisany.

Nagłówki bezpieczeństwa

Polityka bezpieczeństwa treści (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

Wymuszając Trusted Types poprzez CSP, aplikacje mogą być chronione przed atakami DOM XSS. Trusted Types zapewniają, że tylko specjalnie przygotowane obiekty, zgodne z ustalonymi politykami bezpieczeństwa, mogą być używane w niebezpiecznych wywołaniach API przeglądarki, dzięki czemu kod JavaScript jest domyślnie zabezpieczony.

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
});
}

// Assignment of raw strings is blocked, ensuring safety.
el.innerHTML = "some string" // Throws an exception.
const escaped = policy.createHTML("<img src=x onerror=alert(1)>")
el.innerHTML = escaped // Results in safe assignment.

X-Content-Type-Options

Ten nagłówek zapobiega automatycznemu wykrywaniu typu MIME, praktyce, która może prowadzić do podatności XSS. Zapewnia, że przeglądarki będą respektować typy MIME określone przez serwer.

X-Content-Type-Options: nosniff

X-Frame-Options

Aby przeciwdziałać clickjacking, ten nagłówek ogranicza, w jaki sposób dokumenty mogą być osadzane w <frame>, <iframe>, <embed> lub <object> oraz zaleca, by wszystkie dokumenty wyraźnie określały uprawnienia dotyczące osadzania.

X-Frame-Options: DENY

Cross-Origin Resource Policy (CORP) and Cross-Origin Resource Sharing (CORS)

CORP jest kluczowy dla określania, które zasoby mogą być ładowane przez strony internetowe, ograniczając cross-site leak. CORS natomiast umożliwia bardziej elastyczny mechanizm cross-origin resource sharing, rozluźniając same-origin policy w określonych warunkach.

Cross-Origin-Resource-Policy: same-origin
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Polityka osadzania międzyźródłowego (COEP) i Polityka otwierania międzyźródłowego (COOP)

COEP i COOP są niezbędne do włączenia izolacji międzyźródłowej, co znacząco zmniejsza ryzyko ataków podobnych do Spectre. Kontrolują odpowiednio ładowanie zasobów międzyźródłowych oraz interakcję z oknami międzyźródłowymi.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin-allow-popups

HTTP Strict Transport Security (HSTS)

Na koniec, HSTS to funkcja bezpieczeństwa, która wymusza, aby przeglądarki komunikowały się z serwerami wyłącznie za pomocą bezpiecznych połączeń HTTPS, tym samym zwiększając prywatność i bezpieczeństwo.

Strict-Transport-Security: max-age=3153600

Permissions-Policy (formerly Feature-Policy)

Permissions-Policy pozwala deweloperom stron selektywnie włączać, wyłączać lub modyfikować działanie niektórych funkcji przeglądarki i API w dokumencie. Jest następcą już przestarzałego nagłówka Feature-Policy. Ten nagłówek pomaga zmniejszyć powierzchnię ataku, ograniczając dostęp do potężnych funkcji, które mogłyby zostać nadużyte.

Permissions-Policy: geolocation=(), camera=(), microphone=()

Częste dyrektywy:

DyrektywaOpis
accelerometerKontroluje dostęp do sensora akcelerometru
cameraKontroluje dostęp do urządzeń wejścia wideo (kamerę internetową)
geolocationKontroluje dostęp do API geolokalizacji
gyroscopeKontroluje dostęp do czujnika żyroskopu
magnetometerKontroluje dostęp do magnetometru
microphoneKontroluje dostęp do urządzeń wejścia audio (mikrofonu)
paymentKontroluje dostęp do Payment Request API
usbKontroluje dostęp do WebUSB API
fullscreenKontroluje dostęp do Fullscreen API
autoplayKontroluje, czy media mogą odtwarzać się automatycznie
clipboard-readKontroluje dostęp do odczytu zawartości schowka
clipboard-writeKontroluje dostęp do zapisu do schowka

Wartości składni:

  • () - Wyłącza funkcję całkowicie
  • (self) - Pozwala na użycie funkcji tylko dla tego samego pochodzenia
  • * - Pozwala na użycie funkcji dla wszystkich pochodzeń
  • (self "https://example.com") - Pozwala dla tego samego pochodzenia i określonej domeny

Przykładowe konfiguracje:

# Restrictive policy - disable most features
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=()

# Allow camera only from same origin
Permissions-Policy: camera=(self)

# Allow geolocation for same origin and a trusted partner
Permissions-Policy: geolocation=(self "https://maps.example.com")

Z punktu widzenia bezpieczeństwa brak nagłówków Permissions-Policy lub ich nadmiernie pozwalające ustawienia mogą umożliwić atakującym (np. poprzez XSS lub osadzone iframes) nadużycie zaawansowanych funkcji przeglądarki. Zawsze ograniczaj uprawnienia do minimum niezbędnego dla aplikacji.

Obejście weryfikacji wielkości liter w nazwach nagłówków

HTTP/1.1 definiuje nazwy pól nagłówków jako niezależne od wielkości liter (RFC 9110 §5.1). Mimo to bardzo często spotyka się niestandardowe middleware, filtry bezpieczeństwa lub logikę biznesową, które porównują dosłowną otrzymaną nazwę nagłówka bez uprzedniego ujednolicenia wielkości liter (np. header.equals("CamelExecCommandExecutable")). Jeśli takie sprawdzenia są wykonywane z uwzględnieniem wielkości liter, atakujący może je obejść, wysyłając ten sam nagłówek z inną kapitalizacją.

Typical situations where this mistake appears:

  • Niestandardowe listy allow/deny, które próbują zablokować „niebezpieczne” nagłówki wewnętrzne zanim żądanie dotrze do wrażliwego komponentu.
  • Własne implementacje pseudo-nagłówków reverse-proxy (np. sanitizacja X-Forwarded-For).
  • Frameworki udostępniające endpointy zarządzania / debugowania i polegające na nazwach nagłówków przy uwierzytelnianiu lub wyborze komendy.

Wykorzystanie obejścia

  1. Zidentyfikuj nagłówek, który jest filtrowany lub walidowany po stronie serwera (np. przez analizę kodu źródłowego, dokumentacji lub komunikatów o błędach).
  2. Wyślij ten sam nagłówek z inną kapitalizacją (mieszane wielkości liter lub wielkie litery). Ponieważ stosy HTTP zwykle kanonizują nagłówki dopiero po wykonaniu kodu użytkownika, podatna weryfikacja może zostać pominięta.
  3. Jeśli komponent downstream traktuje nagłówki w sposób niezależny od wielkości liter (większość tak robi), przyjmie wartość kontrolowaną przez atakującego.

Przykład: Apache Camel exec RCE (CVE-2025-27636)

W podatnych wersjach Apache Camel trasy Command Center próbują blokować nieufne żądania przez usuwanie nagłówków CamelExecCommandExecutable i CamelExecCommandArgs. Porównanie było wykonywane za pomocą equals(), więc usuwane były tylko nagłówki o dokładnej kapitalizacji.

# Bypass the filter by using mixed-case header names and execute `ls /` on the host
curl "http://<IP>/command-center" \
-H "CAmelExecCommandExecutable: ls" \
-H "CAmelExecCommandArgs: /"

Nagłówki docierają do komponentu exec nieprzefiltrowane, skutkując remote command execution z uprawnieniami procesu Camel.

Wykrywanie i łagodzenie

  • Normalizuj wszystkie nazwy nagłówków do jednej wielkości liter (zazwyczaj małych liter) przed wykonywaniem porównań typu allow/deny.
  • Odrzuć podejrzane duplikaty: jeśli zarówno Header: jak i HeAdEr: są obecne, traktuj to jako anomalię.
  • Zastosuj pozytywną listę dozwolonych (allow-list) wymuszaną po kanonizacji.
  • Chroń endpointy zarządzania za pomocą uwierzytelniania i segmentacji sieci.

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks