Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Αυτή η ευπάθεια συμβαίνει όταν μια **αποσυγχρονισμένη** κατάσταση μεταξύ των **προξενικών διακομιστών** και του **διακομιστή** back-end επιτρέπει σε έναν **επιτιθέμενο**να**στείλει** ένα HTTP **αίτημα** που θα **ερμηνευθεί** ως **ένα μόνο αίτημα** από τους **προξενικούς διακομιστές** (load balance/reverse-proxy) και **ως 2 αιτήματα** από τον **διακομιστή** back-end.\
Αυτό επιτρέπει σε έναν χρήστη να**τροποποιήσει το επόμενο αίτημα που φτάνει στον διακομιστή back-end μετά το δικό του**.
Οι**Front-End** (ένα load-balance / Reverse Proxy) **επεξεργάζονται** την κεφαλίδα _**content-length**_ ή την κεφαλίδα _**transfer-encoding**_ και ο**Back-end** διακομιστής **επεξεργάζεται την άλλη** προκαλώντας μια **αποσυγχρονισμένη** κατάσταση μεταξύ των 2 συστημάτων.\
Αυτό θα μπορούσε να είναι πολύ κρίσιμο καθώς **ένας επιτιθέμενος θα είναι σε θέση να στείλει ένα αίτημα** στον reverse proxy που θα **ερμηνευθεί** από τον **back-end** διακομιστή **ως 2 διαφορετικά αιτήματα**. Ο**κίνδυνος** αυτής της τεχνικής έγκειται στο γεγονός ότι ο**back-end** διακομιστής **θα ερμηνεύσει** το **2ο αίτημα που εισάγεται**σαννα**προήλθε από τον επόμενο πελάτη** και το **πραγματικό αίτημα** αυτού του πελάτη θα είναι **μέρος** του **εισαγμένου αιτήματος**.
* **Content-Length**: Αυτή η κεφαλίδα χρησιμοποιεί έναν **δεκαδικό αριθμό**γιανα υποδείξει τον **αριθμό** των **bytes** του **σώματος** του αιτήματος. Το σώμα αναμένεται να τελειώνει στον τελευταίο χαρακτήρα, **μια νέα γραμμή δεν είναι απαραίτητη στο τέλος του αιτήματος**.
* **Transfer-Encoding:** Αυτή η κεφαλίδα χρησιμοποιεί στο **σώμα** έναν **εξαδικό αριθμό**γιανα υποδείξει τον **αριθμό** των **bytes** του **επόμενου κομματιού**. Το**κομμάτι** πρέπει να**τελειώνει** με μια **νέα γραμμή** αλλά αυτή η νέα γραμμή **δεν μετράται** από τον δείκτη μήκους. Αυτή η μέθοδος μεταφοράς πρέπει να τελειώνει με ένα **κομμάτι μεγέθους 0 ακολουθούμενο από 2 νέες γραμμές**: `0`
* **Connection**: Βασισμένο στην εμπειρία μου, συνιστάται να χρησιμοποιείτε **`Connection: keep-alive`** στο πρώτο αίτημα του request Smuggling.
Όταν προσπαθείτε να εκμεταλλευτείτε αυτό με το Burp Suite **απενεργοποιήστε το `Update Content-Length` και `Normalize HTTP/1 line endings`** στον επαναλήπτη γιατί ορισμένα gadgets εκμεταλλεύονται τις νέες γραμμές, τις επιστροφές καροτσιού και τα κακώς διαμορφωμένα content-lengths.
Οι επιθέσεις HTTP request smuggling κατασκευάζονται στέλνοντας ασαφή αιτήματα που εκμεταλλεύονται τις διαφορές στον τρόπο που οι προξενικοί και οι διακομιστές back-end ερμηνεύουν τις κεφαλίδες `Content-Length` (CL) και `Transfer-Encoding` (TE). Αυτές οι επιθέσεις μπορούν να εκδηλωθούν σε διάφορες μορφές, κυρίως ως **CL.TE**, **TE.CL**, και **TE.TE**. Κάθε τύπος αντιπροσωπεύει έναν μοναδικό συνδυασμό του πώς οι προξενικοί και οι διακομιστές back-end δίνουν προτεραιότητα σε αυτές τις κεφαλίδες. Οι ευπάθειες προκύπτουν από την επεξεργασία του ίδιου αιτήματος από τους διακομιστές με διαφορετικούς τρόπους, οδηγώντας σε απροσδόκητα και δυνητικά κακόβουλα αποτελέσματα.
*Ο προξενικός διακομιστής προωθεί ολόκληρο το αίτημα στον back-end, με βάση την τιμή `Content-Length`.
*Ο διακομιστής back-end επεξεργάζεται το αίτημα ως κομματιασμένο λόγω της κεφαλίδας `Transfer-Encoding: chunked`, ερμηνεύοντας τα υπόλοιπα δεδομένα ως ένα ξεχωριστό, επόμενο αίτημα.
***Παράδειγμα:**
```
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 Ευπάθεια (Transfer-Encoding χρησιμοποιείται από Front-End, Content-Length χρησιμοποιείται από Back-End)
* **Front-End (TE):** Επεξεργάζεται το αίτημα με βάση την κεφαλίδα `Transfer-Encoding`.
* **Back-End (CL):** Επεξεργάζεται το αίτημα με βάση την κεφαλίδα `Content-Length`.
* **Σενάριο Επίθεσης:**
*Ο επιτιθέμενος στέλνει ένα κομματιασμένο αίτημα όπου το μέγεθος του κομματιού (`7b`) και το πραγματικό μήκος περιεχομένου (`Content-Length: 4`) δεν ευθυγραμμίζονται.
*Ο προξενικός διακομιστής, τιμώντας το `Transfer-Encoding`, προωθεί ολόκληρο το αίτημα στον back-end.
*Ο διακομιστής back-end, σεβόμενος το `Content-Length`, επεξεργάζεται μόνο το αρχικό μέρος του αιτήματος (`7b` bytes), αφήνοντας το υπόλοιπο ως μέρος ενός μη προγραμματισμένου επόμενου αιτήματος.
***Παράδειγμα:**
```
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 Ευπάθεια (Transfer-Encoding χρησιμοποιείται και από τους δύο, με παραπλάνηση)
* Αναφέρεται σε σενάρια όπου η κεφαλίδα `Content-Length` είναι παρούσα και έχει τιμή διαφορετική από το μηδέν, υποδεικνύοντας ότι το σώμα του αιτήματος έχει περιεχόμενο.
* Είναι κρίσιμο στην κατανόηση και την κατασκευή επιθέσεων smuggling, καθώς επηρεάζει το πώς οι διακομιστές καθορίζουν το τέλος ενός αιτήματος.
Αυτή η τεχνική είναι επίσης χρήσιμη σε σενάρια όπου είναι δυνατόν να**σπάσει ένας διακομιστής ιστού ενώ διαβάζει τα αρχικά δεδομένα HTTP** αλλά **χωρίς να κλείσει τη σύνδεση**. Με αυτόν τον τρόπο, το **σώμα** του HTTP αιτήματος θα θεωρείται το **επόμενο HTTP αίτημα**.
Για παράδειγμα, όπως εξηγείται σε [**αυτή τη γραφή**](https://mizu.re/post/twisty-python), στο Werkzeug ήταν δυνατό να σταλούν μερικοί **Unicode** χαρακτήρες και αυτό θα έκανε τον διακομιστή να**σπάσει**. Ωστόσο, εάν η σύνδεση HTTP δημιουργήθηκε με την κεφαλίδα **`Connection: keep-alive`**, το σώμα του αιτήματος δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, έτσι το **σώμα** του αιτήματος θα αντιμετωπιστεί ως το **επόμενο HTTP αίτημα**.
Εκμεταλλευόμενοι τις κεφαλίδες hop-by-hop μπορείτε να υποδείξετε στον proxy να**διαγράψει την κεφαλίδα Content-Length ή Transfer-Encoding ώστε να είναι δυνατή η εκμετάλλευση του HTTP request smuggling**.
Η αναγνώριση ευπαθειών HTTP request smuggling μπορεί συχνά να επιτευχθεί χρησιμοποιώντας τεχνικές χρονομέτρησης, οι οποίες βασίζονται στην παρατήρηση του πόσο χρόνο χρειάζεται ο διακομιστής γιανα απαντήσει σε παραποιημένα αιτήματα. Αυτές οι τεχνικές είναι ιδιαίτερα χρήσιμες για την ανίχνευση ευπαθειών CL.TE και TE.CL. Εκτός από αυτές τις μεθόδους, υπάρχουν άλλες στρατηγικές και εργαλεία που μπορούν να χρησιμοποιηθούν γιανα βρουν τέτοιες ευπάθειες:
*Ο διακομιστής front-end επεξεργάζεται το αίτημα με βάση το `Transfer-Encoding` και προωθεί ολόκληρο το μήνυμα.
*Ο διακομιστής back-end, περιμένοντας ένα μήνυμα με βάση το `Content-Length`, περιμένει επιπλέον δεδομένα που ποτέ δεν φτάνουν, προκαλώντας καθυστέρηση.
### Άλλες Μέθοδοι γιανα Βρείτε Ευπάθειες
* **Ανάλυση Διαφορετικών Απαντήσεων:**
* Στείλτε ελαφρώς παραλλαγμένες εκδόσεις ενός αιτήματος και παρατηρήστε ανοι απαντήσεις του διακομιστή διαφέρουν με απροσδόκητο τρόπο, υποδεικνύοντας μια διαφορά στην ανάλυση.
* **Χρησιμοποιώντας Αυτοματοποιημένα Εργαλεία:**
* Εργαλεία όπως η επέκταση 'HTTP Request Smuggler' του Burp Suite μπορούν αυτόματα να δοκιμάσουν αυτές τις ευπάθειες στέλνοντας διάφορες μορφές ασαφών αιτημάτων και αναλύοντας τις απαντήσεις.
* **Δοκιμές Διαφορετικών Τιμών Content-Length:**
* Στείλτε αιτήματα με μεταβαλλόμενες τιμές `Content-Length` που δεν ευθυγραμμίζονται με το πραγματικό μήκος περιεχομένου και παρατηρήστε πώς ο διακομιστής χειρίζεται τέτοιες ασυμφωνίες.
* Στείλτε αιτήματα με παραποιημένες ή κακώς διαμορφωμένες κεφαλίδες `Transfer-Encoding` και παρακολουθήστε πώς αντιδρούν διαφορετικά οι διακομιστές front-end και back-end σε τέτοιες παραποιήσεις.
### Δοκιμή Ευπάθειας HTTP Request Smuggling
Αφού επιβεβαιωθεί η αποτελεσματικότητα των τεχνικών χρονομέτρησης, είναι κρίσιμο να επαληθευτεί αν τα αιτήματα του πελάτη μπορούν να παραποιηθούν. Μια απλή μέθοδος είναι να προσπαθήσετε να δηλητηριάσετε τα αιτήματά σας, για παράδειγμα, κάνοντάς το αίτημα προς το `/`να αποδώσει μια απάντηση 404. Τα παραδείγματα `CL.TE` και `TE.CL` που συζητήθηκαν προηγουμένως στο [Basic Examples](./#basic-examples) δείχνουν πώς να δηλητηριάσετε το αίτημα ενός πελάτη γιανα προκαλέσετε μια απάντηση 404, παρά το γεγονός ότι ο πελάτης στοχεύει να αποκτήσει πρόσβαση σε διαφορετικό πόρο.
* **Διακριτές Δικτυακές Συνδέσεις:** Τα "επίθεση" και "κανονικά" αιτήματα θα πρέπει να αποστέλλονται μέσω ξεχωριστών δικτυακών συνδέσεων. Η χρήση της ίδιας σύνδεσης και για τα δύο δεν επιβεβαιώνει την παρουσία της ευπάθειας.
* **Συνεπής URL και Παράμετροι:** Στοχεύστε να χρησιμοποιήσετε ταυτόσημα URLs και ονόματα παραμέτρων και για τα δύο αιτήματα. Οι σύγχρονες εφαρμογές συχνά δρομολογούν αιτήματα σε συγκεκριμένους διακομιστές back-end με βάση το URL και τις παραμέτρους. Η αντιστοίχιση αυτών αυξάνει την πιθανότητα ότι και τα δύο αιτήματα θα επεξεργαστούν από τον ίδιο διακομιστή, προϋπόθεση για μια επιτυχημένη επίθεση.
* **Χρονομέτρηση και Συνθήκες Αγώνα:** Το "κανονικό" αίτημα, που προορίζεται να ανιχνεύσει την παρέμβαση από το "επίθεση" αίτημα, ανταγωνίζεται άλλα ταυτόχρονα αιτήματα εφαρμογής. Επομένως, στείλτε το "κανονικό" αίτημα αμέσως μετά το "επίθεση" αίτημα. Οι πολυάσχολες εφαρμογές μπορεί να απαιτούν πολλές δοκιμές για την επιβεβαίωση της ευπάθειας.
* **Προκλήσεις Φορτωτικής Ισορροπίας:** Οι διακομιστές front-end που λειτουργούν ως ισοσταθμιστές φορτίου μπορεί να διανέμουν αιτήματα σε διάφορα συστήματα back-end. Εάν τα "επίθεση" και "κανονικά" αιτήματα καταλήξουν σε διαφορετικά συστήματα, η επίθεση δεν θα επιτύχει. Αυτό το στοιχείο ισοσταθμιστή φορτίου μπορεί να απαιτήσει πολλές προσπάθειες για την επιβεβαίωση μιας ευπάθειας.
* **Ακούσια Επίδραση στους Χρήστες:** Εάν η επίθεσή σας επηρεάσει ακούσια το αίτημα άλλου χρήστη (όχι το "κανονικό" αίτημα που στείλατε για ανίχνευση), αυτό υποδεικνύει ότι η επίθεσή σας επηρέασε έναν άλλο χρήστη της εφαρμογής. Η συνεχής δοκιμή θα μπορούσε να διαταράξει άλλους χρήστες, απαιτώντας προσεκτική προσέγγιση.
Μερικές φορές, οι front-end proxies επιβάλλουν μέτρα ασφαλείας, εξετάζοντας τα εισερχόμενα αιτήματα. Ωστόσο, αυτά τα μέτρα μπορούν να παρακαμφθούν εκμεταλλευόμενα το HTTP Request Smuggling, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση σε περιορισμένα endpoints. Για παράδειγμα, η πρόσβαση στο `/admin` μπορεί να απαγορεύεται εξωτερικά, με τον front-end proxy να μπλοκάρει ενεργά τέτοιες προσπάθειες. Ωστόσο, αυτός ο proxy μπορεί να παραλείψει να εξετάσει τα ενσωματωμένα αιτήματα μέσα σε ένα smuggled HTTP αίτημα, αφήνοντας ένα παραθυράκι για την παράκαμψη αυτών των περιορισμών.
Σκεφτείτε τα παρακάτω παραδείγματα που απεικονίζουν πώς το HTTP Request Smuggling μπορεί να χρησιμοποιηθεί γιανα παρακάμψει τους ελέγχους ασφαλείας front-end, στοχεύοντας συγκεκριμένα τη διαδρομή `/admin`, η οποία συνήθως φυλάσσεται από τον front-end proxy:
Στην επίθεση CL.TE, η κεφαλίδα `Content-Length` χρησιμοποιείται για το αρχικό αίτημα, ενώ το επόμενο ενσωματωμένο αίτημα χρησιμοποιεί την κεφαλίδα `Transfer-Encoding: chunked`. Ο μεσολαβητής front-end επεξεργάζεται το αρχικό αίτημα `POST` αλλά αποτυγχάνει να ελέγξει το ενσωματωμένο αίτημα `GET /admin`, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση στο μονοπάτι `/admin`.
Αντίθετα, στην επίθεση TE.CL, το αρχικό `POST` αίτημα χρησιμοποιεί `Transfer-Encoding: chunked`, και το επόμενο ενσωματωμένο αίτημα επεξεργάζεται με βάση την κεφαλίδα `Content-Length`. Παρόμοια με την επίθεση CL.TE, ο πρόξενος της εμπρός πλευράς παραβλέπει το λαθραίο αίτημα `GET /admin`, παραχωρώντας ακούσια πρόσβαση στη περιορισμένη διαδρομή `/admin`.
Οι εφαρμογές συχνά χρησιμοποιούν έναν **διακομιστή εμπρός πλευράς**γιανα τροποποιούν τα εισερχόμενα αιτήματα πριν τα περάσουν στον διακομιστή πίσω πλευράς. Μια τυπική τροποποίηση περιλαμβάνει την προσθήκη κεφαλίδων, όπως `X-Forwarded-For: <IP του πελάτη>`, γιανα μεταφέρει τη διεύθυνση IP του πελάτη στον διακομιστή πίσω πλευράς. Η κατανόηση αυτών των τροποποιήσεων μπορεί να είναι κρίσιμη, καθώς μπορεί να αποκαλύψει τρόπους για**να παρακαμφθούν οι προστασίες** ή **να αποκαλυφθούν κρυφές πληροφορίες ή σημεία πρόσβασης**.
Για να ερευνήσετε πώς ένας πρόξενος τροποποιεί ένα αίτημα, εντοπίστε μια παράμετρο POST που ο διακομιστής πίσω πλευράς επαναλαμβάνει στην απάντηση. Στη συνέχεια, δημιουργήστε ένα αίτημα, χρησιμοποιώντας αυτή την παράμετρο τελευταία, παρόμοια με το εξής:
Σε αυτή τη δομή, τα επόμενα στοιχεία του αιτήματος προστίθενται μετά το `search=`, το οποίο είναι η παράμετρος που αντανακλάται στην απάντηση. Αυτή η αντανάκλαση θα αποκαλύψει τις κεφαλίδες του επόμενου αιτήματος.
Είναι σημαντικό να ευθυγραμμιστεί η κεφαλίδα `Content-Length` του εσωτερικού αιτήματος με το πραγματικό μήκος περιεχομένου. Είναι σκόπιμο να ξεκινήσετε με μια μικρή τιμή και να αυξάνετε σταδιακά, καθώς μια πολύ χαμηλή τιμή θα κόψει τα αντανακλώμενα δεδομένα, ενώ μια πολύ υψηλή τιμή μπορεί να προκαλέσει σφάλμα στο αίτημα.
Αυτή η τεχνική είναι επίσης εφαρμόσιμη στο πλαίσιο μιας ευπάθειας TE.CL, αλλά το αίτημα θα πρέπει να τερματίζεται με `search=\r\n0`. Ανεξάρτητα από τους χαρακτήρες νέας γραμμής, οι τιμές θα προστεθούν στην παράμετρο αναζήτησης.
Αυτή η μέθοδος εξυπηρετεί κυρίως την κατανόηση των τροποποιήσεων του αιτήματος που γίνονται από τον μεσολαβητή front-end, εκτελώντας ουσιαστικά μια αυτοκατευθυνόμενη έρευνα.
Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσθέτοντας ένα συγκεκριμένο αίτημα ως την τιμή μιας παραμέτρου κατά τη διάρκεια μιας λειτουργίας POST. Να πώς μπορεί να επιτευχθεί αυτό:
Σε αυτό το σενάριο, η **παράμετρος σχολίου** προορίζεται να αποθηκεύσει τα περιεχόμενα στην ενότητα σχολίων μιας ανάρτησης σε μια δημόσια προσβάσιμη σελίδα. Ως εκ τούτου, τα περιεχόμενα της επόμενης αίτησης θα εμφανιστούν ως σχόλιο.
Ωστόσο, αυτή η τεχνική έχει περιορισμούς. Γενικά, καταγράφει δεδομένα μόνο μέχρι τον διαχωριστή παραμέτρου που χρησιμοποιείται στην κρυφή αίτηση. Για υποβολές φορμών με κωδικοποίηση URL, αυτός ο διαχωριστής είναι ο χαρακτήρας `&`. Αυτό σημαίνει ότι το καταγεγραμμένο περιεχόμενο από την αίτηση του θύματος θα σταματήσει στον πρώτο `&`, ο οποίος μπορεί ακόμη και να είναι μέρος της συμβολοσειράς ερωτήματος.
Επιπλέον, αξίζει να σημειωθεί ότι αυτή η προσέγγιση είναι επίσης βιώσιμη με μια ευπάθεια TE.CL. Σε τέτοιες περιπτώσεις, η αίτηση θα πρέπει να ολοκληρώνεται με `search=\r\n0`. Ανεξάρτητα από τους χαρακτήρες νέας γραμμής, οι τιμές θα προστεθούν στην παράμετρο αναζήτησης.
Σε σενάρια όπου μια ιστοσελίδα είναι ευάλωτη σε Reflected XSS μέσω της κεφαλίδας User-Agent, το παρακάτω payload δείχνει πώς να εκμεταλλευτείτε αυτήν την ευπάθεια:
1.Να ξεκινήσει ένα `POST` αίτημα, φαινομενικά τυπικό, με ένα `Transfer-Encoding: chunked` header γιανα υποδείξει την αρχή της λαθραίας μεταφοράς.
2.Να ακολουθήσει με ένα `0`, που σηματοδοτεί το τέλος του σώματος του chunked μηνύματος.
3. Στη συνέχεια, εισάγεται ένα λαθραίο `GET` αίτημα, όπου το `User-Agent` header είναι εγχυμένο με ένα script, `<script>alert(1)</script>`, ενεργοποιώντας το XSS όταν ο διακομιστής επεξεργάζεται αυτό το επόμενο αίτημα.
Με την παραποίηση του `User-Agent` μέσω της λαθραίας μεταφοράς, το payload παρακάμπτει τους κανονικούς περιορισμούς αιτημάτων, εκμεταλλευόμενο έτσι την ευπάθεια Reflected XSS με έναν μη τυπικό αλλά αποτελεσματικό τρόπο.
Σε περίπτωση που το περιεχόμενο του χρήστη αντανακλάται σε μια απάντηση με **`Content-type`** όπως **`text/plain`**, αποτρέποντας την εκτέλεση του XSS. Ανο διακομιστής υποστηρίζει **HTTP/0.9, μπορεί να είναι δυνατό να παρακαμφθεί αυτό**!
Σε [**αυτή την αναφορά**](https://mizu.re/post/twisty-python), αυτό εκμεταλλεύτηκε με μια λαθραία μεταφορά αιτήματος και ένα **ευάλωτο endpoint που θα απαντήσει με την είσοδο του χρήστη**γιανα λαθραία μεταφέρει ένα αίτημα με HTTP/0.9. Η παράμετρος που θα αντανακλαστεί στην απάντηση περιείχε μια **ψεύτικη απάντηση HTTP/1.1 (με headers και σώμα)** έτσι ώστε η απάντηση να περιέχει έγκυρο εκτελέσιμο JS κώδικα με `Content-Type``text/html`.
Οι εφαρμογές συχνά ανακατευθύνουν από μια διεύθυνση URL σε άλλη χρησιμοποιώντας το hostname από το `Host` header στην ανακατευθυνόμενη URL. Αυτό είναι κοινό με διακομιστές ιστού όπως ο Apache και ο IIS. Για παράδειγμα, η αίτηση ενός φακέλου χωρίς τελικό slash έχει ως αποτέλεσμα μια ανακατεύθυνση γιανα συμπεριληφθεί το slash:
Αν και φαίνεται αβλαβές, αυτή η συμπεριφορά μπορεί να χειραγωγηθεί χρησιμοποιώντας HTTP request smuggling γιανα ανακατευθύνει τους χρήστες σε έναν εξωτερικό ιστότοπο. Για παράδειγμα:
Αυτό το λαθραίο αίτημα θα μπορούσε να προκαλέσει την επόμενη επεξεργασμένη αίτηση χρήστη να ανακατευθυνθεί σε μια ιστοσελίδα που ελέγχεται από τον επιτιθέμενο:
In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.
Η δηλητηρίαση της μνήμης cache του ιστού μπορεί να εκτελεστεί εάν οποιοδήποτε στοιχείο της **υποδομής front-end αποθηκεύει περιεχόμενο**, συνήθως γιανα βελτιώσει την απόδοση. Με την παραποίηση της απάντησης του διακομιστή, είναι δυνατό να**δηλητηριαστεί η cache**.
Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του διακομιστή θα μπορούσαν να τροποποιηθούν γιανα επιστρέψουν ένα σφάλμα 404 (ανατρέξτε σε [Basic Examples](./#basic-examples)). Ομοίως, είναι εφικτό να ξεγελάσουμε τον διακομιστή ώστε να παραδώσει περιεχόμενο `/index.html` ως απάντηση σε ένα αίτημα για`/static/include.js`. Ως αποτέλεσμα, το περιεχόμενο `/static/include.js` αντικαθίσταται στην cache με αυτό του `/index.html`, καθιστώντας το `/static/include.js` μη προσβάσιμο στους χρήστες, γεγονός που μπορεί να οδηγήσει σε άρνηση υπηρεσίας (DoS).
Αυτή η τεχνική γίνεται ιδιαίτερα ισχυρή εάν ανακαλυφθεί μια **ευπάθεια Open Redirect** ή εάν υπάρχει **ανακατεύθυνση στον ιστό σε μια ανοιχτή ανακατεύθυνση**. Τέτοιες ευπάθειες μπορούν να εκμεταλλευτούν γιανα αντικαταστήσουν το αποθηκευμένο περιεχόμενο του `/static/include.js` με ένα σενάριο υπό τον έλεγχο του επιτιθέμενου, επιτρέποντας ουσιαστικά μια εκτενή επίθεση Cross-Site Scripting (XSS) σε όλους τους πελάτες που ζητούν το ενημερωμένο `/static/include.js`.
Παρακάτω είναι μια απεικόνιση της εκμετάλλευσης **δηλητηρίασης cache σε συνδυασμό με ανακατεύθυνση στον ιστό σε ανοιχτή ανακατεύθυνση**. Ο στόχος είναι να τροποποιηθεί το περιεχόμενο της cache του `/static/include.js`γιανα εξυπηρετήσει κώδικα JavaScript που ελέγχεται από τον επιτιθέμενο:
Σημειώστε το ενσωματωμένο αίτημα που στοχεύει το `/post/next?postId=3`. Αυτό το αίτημα θα ανακατευθυνθεί στο `/post?postId=4`, χρησιμοποιώντας την **τιμή κεφαλίδας Host**γιανα προσδιορίσει το domain. Με την τροποποίηση της **κεφαλίδας Host**, ο επιτιθέμενος μπορεί να ανακατευθύνει το αίτημα στο domain του (**on-site redirect to open redirect**).
Μετά από επιτυχή **socket poisoning**, θα πρέπει να ξεκινήσει ένα **GET request**για το `/static/include.js`. Αυτό το αίτημα θα μολυνθεί από το προηγούμενο αίτημα **on-site redirect to open redirect** και θα ανακτήσει το περιεχόμενο του script που ελέγχεται από τον επιτιθέμενο.
Στη συνέχεια, οποιοδήποτε αίτημα για το `/static/include.js` θα εξυπηρετεί το αποθηκευμένο περιεχόμενο του script του επιτιθέμενου, εκκινώντας αποτελεσματικά μια ευρεία επίθεση XSS.
### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> * Στο **web cache poisoning**, ο επιτιθέμενος προκαλεί την εφαρμογή να αποθηκεύσει κάποιο κακόβουλο περιεχόμενο στην cache, και αυτό το περιεχόμενο εξυπηρετείται από την cache σε άλλους χρήστες της εφαρμογής.
> * Στο **web cache deception**, ο επιτιθέμενος προκαλεί την εφαρμογή να αποθηκεύσει κάποιο ευαίσθητο περιεχόμενο που ανήκει σε άλλο χρήστη στην cache, και ο επιτιθέμενος στη συνέχεια ανακτά αυτό το περιεχόμενο από την cache.
Αν αυτή η λαθραία αίτηση δηλητηριάσει μια είσοδο cache που προορίζεται για στατικό περιεχόμενο (π.χ., `/someimage.png`), τα ευαίσθητα δεδομένα του θύματος από το `/private/messages` μπορεί να αποθηκευτούν στην είσοδο cache του στατικού περιεχομένου. Ως εκ τούτου, ο επιτιθέμενος θα μπορούσε ενδεχομένως να ανακτήσει αυτά τα αποθηκευμένα ευαίσθητα δεδομένα.
[**Σε αυτή την ανάρτηση**](https://portswigger.net/research/trace-desync-attack) προτείνεται ότι ανο διακομιστής έχει ενεργοποιημένη τη μέθοδο TRACE, θα μπορούσε να είναι δυνατό να την καταχραστεί με ένα HTTP Request Smuggling. Αυτό συμβαίνει επειδή αυτή η μέθοδος θα ανακλά οποιαδήποτε κεφαλίδα σταλεί στον διακομιστή ως μέρος του σώματος της απάντησης. Για παράδειγμα:
Ένα παράδειγμα για το πώς να εκμεταλλευτείτε αυτή τη συμπεριφορά θα ήταν να**λαθρέψετε πρώτα ένα HEAD request**. Αυτό το αίτημα θα απαντηθεί μόνο με τα **headers** ενός GET request (**`Content-Type`** μεταξύ αυτών). Καινα λαθρέψετε **άμεσα μετά το HEAD ένα TRACE request**, το οποίο θα **αντανακλά τα δεδομένα που στάλθηκαν**.\
Καθώς η απάντηση του HEAD θα περιέχει ένα header `Content-Length`, η **απάντηση του TRACE request θα θεωρείται ως το σώμα της απάντησης του HEAD, αντανακλώντας έτσι αυθαίρετα δεδομένα** στην απάντηση. \
Αυτή η απάντηση θα σταλεί στο επόμενο αίτημα μέσω της σύνδεσης, οπότε αυτό θα μπορούσε να**χρησιμοποιηθεί σε ένα cached JS αρχείο για παράδειγμα γιανα εισάγει αυθαίρετο JS κώδικα**.
Συνεχίστε ακολουθώντας [**αυτή την ανάρτηση**](https://portswigger.net/research/trace-desync-attack) προτείνεται ένας άλλος τρόπος γιανα εκμεταλλευτείτε τη μέθοδο TRACE. Όπως σχολιάστηκε, λαθρεύοντας ένα HEAD request και ένα TRACE request είναι δυνατό να**ελέγξετε κάποια αντανακλώμενα δεδομένα** στην απάντηση του HEAD request. Το μήκος του σώματος του HEAD request υποδεικνύεται βασικά στο header Content-Length και σχηματίζεται από την απάντηση στο TRACE request.
Επομένως, η νέα ιδέα θα ήταν ότι, γνωρίζοντας αυτό το Content-Length και τα δεδομένα που δίνονται στην απάντηση του TRACE, είναι δυνατό να γίνει η απάντηση του TRACE να περιέχει μια έγκυρη HTTP απάντηση μετά το τελευταίο byte του Content-Length, επιτρέποντας σε έναν επιτιθέμενο να ελέγξει πλήρως το αίτημα στην επόμενη απάντηση (η οποία θα μπορούσε να χρησιμοποιηθεί γιανα εκτελέσει μια δηλητηρίαση cache).
Θα δημιουργήσει αυτές τις απαντήσεις (σημειώστε πώς η απάντηση HEAD έχει ένα Content-Length που καθιστά την απάντηση TRACE μέρος του σώματος της HEAD και μόλις τελειώσει το Content-Length της HEAD, μια έγκυρη HTTP απάντηση διαρρέει):
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Αυτό το εργαλείο είναι ένας HTTP Fuzzer βασισμένος σε γραμματική, χρήσιμο γιανα βρείτε παράξενες διαφορές στο request smuggling.
Μάθετε & εξασκηθείτε στο AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Μάθετε & εξασκηθείτε στο GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Ελέγξτε τα [**σχέδια συνδρομής**](https://github.com/sponsors/carlospolop)!
* **Εγγραφείτε στην** 💬 [**ομάδα Discord**](https://discord.gg/hRep4RUj7f) ή στην [**ομάδα telegram**](https://t.me/peass) ή **ακολουθήστε** μας στο **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**