# HTTP Response Smuggling / Desync

{{#include ../banners/hacktricks-training.md}}

**Die Technik dieses Beitrags stammt aus dem Video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao&t=1343s)

## HTTP Request Queue Desynchronisation

Zunächst einmal **missbraucht diese Technik eine HTTP Request Smuggling-Schwachstelle**, daher müssen Sie wissen, was das ist:

Der **Hauptunterschied** zwischen dieser Technik und einem gängigen HTTP Request Smuggling besteht darin, dass wir **statt** die **Anfrage** des **Opfers** **durch Hinzufügen eines Präfixes anzugreifen**, die **Antwort, die das Opfer erhält, leaken oder modifizieren** werden. Dies geschieht, indem wir **anstatt 1,5 Anfragen zu senden, um das HTTP Request Smuggling auszunutzen, 2 vollständige Anfragen senden, um die Antwortwarteschlange der Proxys zu desynchronisieren**.

Das liegt daran, dass wir in der Lage sein werden, die **Antwortwarteschlange zu desynchronisieren**, sodass die **Antwort** der **legitimen** **Anfrage** des **Opfers an den Angreifer gesendet wird**, oder indem wir **Inhalte, die vom Angreifer kontrolliert werden, in die Antwort an das Opfer injizieren**.

### HTTP Pipeline Desync

HTTP/1.1 erlaubt es, **verschiedene Ressourcen anzufordern, ohne auf vorherige warten zu müssen**. Daher ist es die Aufgabe des **Proxys**, **eine synchronisierte Übereinstimmung von Anfragen, die an das Backend gesendet werden, und Antworten, die von ihm kommen, aufrechtzuerhalten**.

Es gibt jedoch ein Problem bei der Desynchronisation der Antwortwarteschlange. Wenn ein Angreifer einen HTTP Response Smuggling-Angriff sendet und die Antworten auf die **ursprüngliche Anfrage und die geschmuggelte sofort beantwortet werden**, wird die geschmuggelte Antwort nicht in die Warteschlange der Opferantwort eingefügt, sondern wird **einfach als Fehler verworfen**.

![](<../images/image (633).png>)

Daher ist es notwendig, dass die **geschmuggelte** **Anfrage** **länger benötigt, um verarbeitet zu werden**. Wenn die geschmuggelte Anfrage verarbeitet wird, wird die Kommunikation mit dem Angreifer beendet sein.

Wenn in dieser speziellen Situation ein **Opfer eine Anfrage gesendet hat** und die **geschmuggelte Anfrage vor** der legitimen Anfrage beantwortet wird, wird die **geschmuggelte Antwort an das Opfer gesendet**. Daher wird der Angreifer die **Anfrage "ausgeführt" vom Opfer kontrollieren**.

Darüber hinaus, wenn der **Angreifer dann eine Anfrage ausführt** und die **legitime Antwort** auf die **Anfrage des Opfers** **beantwortet** **wird**, **bevor** die Anfrage des Angreifers. Die **Antwort an das Opfer wird an den Angreifer gesendet**, **stiehlt** die Antwort an das Opfer (die beispielsweise den Header **Set-Cookie** enthalten kann).

![](<../images/image (1020).png>)

![](<../images/image (719).png>)

### Multiple Nested Injections

Ein weiterer **interessanter Unterschied** zu gängigem **HTTP Request Smuggling** besteht darin, dass das **Ziel** bei einem gängigen Smuggling-Angriff darin besteht, den **Beginn der Anfrage des Opfers zu modifizieren**, sodass sie eine unerwartete Aktion ausführt. Bei einem **HTTP Response Smuggling-Angriff**, da Sie **vollständige Anfragen senden**, können Sie **in einem Payload Dutzende von Antworten injizieren**, die **Dutzende von Benutzern desynchronisieren**, die die **injizierten** **Antworten** **erhalten**.

Neben der Möglichkeit, **Dutzende von Exploits leichter auf legitime Benutzer zu verteilen**, könnte dies auch verwendet werden, um einen **DoS** auf dem Server zu verursachen.

### Exploit Organisation

Wie zuvor erklärt, um diese Technik auszunutzen, ist es notwendig, dass die **erste geschmuggelte Nachricht** im Server **viel Zeit benötigt, um verarbeitet zu werden**.

Diese **zeitaufwendige Anfrage ist ausreichend**, wenn wir nur versuchen wollen, die Antwort des Opfers zu **stehlen**. Aber wenn Sie einen komplexeren Exploit durchführen möchten, wird dies eine gängige Struktur für den Exploit sein.

Zunächst die **initiale** Anfrage, die **HTTP** **Request** **Smuggling** missbraucht, dann die **zeitaufwendige Anfrage** und dann **1 oder mehr Payload-Anfragen**, deren Antworten an die Opfer gesendet werden.

## Missbrauch der HTTP Response Queue Desynchronisation

### Abfangen von Anfragen anderer Benutzer <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

Wie bei bekannten Payloads von HTTP Request Smuggling können Sie **die Anfrage des Opfers stehlen** mit einem wichtigen Unterschied: In diesem Fall müssen Sie nur den **gesendeten Inhalt reflektiert in der Antwort haben**, **keine persistente Speicherung** ist erforderlich.

Zunächst sendet der Angreifer ein Payload, das eine **abschließende POST-Anfrage mit dem reflektierten Parameter** am Ende und einer großen Content-Length enthält.

![](<../images/image (1053).png>)

Dann, sobald die **initiale Anfrage** (blau) **verarbeitet** wurde und **während** die **schlafende** verarbeitet wird (gelb), wird die **nächste Anfrage, die von einem Opfer eintrifft**, in die Warteschlange direkt nach dem reflektierten Parameter **angehängt**:

![](<../images/image (794).png>)

Dann wird das **Opfer** die **Antwort** auf die **schlafende** Anfrage erhalten und wenn in der Zwischenzeit der **Angreifer** **eine weitere** **Anfrage gesendet hat**, wird die **Antwort von der reflektierten Inhaltsanfrage an ihn gesendet**.

## Antwort Desynchronisation

Bis zu diesem Punkt haben wir gelernt, wie man HTTP Request Smuggling-Angriffe missbraucht, um die **Anfrage** zu **kontrollieren**, **deren** **Antwort** ein **Client** **erhalten** wird und wie Sie dann die **Antwort stehlen können, die für das Opfer bestimmt war**.

Aber es ist immer noch möglich, die Antworten **noch weiter zu desynchronisieren**.

Es gibt interessante Anfragen wie die **HEAD**-Anfrage, die spezifiziert, dass sie **keinen Inhalt im Antwortkörper** haben sollte und die **den Content-Length** der Anfrage wie **bei einer GET-Anfrage** **enthalten muss**.

Wenn ein Angreifer also eine **HEAD**-Anfrage **injiziert**, wie in diesen Bildern:

![](<../images/image (1107).png>)

Dann, **sobald die blaue beantwortet wird**, wird die nächste Anfrage des Opfers in die Warteschlange eingeführt:

![](<../images/image (999).png>)

Dann wird das **Opfer** die **Antwort** von der **HEAD**-Anfrage erhalten, die **einen Content-Length, aber keinen Inhalt enthält**. Daher wird der Proxy **diese Antwort nicht an das Opfer senden**, sondern **auf etwas **Inhalt** warten, der tatsächlich die **Antwort auf die gelbe Anfrage** (die ebenfalls vom Angreifer injiziert wurde) sein wird:

![](<../images/image (735).png>)

### Content Confusion

Folgendes Beispiel zeigt, dass Sie **den Körper** der Anfrage, deren Antwort das Opfer erhalten wird, **kontrollieren** können und dass eine **HEAD**-**Antwort** normalerweise in ihren Headern den **Content-Type und den Content-Length** enthält. Sie können **eine Anfrage wie die folgende** senden, um **XSS** im Opfer zu verursachen, ohne dass die Seite anfällig für XSS ist:

![](<../images/image (688).png>)

### Cache Poisoning

Wenn Sie den zuvor kommentierten Angriff zur Desynchronisation der Antwort Content Confusion missbrauchen, **wenn der Cache die Antwort auf die vom Opfer ausgeführte Anfrage speichert und diese Antwort eine injizierte ist, die ein XSS verursacht, dann ist der Cache vergiftet**.

Bösartige Anfrage, die das XSS-Payload enthält:

![](<../images/image (614).png>)

Bösartige Antwort an das Opfer, die den Header enthält, der dem Cache anzeigt, die Antwort zu speichern:

![](<../images/image (566).png>)

> [!WARNING]
> Beachten Sie, dass in diesem Fall, wenn das **"Opfer" der Angreifer ist**, er jetzt **Cache Poisoning in beliebigen URLs** durchführen kann, da er **die URL, die mit der bösartigen Antwort zwischengespeichert werden soll, kontrollieren kann**.

### Web Cache Deception

Dieser Angriff ist ähnlich wie der vorherige, aber **anstatt ein Payload im Cache zu injizieren, wird der Angreifer Informationen des Opfers im Cache speichern:**

![](<../images/image (991).png>)

### Response Splitting

Das **Ziel** dieses Angriffs ist es, erneut die **Antwort** **desynchronisation** auszunutzen, um **den Proxy dazu zu bringen, eine 100% vom Angreifer generierte Antwort zu senden**.

Um dies zu erreichen, muss der Angreifer einen Endpunkt der Webanwendung finden, der **einige Werte in der Antwort reflektiert** und **die Content-Length der HEAD-Antwort kennen**.

Er wird einen **Exploit** wie folgt senden:

![](<../images/image (911).png>)

Nachdem die erste Anfrage gelöst und an den Angreifer zurückgesendet wurde, wird die **Anfrage des Opfers in die Warteschlange eingefügt**:

![](<../images/image (737).png>)

Das Opfer erhält als Antwort die **HEAD-Antwort + den Inhalt der Antwort der zweiten Anfrage (die einen Teil der reflektierten Daten enthält):**

![](<../images/image (356).png>)

Beachten Sie jedoch, wie die **reflektierten Daten eine Größe gemäß dem Content-Length** der **HEAD**-Antwort hatten, die **eine gültige HTTP-Antwort in der Antwortwarteschlange erzeugte**.

Daher wird die **nächste Anfrage des zweiten Opfers** als **Antwort etwas erhalten, das vollständig vom Angreifer erstellt wurde**. Da die Antwort vollständig vom Angreifer erstellt wurde, kann er auch **den Proxy dazu bringen, die Antwort zu cachen**.

{{#include ../banners/hacktricks-training.md}}