mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
225 lines
13 KiB
Markdown
225 lines
13 KiB
Markdown
# Besondere HTTP-Header
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
## Wortlisten & Tools
|
||
|
||
- [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
|
||
- [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
|
||
|
||
## Header zur Änderung des Standorts
|
||
|
||
Ändern Sie **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` (Überprüfen Sie die Hop-by-Hop-Header)
|
||
|
||
Ändern Sie **Standort**:
|
||
|
||
- `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 ausgelegt ist, vom Proxy, der die Anfrage derzeit bearbeitet, verarbeitet und konsumiert zu werden, im Gegensatz zu einem End-to-End-Header.
|
||
|
||
- `Connection: close, X-Forwarded-For`
|
||
|
||
{{#ref}}
|
||
../../pentesting-web/abusing-hop-by-hop-headers.md
|
||
{{#endref}}
|
||
|
||
## HTTP-Anforderungs-Schmuggeln
|
||
|
||
- `Content-Length: 30`
|
||
- `Transfer-Encoding: chunked`
|
||
|
||
{{#ref}}
|
||
../../pentesting-web/http-request-smuggling/
|
||
{{#endref}}
|
||
|
||
## Cache-Header
|
||
|
||
**Server-Cache-Header**:
|
||
|
||
- **`X-Cache`** in der Antwort kann den Wert **`miss`** haben, wenn die Anfrage nicht im Cache war, und den Wert **`hit`**, wenn sie im Cache ist
|
||
- Ähnliches Verhalten im Header **`Cf-Cache-Status`**
|
||
- **`Cache-Control`** gibt an, ob eine Ressource im Cache gespeichert wird und wann die Ressource das nächste Mal wieder im Cache gespeichert wird: `Cache-Control: public, max-age=1800`
|
||
- **`Vary`** wird oft in der Antwort verwendet, um **zusätzliche Header** anzuzeigen, die als **Teil des Cache-Schlüssels** behandelt werden, auch wenn sie normalerweise nicht als Schlüssel verwendet 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 im Cache gespeichert wurde
|
||
|
||
{{#ref}}
|
||
../../pentesting-web/cache-deception/
|
||
{{#endref}}
|
||
|
||
**Lokale Cache-Header**:
|
||
|
||
- `Clear-Site-Data`: Header, um anzugeben, dass der Cache entfernt werden soll: `Clear-Site-Data: "cache", "cookies"`
|
||
- `Expires`: Enthält Datum/Uhrzeit, wann die Antwort ablaufen soll: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
|
||
- `Pragma: no-cache` dasselbe wie `Cache-Control: no-cache`
|
||
- `Warning`: Der **`Warning`** allgemeine HTTP-Header 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"`
|
||
|
||
## Bedingungen
|
||
|
||
- Anfragen, die diese Header verwenden: **`If-Modified-Since`** und **`If-Unmodified-Since`** werden nur mit Daten beantwortet, wenn der Antwortheader **`Last-Modified`** eine andere Zeit enthält.
|
||
- Bedingte Anfragen, die **`If-Match`** und **`If-None-Match`** verwenden, nutzen einen Etag-Wert, sodass der Webserver den Inhalt der Antwort sendet, wenn sich die Daten (Etag) geändert haben. Der `Etag` wird aus der HTTP-Antwort entnommen.
|
||
- Der **Etag**-Wert wird normalerweise **basierend auf dem Inhalt** der Antwort **berechnet**. Zum Beispiel zeigt `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` an, dass der `Etag` der **Sha1** von **37 Bytes** ist.
|
||
|
||
## Bereichsanfragen
|
||
|
||
- **`Accept-Ranges`**: Gibt an, ob der Server Bereichsanfragen unterstützt und, falls ja, in welcher Einheit der Bereich ausgedrückt werden kann. `Accept-Ranges: <range-unit>`
|
||
- **`Range`**: Gibt den Teil eines Dokuments an, den der Server zurückgeben soll. Zum Beispiel wird `Range:80-100` die Bytes 80 bis 100 der ursprünglichen Antwort mit einem Statuscode von 206 Partial Content zurückgeben. Denken Sie auch daran, den `Accept-Encoding`-Header aus der Anfrage zu entfernen.
|
||
- Dies könnte nützlich sein, um eine Antwort mit beliebigem reflektiertem JavaScript-Code zu erhalten, der sonst möglicherweise entkommen könnte. Um dies auszunutzen, müssten Sie jedoch diese Header in die Anfrage injizieren.
|
||
- **`If-Range`**: Erstellt eine bedingte Bereichsanfrage, die nur erfüllt wird, wenn der angegebene Etag oder das Datum mit der entfernten Ressource übereinstimmt. Wird verwendet, um das Herunterladen von zwei Bereichen aus inkompatiblen Versionen der Ressource zu verhindern.
|
||
- **`Content-Range`**: Gibt an, wo in einer vollständigen Nachrichtenkörpernachricht eine partielle Nachricht gehört.
|
||
|
||
## Informationen zum Nachrichtenkörper
|
||
|
||
- **`Content-Length`:** Die Größe der Ressource, in dezimalen Bytes.
|
||
- **`Content-Type`**: Gibt den Medientyp der Ressource an
|
||
- **`Content-Encoding`**: Wird verwendet, um den Komprimierungsalgorithmus anzugeben.
|
||
- **`Content-Language`**: Beschreibt die menschliche Sprache(n), die für das Publikum bestimmt sind, sodass es einem Benutzer ermöglicht, je nach bevorzugter Sprache des Benutzers zu unterscheiden.
|
||
- **`Content-Location`**: Gibt einen alternativen Standort für die zurückgegebenen Daten an.
|
||
|
||
Aus der Sicht eines Pentests sind diese Informationen normalerweise "nutzlos", aber wenn die Ressource **geschützt** ist durch eine 401 oder 403 und Sie einen **Weg** finden können, um diese **Info** zu **erhalten**, könnte dies **interessant** sein.\
|
||
Zum Beispiel kann eine Kombination aus **`Range`** und **`Etag`** in einer HEAD-Anfrage den Inhalt der Seite über HEAD-Anfragen leaken:
|
||
|
||
- 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 könnte er als `Allow: GET, POST, HEAD` angegeben werden, was darauf hinweist, dass die Ressource diese Methoden unterstützt.
|
||
- **`Expect`**: Wird vom Client verwendet, um Erwartungen zu übermitteln, die der Server erfüllen muss, damit die Anfrage erfolgreich verarbeitet werden kann. Ein häufiges Anwendungsbeispiel ist der Header `Expect: 100-continue`, der signalisiert, dass der Client beabsichtigt, eine große Datenmenge zu senden. Der Client wartet auf eine `100 (Continue)`-Antwort, bevor er mit der Übertragung fortfährt. Dieser Mechanismus hilft, die Netzwerknutzung zu optimieren, indem er auf die Bestätigung des Servers wartet.
|
||
|
||
## Downloads
|
||
|
||
- Der **`Content-Disposition`**-Header in HTTP-Antworten gibt an, ob eine Datei **inline** (innerhalb der Webseite) oder als **Anhang** (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 bestimmt ist.
|
||
|
||
## Sicherheitsheader
|
||
|
||
### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
|
||
|
||
{{#ref}}
|
||
../../pentesting-web/content-security-policy-csp-bypass/
|
||
{{#endref}}
|
||
|
||
### **Vertrauenswürdige Typen**
|
||
|
||
Durch die Durchsetzung von Vertrauenswürdigen Typen über CSP können Anwendungen vor DOM XSS-Angriffen geschützt werden. Vertrauenswürdige Typen stellen sicher, dass nur speziell gestaltete Objekte, die den festgelegten Sicherheitsrichtlinien entsprechen, in gefährlichen Web-API-Aufrufen verwendet werden können, wodurch JavaScript-Code standardmäßig gesichert wird.
|
||
```javascript
|
||
// Feature detection
|
||
if (window.trustedTypes && trustedTypes.createPolicy) {
|
||
// Name and create a policy
|
||
const policy = trustedTypes.createPolicy('escapePolicy', {
|
||
createHTML: str => str.replace(/\</g, '<').replace(/>/g, '>');
|
||
});
|
||
}
|
||
```
|
||
|
||
```javascript
|
||
// 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-Typ-Sniffing, eine Praxis, die zu XSS-Sicherheitsanfälligkeiten führen könnte. Er stellt sicher, dass Browser die vom Server angegebenen MIME-Typen respektieren.
|
||
```
|
||
X-Content-Type-Options: nosniff
|
||
```
|
||
### **X-Frame-Options**
|
||
|
||
Um Clickjacking zu bekämpfen, schränkt dieser Header ein, wie Dokumente in `<frame>`, `<iframe>`, `<embed>` oder `<object>`-Tags eingebettet werden können, und empfiehlt, dass alle Dokumente ihre Einbettungsberechtigungen ausdrücklich angeben.
|
||
```
|
||
X-Frame-Options: DENY
|
||
```
|
||
### **Cross-Origin Resource Policy (CORP) und Cross-Origin Resource Sharing (CORS)**
|
||
|
||
CORP ist entscheidend für die Festlegung, welche Ressourcen von Websites geladen werden können, um Cross-Site-Leaks zu mindern. CORS hingegen ermöglicht einen flexibleren Mechanismus für das Cross-Origin-Ressourcenteilung, der die Same-Origin-Policy unter bestimmten Bedingungen lockert.
|
||
```
|
||
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 für die Ermöglichung von Cross-Origin-Isolation und reduzieren erheblich das Risiko von Angriffen wie Spectre. Sie steuern 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)**
|
||
|
||
Zuletzt ist HSTS eine Sicherheitsfunktion, die Browser zwingt, nur über sichere HTTPS-Verbindungen mit Servern zu kommunizieren, wodurch die Privatsphäre und Sicherheit verbessert wird.
|
||
```
|
||
Strict-Transport-Security: max-age=3153600
|
||
```
|
||
## Header Name Casing Bypass
|
||
|
||
HTTP/1.1 definiert Headerfeldnamen als **groß-/kleinschreibungsempfindlich** (RFC 9110 §5.1). Dennoch ist es sehr häufig, benutzerdefinierte Middleware, Sicherheitsfilter oder Geschäftslogik zu finden, die den *wörtlichen* Headernamen vergleicht, ohne die Groß- und Kleinschreibung zuerst zu normalisieren (z. B. `header.equals("CamelExecCommandExecutable")`). Wenn diese Überprüfungen **groß-/kleinschreibungsempfindlich** durchgeführt werden, kann ein Angreifer sie einfach umgehen, indem er denselben Header mit einer anderen Großschreibung sendet.
|
||
|
||
Typische Situationen, in denen dieser Fehler auftritt:
|
||
|
||
* Benutzerdefinierte Erlauben/Verweigern-Listen, die versuchen, „gefährliche“ interne Header zu blockieren, bevor die Anfrage eine sensible Komponente erreicht.
|
||
* Interne Implementierungen von Reverse-Proxy-Pseudo-Headern (z. B. `X-Forwarded-For` Sanitierung).
|
||
* Frameworks, die Verwaltungs-/Debug-Endpunkte exponieren und auf Headernamen für Authentifizierung oder Befehlsauswahl angewiesen sind.
|
||
|
||
### Abusing the bypass
|
||
|
||
1. Identifizieren Sie einen Header, der serverseitig gefiltert oder validiert wird (zum Beispiel durch Lesen des Quellcodes, der Dokumentation oder von Fehlermeldungen).
|
||
2. Senden Sie den **gleichen Header mit einer anderen Großschreibung** (gemischte Groß- und Kleinschreibung oder Großbuchstaben). Da HTTP-Stacks Header normalerweise nur *nach* der Ausführung des Benutzercodes kanonisieren, kann die anfällige Überprüfung übersprungen werden.
|
||
3. Wenn die nachgelagerte Komponente Header groß-/kleinschreibungsempfindlich behandelt (die meisten tun dies), akzeptiert sie den vom Angreifer kontrollierten Wert.
|
||
|
||
### Beispiel: Apache Camel `exec` RCE (CVE-2025-27636)
|
||
|
||
In anfälligen Versionen von Apache Camel versuchen die *Command Center*-Routen, untrusted Anfragen zu blockieren, indem sie die Header `CamelExecCommandExecutable` und `CamelExecCommandArgs` entfernen. Der Vergleich wurde mit `equals()` durchgeführt, sodass nur die genauen Kleinbuchstabennamen entfernt wurden.
|
||
```bash
|
||
# 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 einer Remote-Befehlsausführung mit den Rechten des Camel-Prozesses führt.
|
||
|
||
### Erkennung & Minderung
|
||
|
||
* Normalisieren Sie alle Header-Namen auf einen einheitlichen Fall (in der Regel Kleinbuchstaben) **bevor** Sie Erlauben/Verweigern-Vergleiche durchführen.
|
||
* Ablehnen von verdächtigen Duplikaten: Wenn sowohl `Header:` als auch `HeAdEr:` vorhanden sind, behandeln Sie dies als Anomalie.
|
||
* Verwenden Sie eine positive Erlauben-Liste, die **nach** der Kanonisierung durchgesetzt wird.
|
||
* Schützen Sie Verwaltungsendpunkte mit Authentifizierung und Netzwerksegmentierung.
|
||
|
||
## Referenzen
|
||
|
||
- [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
|
||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
|
||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
|
||
- [https://web.dev/security-headers/](https://web.dev/security-headers/)
|
||
- [https://web.dev/articles/security-headers](https://web.dev/articles/security-headers)
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|