# HTTP Response Smuggling / Desync

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

**Η τεχνική αυτού του άρθρου προήλθε από το βίντεο:** [**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 απάντηση δεν θα εισαχθεί μέσα στην ουρά της απάντησης του θύματος αλλά θα **απλώς απορριφθεί ως σφάλμα**.

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

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

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

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

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

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

### Multiple Nested Injections

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

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

### Exploit Organisation

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

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

Πρώτα απ' όλα το **αρχικό** αίτημα που καταχράται το **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.

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

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

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

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

## Response Desynchronisation

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

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

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

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

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

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

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

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

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

### Content Confusion

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

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

### Cache Poisoning

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

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

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

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

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

> [!WARNING]
> Σημειώστε ότι σε αυτή την περίπτωση αν ο **"θύμα" είναι ο επιτιθέμενος** μπορεί τώρα να εκτελέσει **δηλητηρίαση cache σε αυθαίρετες διευθύνσεις URL** καθώς μπορεί να **ελέγξει τη διεύθυνση URL που θα αποθηκευτεί στην cache** με την κακόβουλη απάντηση.

### Web Cache Deception

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

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

### Response Splitting

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

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

Θα στείλει ένα **exploit** όπως:

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

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

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

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

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

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

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

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