Spezielle HTTP-Header

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Wortlisten & Tools

Header zum Ändern der Location

Überschreibe die IP-Quelle:

  • 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 (Hop-by-hop-Header prüfen)

Überschreibe die Location:

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

Hop-by-Hop-Header

Ein Hop-by-hop-Header ist ein Header, der dafür gedacht ist, vom Proxy verarbeitet und konsumiert zu werden, der die Anfrage gerade behandelt — im Gegensatz zu einem End-to-End-Header.

  • Connection: close, X-Forwarded-For

hop-by-hop headers

HTTP Request Smuggling

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

HTTP Request Smuggling / HTTP Desync Attack

Der Expect-Header

Es ist möglich, dass der Client den Header Expect: 100-continue sendet und der Server mit HTTP/1.1 100 Continue antwortet, um dem Client zu erlauben, den Body der Anfrage weiterzuschicken. Einige Proxys mögen diesen Header jedoch nicht.

Interessante Effekte von Expect: 100-continue:

  • Versand einer HEAD-Anfrage mit Body: der Server berücksichtigt möglicherweise nicht, dass HEAD-Anfragen keinen Body haben, und hält die Verbindung offen, bis sie timeoutet.
  • Manche Server senden seltsame Daten zurück: zufällige Daten vom Socket in der Antwort, geheime Schlüssel oder es ermöglichte, dass der Frontend-Proxy Header-Werte nicht entfernte.
  • Es verursachte außerdem eine 0.CL Desynchronisation, weil das Backend mit einer 400-Antwort statt einer 100-Antwort geantwortet hat, aber der Proxy-Frontend war bereit, den Body der ursprünglichen Anfrage zu senden — also sendete es ihn und das Backend interpretiert ihn als neue Anfrage.
  • Das Senden einer Variation wie Expect: y 100-continue verursachte ebenfalls die 0.CL Desync.
  • Ein ähnlicher Fehler, bei dem das Backend mit einem 404 antwortete, erzeugte eine CL.0 Desync, weil die bösartige Anfrage eine Content-Length angab. Das Backend sendet die bösartige Anfrage + die Content-Length Bytes der nächsten Anfrage (eines Opfers), wodurch die Warteschlange desynchronisiert wird: das Backend sendet die 404-Antwort für die bösartige Anfrage + die Antwort der Opfer-Anfrage, aber das Frontend dachte, nur 1 Anfrage sei gesendet worden, sodass die zweite Antwort an einen zweiten Opfer-Request geschickt wird und die Antwort dieses Requests an den nächsten usw.

Mehr Infos zu HTTP Request Smuggling:

HTTP Request Smuggling / HTTP Desync Attack

Cache-Header

Server-Cache-Header:

  • X-Cache in der Antwort kann den Wert miss haben, wenn die Anfrage nicht gecached wurde, und hit wenn sie gecached ist.
  • Ähnliches Verhalten beim Header Cf-Cache-Status.
  • Cache-Control gibt an, ob eine Ressource gecached wird und wann sie das nächste Mal aus dem Cache kommt: Cache-Control: public, max-age=1800
  • Vary wird oft in der Antwort verwendet, um zusätzliche Header anzugeben, die als Teil des Cache-Keys behandelt werden, auch wenn sie normalerweise nicht berücksichtigt werden.
  • Age definiert die Zeit in Sekunden, wie lange das Objekt im Proxy-Cache war.
  • Server-Timing: cdn-cache; desc=HIT zeigt ebenfalls an, dass eine Ressource gecached wurde.

Cache Poisoning and Cache Deception

Lokale Cache-Header:

  • Clear-Site-Data: Header, um anzugeben, welche Caches gelöscht werden sollen: Clear-Site-Data: "cache", "cookies"
  • Expires: Enthält Datum/Uhrzeit, wann die Antwort abläuft: Expires: Wed, 21 Oct 2015 07:28:00 GMT
  • Pragma: no-cache entspricht Cache-Control: no-cache
  • Warning: Der allgemeine HTTP-Header Warning enthält Informationen über mögliche Probleme mit dem Status der Nachricht. Mehr als ein Warning-Header kann in einer Antwort vorkommen. Warning: 110 anderson/1.3.37 "Response is stale"

Conditionals

  • Anfragen mit diesen Headern: If-Modified-Since und If-Unmodified-Since werden nur dann mit Daten beantwortet, wenn der Response-Header Last-Modified eine andere Zeit enthält.
  • Bedingte Anfragen mit If-Match und If-None-Match verwenden einen ETag-Wert, sodass der Webserver den Inhalt nur sendet, wenn die Daten (ETag) sich geändert haben. Der Etag stammt aus der HTTP-Antwort.
  • Der Etag-Wert wird üblicherweise basierend auf dem Inhalt der Antwort berechnet. Zum Beispiel zeigt ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI", dass der Etag der Sha1 von 37 Bytes ist.

Range-Anfragen

  • Accept-Ranges: Gibt an, ob der Server Range-Anfragen unterstützt und in welcher Einheit der Range ausgedrückt werden kann. Accept-Ranges: <range-unit>
  • Range: Gibt den Teil eines Dokuments an, den der Server zurückgeben soll. Zum Beispiel gibt Range:80-100 die Bytes 80 bis 100 der Originalantwort mit dem Statuscode 206 Partial Content zurück. Entferne außerdem den Accept-Encoding-Header aus der Anfrage.
  • Das kann nützlich sein, um eine Antwort mit beliebigem reflektiertem JavaScript zu erhalten, das sonst escaped wäre. Um das zu missbrauchen, müsstest du diese Header in der Anfrage injizieren.
  • If-Range: Erstellt eine bedingte Range-Anfrage, die nur erfüllt wird, wenn der gegebene ETag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um zu verhindern, dass zwei Ranges von inkompatiblen Versionen der Ressource heruntergeladen werden.
  • Content-Range: Gibt an, wo in einer vollständigen Nachricht ein partieller Teil gehört.

Informationen zum Message-Body

  • Content-Length: Die Größe der Ressource in dezimalen Bytes.
  • Content-Type: Gibt den Medientyp der Ressource an.
  • Content-Encoding: Wird verwendet, um den Kompressionsalgorithmus anzugeben.
  • Content-Language: Beschreibt die menschliche Sprache(n), die für das Publikum vorgesehen sind, sodass Benutzer nach ihrer bevorzugten Sprache differenzieren können.
  • Content-Location: Gibt einen alternativen Ort für die zurückgegebenen Daten an.

Aus Sicht eines pentests sind diese Informationen normalerweise “nutzlos”, aber wenn die Ressource durch einen 401 oder 403 geschützt ist und du einen Weg findest, diese Info zu bekommen, kann das interessant sein.
Zum Beispiel kann eine Kombination aus Range und Etag in einer HEAD-Anfrage den Inhalt der Seite via HEAD-Anfragen leak-en:

  • Eine Anfrage mit dem Header Range: bytes=20-20 und einer Antwort, die ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" enthält, leakt, dass der SHA1 des Bytes 20 ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y ist.

Server-Info

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

Kontrollen

  • Allow: Dieser Header wird verwendet, um die HTTP-Methoden zu kommunizieren, die eine Ressource verarbeiten kann. Zum Beispiel kann Allow: GET, POST, HEAD angeben, dass die Ressource diese Methoden unterstützt.
  • Expect: Vom Client genutzt, um Erwartungen zu übermitteln, die der Server erfüllen muss, damit die Anfrage erfolgreich verarbeitet wird. Ein häufiger Anwendungsfall ist der Header Expect: 100-continue, der signalisiert, dass der Client einen großen Datenpayload senden will. Der Client wartet auf eine 100 (Continue)-Antwort, bevor er weitersendet. Dieser Mechanismus hilft, Netzwerkbandbreite zu optimieren, indem er die Bestätigung des Servers abwartet.

Downloads

  • Der Content-Disposition-Header in HTTP-Antworten legt fest, ob eine Datei inline (innerhalb der Webseite) angezeigt oder als attachment (heruntergeladen) behandelt werden soll. Zum Beispiel:
Content-Disposition: attachment; filename="filename.jpg"

Das bedeutet, dass die Datei mit dem Namen “filename.jpg” heruntergeladen und gespeichert werden soll.

Sicherheits-Header

Content Security Policy (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

Durch das Erzwingen von Trusted Types über CSP können Anwendungen gegen DOM-XSS-Angriffe geschützt werden. Trusted Types stellen sicher, dass nur speziell konstruierte Objekte, die mit den festgelegten Sicherheitsrichtlinien übereinstimmen, in gefährlichen Web-API-Aufrufen verwendet werden dürfen, wodurch JavaScript-Code standardmäßig abgesichert wird.

// 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

Dieser Header verhindert MIME Type Sniffing, eine Praxis, die zu XSS-Schwachstellen führen kann. Er stellt sicher, dass Browser die vom Server angegebenen MIME-Typen respektieren.

X-Content-Type-Options: nosniff

X-Frame-Options

Um Clickjacking zu verhindern, beschränkt dieser Header, wie Dokumente in <frame>, <iframe>, <embed> oder <object>-Tags eingebettet werden können, und empfiehlt, dass alle Dokumente ihre Einbettungsberechtigungen explizit angeben.

X-Frame-Options: DENY

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

CORP ist entscheidend, um festzulegen, welche Ressourcen von Websites geladen werden dürfen und vermindert cross-site leaks. CORS hingegen erlaubt einen flexibleren cross-origin resource sharing‑Mechanismus und lockert die same-origin policy unter bestimmten Bedingungen.

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

Cross-Origin Embedder Policy (COEP) und Cross-Origin Opener Policy (COOP)

COEP und COOP sind entscheidend, um Cross-Origin-Isolation zu ermöglichen und reduzieren dadurch deutlich das Risiko von Spectre-ähnlichen Angriffen. Sie steuern jeweils das Laden von Cross-Origin-Ressourcen und die Interaktion mit Cross-Origin-Fenstern.

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

HTTP Strict Transport Security (HSTS)

Abschließend ist HSTS eine Sicherheitsfunktion, die Browser dazu zwingt, nur über sichere HTTPS‑Verbindungen mit Servern zu kommunizieren, und dadurch die Privatsphäre und Sicherheit erhöht.

Strict-Transport-Security: max-age=3153600

Permissions-Policy (formerly Feature-Policy)

Permissions-Policy erlaubt Webentwicklern, bestimmte Browser-Funktionen und APIs innerhalb eines Dokuments selektiv zu aktivieren, zu deaktivieren oder ihr Verhalten zu ändern. Es ist der Nachfolger des inzwischen veralteten Feature-Policy-Headers. Dieser Header hilft, die Angriffsfläche zu reduzieren, indem er den Zugriff auf mächtige Funktionen einschränkt, die missbraucht werden könnten.

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

Gängige Direktiven:

DirektiveBeschreibung
accelerometerSteuert den Zugriff auf den Beschleunigungssensor
cameraSteuert den Zugriff auf Videoeingabegeräte (Webcam)
geolocationSteuert den Zugriff auf die Geolocation-API
gyroscopeSteuert den Zugriff auf den Gyroskop-Sensor
magnetometerSteuert den Zugriff auf den Magnetometer-Sensor
microphoneSteuert den Zugriff auf Audioeingabegeräte
paymentSteuert den Zugriff auf die Payment Request API
usbSteuert den Zugriff auf die WebUSB-API
fullscreenSteuert den Zugriff auf die Fullscreen-API
autoplaySteuert, ob Medien automatisch abgespielt werden können
clipboard-readSteuert den Zugriff zum Lesen des Inhalts der Zwischenablage
clipboard-writeSteuert den Zugriff zum Schreiben in die Zwischenablage

Syntaxwerte:

  • () - Deaktiviert die Funktion vollständig
  • (self) - Erlaubt die Funktion nur für dieselbe Origin
  • * - Erlaubt die Funktion für alle Ursprünge
  • (self "https://example.com") - Erlaubt für dieselbe Origin und die angegebene Domain

Beispielkonfigurationen:

# 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")

Aus Sicht der Sicherheit können fehlende oder zu großzügige Permissions-Policy-Header Angreifern (z. B. durch XSS oder eingebettete iframes) erlauben, mächtige Browser-Funktionen zu missbrauchen. Beschränken Sie Features stets auf das für Ihre Anwendung notwendige Minimum.

Umgehung durch Groß-/Kleinschreibung von Header-Namen

HTTP/1.1 definiert Header-Feldnamen als case-insensitive (RFC 9110 §5.1). Trotzdem findet man sehr häufig custom middleware, security filters oder Business-Logik, die den literalen empfangenen Header-Namen vergleichen, ohne die Groß-/Kleinschreibung vorher zu normalisieren (z. B. header.equals("CamelExecCommandExecutable")). Wenn diese Prüfungen case-sensitiv durchgeführt werden, kann ein Angreifer sie einfach umgehen, indem er denselben Header mit anderer Groß-/Kleinschreibung sendet.

Typische Situationen, in denen dieser Fehler auftritt:

  • Eigene Allow-/Deny-Listen, die versuchen, „gefährliche“ interne Header zu blockieren, bevor die Anfrage eine sensitive Komponente erreicht.
  • In-house-Implementierungen von reverse-proxy pseudo-headers (z. B. X-Forwarded-For Sanitisierung).
  • Frameworks, die Management-/Debug-Endpunkte exponieren und sich auf Header-Namen zur Authentifizierung oder zur Auswahl von Befehlen verlassen.

Ausnutzen der Umgehung

  1. Identifizieren Sie einen Header, der serverseitig gefiltert oder validiert wird (z. B. durch Lesen von Quellcode, Dokumentation oder Fehlermeldungen).
  2. Senden Sie den gleichen Header mit anderer Groß-/Kleinschreibung (mixed-case oder upper-case). Da HTTP-Stacks Header üblicherweise erst nachdem benutzerdefinierter Code ausgeführt wurde normalisieren, kann die verwundbare Prüfung umgangen werden.
  3. Wenn die nachgelagerte Komponente Header case-insensitiv behandelt (die meisten tun das), akzeptiert sie den vom Angreifer kontrollierten Wert.

Beispiel: Apache Camel exec RCE (CVE-2025-27636)

In verwundbaren Versionen von Apache Camel versuchen die Command Center-Routen, nicht vertrauenswürdige Anfragen zu blockieren, indem sie die Header CamelExecCommandExecutable und CamelExecCommandArgs entfernen. Der Vergleich erfolgte mit equals(), sodass nur die exakt kleingeschriebenen Namen entfernt wurden.

# 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: /"

Die Header gelangen ungefiltert zur exec-Komponente, was zu remote command execution mit den Rechten des Camel-Prozesses führt.

Erkennung & Gegenmaßnahmen

  • Normalisieren Sie alle Header-Namen auf eine einheitliche Schreibweise (meist lowercase) bevor Sie Allow/Deny-Vergleiche durchführen.
  • Verdächtige Duplikate ablehnen: wenn sowohl Header: als auch HeAdEr: vorhanden sind, behandeln Sie dies als Anomalie.
  • Verwenden Sie eine positive allow-list, die nach der canonicalisation durchgesetzt wird.
  • Schützen Sie Management-Endpunkte durch Authentifizierung und Netzwerksegmentierung.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks