diff --git a/src/network-services-pentesting/pentesting-web/special-http-headers.md b/src/network-services-pentesting/pentesting-web/special-http-headers.md index bb31f1267..450baa481 100644 --- a/src/network-services-pentesting/pentesting-web/special-http-headers.md +++ b/src/network-services-pentesting/pentesting-web/special-http-headers.md @@ -1,4 +1,4 @@ -# Besondere HTTP-Header +# Spezielle HTTP-Header {{#include ../../banners/hacktricks-training.md}} @@ -7,9 +7,9 @@ - [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 +## Header zur Änderung des Ursprungs -Ändern Sie **IP-Quelle**: +Rewrite **IP source**: - `X-Originating-IP: 127.0.0.1` - `X-Forwarded-For: 127.0.0.1` @@ -26,42 +26,63 @@ - `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) +- `Connection: close, X-Forwarded-For` (Hop-by-Hop-Header prüfen) -Ändern Sie **Standort**: +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 ausgelegt ist, vom Proxy, der die Anfrage derzeit bearbeitet, verarbeitet und konsumiert zu werden, im Gegensatz zu einem End-to-End-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` + {{#ref}} ../../pentesting-web/abusing-hop-by-hop-headers.md {{#endref}} -## HTTP-Anforderungs-Schmuggeln +## HTTP Request Smuggling - `Content-Length: 30` - `Transfer-Encoding: chunked` + {{#ref}} ../../pentesting-web/http-request-smuggling/ {{#endref}} +## 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: + +{{#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. +- **`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 im Cache gespeichert wurde +- **`Server-Timing: cdn-cache; desc=HIT`** zeigt ebenfalls an, dass eine Ressource gecached wurde. + {{#ref}} ../../pentesting-web/cache-deception/ @@ -69,37 +90,37 @@ Ein Hop-by-Hop-Header ist ein Header, der dafür ausgelegt ist, vom Proxy, der d **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"` +- `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"` -## Bedingungen +## Konditionale Anfragen -- 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. +- 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. -## Bereichsanfragen +## Range-Anfragen -- **`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`**: 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. +- **`Accept-Ranges`**: Gibt an, ob der Server Range-Anfragen unterstützt und in welcher Einheit die Range ausgedrückt werden kann. `Accept-Ranges: ` +- **`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 Nachrichtenkörper +## 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 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. +- **`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 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: +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 einer Antwort, die `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` enthält, leakt, dass der SHA1 des Bytes 20 `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` ist. +- 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 @@ -108,28 +129,29 @@ Zum Beispiel kann eine Kombination aus **`Range`** und **`Etag`** in einer HEAD- ## 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. +- **`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) oder als **Anhang** (heruntergeladen) behandelt werden soll. Zum Beispiel: +- 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 bestimmt ist. +Das bedeutet, dass die Datei mit dem Namen "filename.jpg" zum Herunterladen und Speichern vorgesehen ist. -## Sicherheitsheader +## Sicherheits-Header ### Content Security Policy (CSP) + {{#ref}} ../../pentesting-web/content-security-policy-csp-bypass/ {{#endref}} -### **Vertrauenswürdige Typen** +### **Trusted Types** -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. +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. ```javascript // Feature detection if (window.trustedTypes && trustedTypes.createPolicy) { @@ -148,19 +170,19 @@ 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. +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 bekämpfen, schränkt dieser Header ein, wie Dokumente in ``, `