hacktricks/pentesting-web/http-response-smuggling-desync.md

# HTTP Response Smuggling / Desync

{% hint style="success" %}
Μάθετε & εξασκηθείτε στο AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Μάθετε & εξασκηθείτε στο GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Υποστήριξη HackTricks</summary>

* Ελέγξτε τα [**σχέδια συνδρομής**](https://github.com/sponsors/carlospolop)!
* **Εγγραφείτε στην** 💬 [**ομάδα Discord**](https://discord.gg/hRep4RUj7f) ή στην [**ομάδα telegram**](https://t.me/peass) ή **ακολουθήστε** μας στο **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα** [**HackTricks**](https://github.com/carlospolop/hacktricks) και [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}

**Η τεχνική αυτού του άρθρου προήλθε από το βίντεο:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)

## HTTP Request Queue Desynchronisation

Πρώτα απ' όλα, αυτή η τεχνική **καταχράται μια ευπάθεια HTTP Request Smuggling**, οπότε πρέπει να γνωρίζετε τι είναι αυτό:

Η **κύρια** **διαφορά** μεταξύ αυτής της τεχνικής και μιας κοινής HTTP Request smuggling είναι ότι **αντί** να **επιτίθεται** στο **αίτημα** του **θύματος** **προσθέτοντας ένα πρόθεμα σε αυτό**, θα **διαρρεύσουμε ή θα τροποποιήσουμε την απάντηση που λαμβάνει το θύμα**. Αυτό γίνεται στέλνοντας, αντί να στείλουμε 1 αίτημα και μισό για να καταχραστούμε το HTTP Request smuggling, **2 πλήρη αιτήματα για να αποσυγχρονίσουμε την ουρά απαντήσεων των proxies**.

Αυτό συμβαίνει επειδή θα μπορέσουμε να **αποσυγχρονίσουμε την ουρά απαντήσεων** έτσι ώστε η **απάντηση** από το **νόμιμο** **αίτημα** του **θύματος να σταλεί στον επιτιθέμενο**, ή **εισάγοντας περιεχόμενο που ελέγχεται από τον επιτιθέμενο στην απάντηση προς το θύμα**.

### HTTP Pipeline Desync

HTTP/1.1 επιτρέπει να ζητάμε **διαφορετικούς πόρους χωρίς να χρειάζεται να περιμένουμε για τους προηγούμενους**. Επομένως, αν υπάρχει ένας **proxy** στη **μέση**, είναι καθήκον του proxy να **διατηρεί μια συγχρονισμένη αντιστοίχιση των αιτημάτων που αποστέλλονται στο backend και των απαντήσεων που προέρχονται από αυτό**.

Ωστόσο, υπάρχει ένα πρόβλημα με την αποσυγχρονισμένη ουρά απαντήσεων. Αν ένας επιτιθέμενος στείλει μια επίθεση HTTP Response smuggling και οι απαντήσεις στο **αρχικό αίτημα και το smuggled** απαντηθούν αμέσως, η smuggled απάντηση δεν θα εισαχθεί μέσα στην ουρά της απάντησης του θύματος αλλά θα **απλώς απορριφθεί ως σφάλμα**.

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

Επομένως, είναι απαραίτητο το **smuggled** **αίτημα** **να χρειάζεται περισσότερο χρόνο για να επεξεργαστεί** μέσα στον backend server. Επομένως, μέχρι τη στιγμή που το smuggled αίτημα επεξεργάζεται, η επικοινωνία με τον επιτιθέμενο θα έχει τελειώσει.

Αν σε αυτή τη συγκεκριμένη κατάσταση ένα **θύμα έχει στείλει ένα αίτημα** και το **smuggled αίτημα απαντηθεί πριν** από το νόμιμο αίτημα, η **smuggled απάντηση θα σταλεί στο θύμα**. Επομένως, ο επιτιθέμενος θα **ελέγχει το αίτημα "που εκτελείται" από το θύμα**.

Επιπλέον, αν ο **επιτιθέμενος εκτελέσει στη συνέχεια ένα αίτημα** και η **νόμιμη απάντηση** στο **αίτημα** του **θύματος** **απαντηθεί** **πριν** από το αίτημα του επιτιθέμενου. Η **απάντηση στο θύμα θα σταλεί στον επιτιθέμενο**, **κλέβοντας** την απάντηση προς το θύμα (η οποία μπορεί να περιέχει για παράδειγμα την κεφαλίδα **Set-Cookie**).

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

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

### Multiple Nested Injections

Μια άλλη **ενδιαφέρουσα διαφορά** με την κοινή **HTTP Request Smuggling** είναι ότι, σε μια κοινή επίθεση smuggling, ο **στόχος** είναι να **τροποποιηθεί η αρχή του αιτήματος του θύματος** ώστε να εκτελέσει μια απροσδόκητη ενέργεια. Σε μια **HTTP Response smuggling επίθεση**, καθώς στέλνετε **πλήρη αιτήματα**, μπορείτε να **εισάγετε σε ένα payload δεκάδες απαντήσεις** που θα **αποσυγχρονίζουν δεκάδες χρήστες** που θα **λαμβάνουν** τις **εισαγμένες** **απαντήσεις**.

Εκτός από το ότι μπορείτε να **κατανείμετε πιο εύκολα δεκάδες exploits** σε νόμιμους χρήστες, αυτό θα μπορούσε επίσης να χρησιμοποιηθεί για να προκαλέσει μια **DoS** στον server.

### Exploit Organisation

Όπως εξηγήθηκε προηγουμένως, για να καταχραστείτε αυτή την τεχνική, είναι απαραίτητο το **πρώτο smuggled μήνυμα** προς τον server **να απαιτεί πολύ χρόνο για να επεξεργαστεί**.

Αυτή η **χρονικά απαιτητική αίτηση είναι αρκετή** αν θέλουμε απλώς να **προσπαθήσουμε να κλέψουμε την απάντηση του θύματος.** Αλλά αν θέλετε να εκτελέσετε μια πιο σύνθετη εκμετάλλευση, αυτή θα είναι μια κοινή δομή για την εκμετάλλευση.

Πρώτα απ' όλα το **αρχικό** αίτημα που καταχράται το **HTTP** **Request** **smuggling**, στη συνέχεια το **χρονικά απαιτητικό αίτημα** και μετά **1 ή περισσότερα payload αιτήματα** των οποίων οι απαντήσεις θα σταλούν στα θύματα.

## Abusing HTTP Response Queue Desynchronisation

### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

Όπως με τα γνωστά payloads HTTP Request Smuggling, μπορείτε να **κλέψετε το αίτημα του θύματος** με μια σημαντική διαφορά: Σε αυτή την περίπτωση χρειάζεστε απλώς το **περιεχόμενο που θα ανακλαστεί στην απάντηση**, **δεν απαιτείται μόνιμη αποθήκευση**.

Πρώτα, ο επιτιθέμενος στέλνει ένα payload που περιέχει ένα **τελικό POST αίτημα με την ανακλαστική παράμετρο** στο τέλος και μια μεγάλη Content-Length

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

Στη συνέχεια, μόλις το **αρχικό αίτημα** (μπλε) **επεξεργαστεί** και **ενώ** το **ύπνο** αίτημα επεξεργάζεται (κίτρινο), το **επόμενο αίτημα που φτάνει από ένα θύμα** θα **προστεθεί στην ουρά αμέσως μετά την ανακλαστική παράμετρο**:

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

Στη συνέχεια, το **θύμα** θα **λάβει** την **απάντηση στο ύπνο** αίτημα και αν εν τω μεταξύ ο **επιτιθέμενος** **έστειλε** **ένα άλλο** **αίτημα**, η **απάντηση από το αίτημα ανακλαστικού περιεχομένου θα σταλεί σε αυτόν**.

## Response Desynchronisation

Μέχρι αυτό το σημείο, έχουμε μάθει πώς να καταχραστούμε τις επιθέσεις HTTP Request Smuggling για να **ελέγξουμε** το **αίτημα** **του οποίου** **η απάντηση** θα **λάβει** ένας **πελάτης** και πώς μπορείτε στη συνέχεια να **κλέψετε την απάντηση που προοριζόταν για το θύμα**.

Αλλά είναι ακόμα δυνατό να **αποσυγχρονίσουμε ακόμα** περισσότερες απαντήσεις.

Υπάρχουν ενδιαφέροντα αιτήματα όπως το **HEAD** αίτημα που είναι καθορισμένα να μην έχουν **κανένα περιεχόμενο μέσα στο σώμα των απαντήσεων** και που θα πρέπει (πρέπει) να **περιέχουν την Content-Length** του αιτήματος όπως **αν ήταν ένα GET αίτημα**.

Επομένως, αν ένας επιτιθέμενος **εισάγει** ένα **HEAD** αίτημα, όπως στις παρακάτω εικόνες:

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

Στη συνέχεια, **μόλις το μπλε απαντηθεί στον επιτιθέμενο**, το επόμενο αίτημα του θύματος θα εισαχθεί στην ουρά:

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

Στη συνέχεια, το **θύμα** θα **λάβει** την **απάντηση** από το **HEAD** αίτημα, το οποίο **θα περιέχει μια Content-Length αλλά καθόλου περιεχόμενο**. Επομένως, ο proxy **δεν θα στείλει αυτή την απάντηση** στο θύμα, αλλά θα **περιμένει** για κάποιο **περιεχόμενο**, το οποίο στην πραγματικότητα θα είναι η **απάντηση στο κίτρινο αίτημα** (επίσης εισαχθέν από τον επιτιθέμενο):

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

### Content Confusion

Ακολουθώντας το προηγούμενο παράδειγμα, γνωρίζοντας ότι μπορείτε να **ελέγξετε το σώμα** του αιτήματος του οποίου η απάντηση θα λάβει το θύμα και ότι μια **HEAD** **απάντηση** συνήθως περιέχει στα headers της την **Content-Type και την Content-Length**, μπορείτε να **στείλετε ένα αίτημα όπως το παρακάτω** για να **προκαλέσετε XSS** στο θύμα χωρίς η σελίδα να είναι ευάλωτη σε XSS:

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

### Cache Poisoning

Καταχρώντας την προηγουμένως σχολιασμένη επίθεση αποσυγχρονισμού απάντησης Content Confusion, **αν η cache αποθηκεύει την απάντηση στο αίτημα που εκτελέστηκε από το θύμα και αυτή η απάντηση είναι μια εισαχθείσα που προκαλεί XSS, τότε η cache είναι δηλητηριασμένη**.

Κακόβουλο αίτημα που περιέχει το payload XSS:

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

Κακόβουλη απάντηση προς το θύμα που περιέχει την κεφαλίδα που υποδεικνύει στην cache να αποθηκεύσει την απάντηση:

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

{% hint style="warning" %}
Σημειώστε ότι σε αυτή την περίπτωση αν ο **"θύμα" είναι ο επιτιθέμενος** μπορεί τώρα να εκτελέσει **δηλητηρίαση cache σε αυθαίρετες διευθύνσεις URL** καθώς μπορεί να **ελέγξει τη διεύθυνση URL που θα αποθηκευτεί στην cache** με την κακόβουλη απάντηση.
{% endhint %}

### Web Cache Deception

Αυτή η επίθεση είναι παρόμοια με την προηγούμενη, αλλά **αντί να εισάγει ένα payload μέσα στην cache, ο επιτιθέμενος θα αποθηκεύει πληροφορίες του θύματος μέσα στην cache:**

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

### Response Splitting

Ο **στόχος** αυτής της επίθεσης είναι να καταχραστεί ξανά την **αποσυγχρονισμένη** **απάντηση** προκειμένου να **κάνει τον proxy να στείλει μια 100% απάντηση που έχει δημιουργηθεί από τον επιτιθέμενο**.

Για να το πετύχει αυτό, ο επιτιθέμενος πρέπει να βρει ένα endpoint της διαδικτυακής εφαρμογής που **αντικατοπτρίζει κάποιες τιμές μέσα στην απάντηση** και **να γνωρίζει την Content-Length της HEAD απάντησης**.

Θα στείλει μια **εκμετάλλευση** όπως:

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

Αφού το πρώτο αίτημα επιλυθεί και σταλεί πίσω στον επιτιθέμενο, το **αίτημα του θύματος προστίθεται στην ουρά**:

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

Το θύμα θα λάβει ως απάντηση την **HEAD απάντηση + το περιεχόμενο της δεύτερης απάντησης (που περιέχει μέρος των αντικατοπτριζόμενων δεδομένων):**

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

Ωστόσο, σημειώστε πώς τα **αντικατοπτριζόμενα δεδομένα είχαν μέγεθος σύμφωνα με την Content-Length** της **HEAD** απάντησης που **δημιούργησε μια έγκυρη HTTP απάντηση στην ουρά απαντήσεων**.

Επομένως, το **επόμενο αίτημα του δεύτερου θύματος** θα **λαμβάνει** ως **απάντηση κάτι εντελώς κατασκευασμένο από τον επιτιθέμενο**. Καθώς η απάντηση είναι εντελώς κατασκευασμένη από τον επιτιθέμενο, μπορεί επίσης να **κάνει τον proxy να αποθηκεύσει την απάντηση στην cache**.

{% hint style="success" %}
Μάθετε & εξασκηθείτε στο AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Μάθετε & εξασκηθείτε στο GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Υποστήριξη HackTricks</summary>

* Ελέγξτε τα [**σχέδια συνδρομής**](https://github.com/sponsors/carlospolop)!
* **Εγγραφείτε στην** 💬 [**ομάδα Discord**](https://discord.gg/hRep4RUj7f) ή στην [**ομάδα telegram**](https://t.me/peass) ή **ακολουθήστε** μας στο **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα** [**HackTricks**](https://github.com/carlospolop/hacktricks) και [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}