Spezielle HTTP-Header

Reading time: 12 minutes

Wortlisten & Tools

• https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers
• https://github.com/rfc-st/humble

Header zur Änderung des Ursprungs

Rewrite IP source:

• 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)

Rewrite 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 vorgesehen ist, vom Proxy, der gerade die Anfrage bearbeitet, verarbeitet und konsumiert zu werden — 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 das Fortsetzen des Sends des Request-Bodys zu erlauben. Einige Proxies mögen diesen Header jedoch nicht.

Interessante Ergebnisse von Expect: 100-continue:

• Senden einer HEAD-Anfrage mit einem Body: einige Server berücksichtigten nicht, dass HEAD-Anfragen keinen Body haben, und hielten die Verbindung offen, bis sie timeoute.
• Manche Server sendeten seltsame Daten zurück: zufällige Daten, die vom Socket gelesen wurden, geheime Schlüssel oder es erlaubte, dass Front-Ends bestimmte Header-Werte nicht entfernten.
• Es verursachte auch einen 0.CL-Desync, weil das Backend mit einer 400-Antwort statt mit 100 antwortete, das Proxy-Frontend aber bereits vorbereitet war, den Body der ursprünglichen Anfrage zu senden. Es schickte ihn; das Backend interpretierte ihn als neue Anfrage.
• Das Senden einer Variation wie Expect: y 100-continue führte ebenfalls zu einem 0.CL-Desync.
• Ein ähnlicher Fehler, bei dem das Backend mit einer 404 antwortete, erzeugte einen CL.0-Desync, weil die bösartige Anfrage eine Content-Length angab. Das Backend sendet die bösartige Anfrage plus die Content-Length Bytes der nächsten Anfrage (eines Opfers). Dadurch synchronisiert sich die Queue nicht mehr: Das Backend sendet die 404-Antwort für die bösartige Anfrage plus die Antwort der Opfer-Anfrage, das Frontend dachte jedoch, nur eine Antwort sei gesendet worden, sodass die zweite Antwort an einen anderen Empfänger geht usw.

Für mehr Infos zu HTTP Request Smuggling siehe:

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 den Wert hit, wenn sie gecached wurde.
• Ähnliches Verhalten beim Header Cf-Cache-Status.
• Cache-Control zeigt an, ob eine Ressource gecached wird und wann sie erneut gecached wird: 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, selbst wenn sie normalerweise nicht berücksichtigt werden.
• Age definiert die Zeit in Sekunden, die 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 entfernt werden sollen: Clear-Site-Data: "cache", "cookies"
• Expires: Enthält Datum/Uhrzeit, wann die Antwort verfallen soll: 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 erscheinen. Warning: 110 anderson/1.3.37 "Response is stale"

Konditionale Anfragen

• Anfragen mit diesen Headern: If-Modified-Since und If-Unmodified-Since werden nur dann mit Daten beantwortet, wenn der Response-Header Last-Modified eine abweichende Zeit enthält.
• Konditionale Anfragen mit If-Match und If-None-Match verwenden einen Etag-Wert, sodass der Webserver den Inhalt nur sendet, wenn sich die Daten (Etag) geändert haben. Der Etag stammt aus der HTTP-Antwort.
• Der Etag-Wert wird normalerweise auf Basis des Inhalts der Antwort berechnet. Zum Beispiel zeigt ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" an, 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 die 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 ursprünglichen Antwort mit dem Statuscode 206 Partial Content zurück. Entferne außerdem den Header Accept-Encoding aus der Anfrage.
• Das kann nützlich sein, um eine Antwort mit beliebigem reflektiertem JavaScript-Code zu erhalten, der sonst escaped würde. Um dies zu missbrauchen, musst du diese Header in die Anfrage injizieren.
• If-Range: Erstellt eine konditionale Range-Anfrage, die nur erfüllt wird, wenn der angegebene Etag oder das Datum mit der Remote-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 Teilabschnitt gehört.

Informationen zum Message-Body

• Content-Length: Die Größe der Ressource in dezimaler Anzahl von Bytes.
• Content-Type: Gibt den Medientyp der Ressource an.
• Content-Encoding: Wird verwendet, um den Kompressionsalgorithmus anzugeben.
• Content-Language: Beschreibt die menschliche(n) Sprache(n) für das Publikum, damit ein Benutzer nach seiner bevorzugten Sprache unterscheiden kann.
• Content-Location: Gibt einen alternativen Ort für die zurückgegebenen Daten an.

Aus pentest-Sicht sind diese Informationen normalerweise "nutzlos", aber wenn die Ressource durch einen 401 oder 403 geschützt ist und du irgendeinen Weg findest, diese Info zu bekommen, könnte 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 mit einer Antwort, die ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" enthält, leak't, 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 werden kann. Ein häufiges Beispiel ist der Header Expect: 100-continue, der signalisiert, dass der Client einen großen Payload senden will und auf eine 100 (Continue)-Antwort wartet, bevor er fortfährt. Dieser Mechanismus hilft, Netzwerkressourcen zu optimieren, indem auf die Bestätigung des Servers gewartet wird.

Downloads

• Der Content-Disposition-Header in HTTP-Antworten gibt an, 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" zum Herunterladen und Speichern vorgesehen ist.

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 erstellte Objekte, die den festgelegten Sicherheitsrichtlinien entsprechen, in gefährlichen Web-API-Aufrufen verwendet werden dürfen, wodurch JavaScript-Code standardmäßig geschützt 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 sorgt dafür, 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) and Cross-Origin Resource Sharing (CORS)

CORP ist entscheidend, um festzulegen, welche Ressourcen von Websites geladen werden dürfen, und mindert cross-site leaks. CORS hingegen ermöglicht einen flexibleren Mechanismus für cross-origin resource sharing 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 wesentlich, um Cross-Origin-Isolation zu ermöglichen, und reduzieren dadurch signifikant das Risiko von Spectre-ähnlichen Angriffen. Sie kontrollieren 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)

Schließlich ist HSTS eine Sicherheitsfunktion, die Browser dazu zwingt, nur über sichere HTTPS-Verbindungen mit Servern zu kommunizieren, und dadurch Datenschutz und Sicherheit erhöht.

Strict-Transport-Security: max-age=3153600

Header Name Casing Bypass

HTTP/1.1 definiert Header-Feldnamen als ohne Berücksichtigung der Groß-/Kleinschreibung (RFC 9110 §5.1). Dennoch ist es sehr verbreitet, dass benutzerdefinierte Middleware, Sicherheitsfilter oder Business-Logic den wörtlichen empfangenen Header-Namen vergleichen, ohne die Groß-/Kleinschreibung zuerst zu normalisieren (z. B. header.equals("CamelExecCommandExecutable")). Wenn diese Prüfungen groß-/kleinschreibungssensitiv 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:

• Benutzerdefinierte Allow/Deny-Listen, die versuchen, „gefährliche“ interne Header zu blockieren, bevor die Anfrage eine sensitive Komponente erreicht.
• Interne Implementierungen von reverse-proxy Pseudo-Headern (z. B. X-Forwarded-For-Sanitisierung).
• Frameworks, die Management-/Debug-Endpunkte exponieren und sich bei Authentifizierung oder Kommandoauswahl auf Header-Namen verlassen.

Umgehung ausnutzen

1. Identifiziere einen Header, der serverseitig gefiltert oder validiert wird (z. B. durch Lesen von Quellcode, Dokumentation oder Fehlermeldungen).
2. Sende den denselben Header mit anderer Groß-/Kleinschreibung (gemischte Schreibweise oder Großbuchstaben). Da HTTP-Stacks Header normalerweise erst nach der Ausführung von User-Code kanonisieren, kann die verwundbare Prüfung übersprungen werden.
3. Wenn die nachgelagerte Komponente Header ohne Berücksichtigung der Groß-/Kleinschreibung 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-Routes, nicht vertrauenswürdige Anfragen zu blockieren, indem sie die Header CamelExecCommandExecutable und CamelExecCommandArgs entfernen. Der Vergleich erfolgte mit equals(), sodass nur exakt übereinstimmende (case-sensitive) 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 erreichen die exec-Komponente ungefiltert, was zu remote command execution mit den Rechten des Camel-Prozesses führt.

Erkennung & Gegenmaßnahmen

• Normalisiere alle Header-Namen auf eine einheitliche Schreibweise (meistens lowercase) bevor allow/deny-Vergleiche durchgeführt werden.
• Verdächtige Duplikate ablehnen: wenn sowohl Header: als auch HeAdEr: vorhanden sind, behandle das als Anomalie.
• Verwende eine positive allow-list, die nach der canonicalisation durchgesetzt wird.
• Schütze Management-Endpunkte durch Authentifizierung und Netzwerksegmentierung.

Referenzen

• CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• https://web.dev/security-headers/
• https://web.dev/articles/security-headers