mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
71 lines
8.3 KiB
Markdown
71 lines
8.3 KiB
Markdown
# Cookie Tossing
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
### Περιγραφή
|
||
|
||
Εάν ένας επιτιθέμενος μπορεί να **ελέγξει μια υποτομέα ή το domain μιας εταιρείας ή βρει ένα XSS σε μια υποτομέα**, θα είναι σε θέση να εκτελέσει αυτή την επίθεση.
|
||
|
||
Όπως αναφέρθηκε στην ενότητα Hacking Cookies, όταν ένα **cookie ορίζεται σε ένα domain (καθορίζοντάς το) θα χρησιμοποιείται στο domain και στις υποτομείς.**
|
||
|
||
> [!CAUTION]
|
||
> Επομένως, **ένας επιτιθέμενος θα είναι σε θέση να ορίσει σε το domain και τις υποτομείς ένα συγκεκριμένο cookie κάνοντας κάτι όπως** `document.cookie="session=1234; Path=/app/login; domain=.example.com"`
|
||
|
||
Αυτό μπορεί να είναι επικίνδυνο καθώς ο επιτιθέμενος μπορεί να είναι σε θέση να:
|
||
|
||
- **Σταθεροποιήσει το cookie του θύματος στον λογαριασμό του επιτιθέμενου** έτσι ώστε αν ο χρήστης δεν το παρατηρήσει, **να εκτελεί τις ενέργειες στον λογαριασμό του επιτιθέμενου** και ο επιτιθέμενος μπορεί να αποκτήσει κάποιες ενδιαφέρουσες πληροφορίες (να ελέγξει την ιστορία των αναζητήσεων του χρήστη στην πλατφόρμα, το θύμα μπορεί να έχει ορίσει την πιστωτική του κάρτα στον λογαριασμό...)
|
||
- Ένα παράδειγμα αυτού [μπορεί να βρεθεί εδώ](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) όπου ο επιτιθέμενος ορίζει το cookie του σε συγκεκριμένες ενότητες που θα χρησιμοποιήσει ένα θύμα για να εξουσιοδοτήσει **πρόσβαση στα git repos του αλλά από τον λογαριασμό του επιτιθέμενου** καθώς θα ορίζει τα cookies του στα απαραίτητα endpoints.
|
||
- Εάν το **cookie δεν αλλάξει μετά την είσοδο**, ο επιτιθέμενος μπορεί απλά να **σταθεροποιήσει ένα cookie (session-fixation)**, να περιμένει μέχρι το θύμα να συνδεθεί και στη συνέχεια **να χρησιμοποιήσει αυτό το cookie για να συνδεθεί ως το θύμα**.
|
||
- Μερικές φορές, ακόμη και αν τα session cookies αλλάζουν, ο επιτιθέμενος χρησιμοποιεί το προηγούμενο και θα λάβει και το νέο.
|
||
- Εάν το **cookie ορίζει κάποια αρχική τιμή** (όπως στο flask όπου το **cookie** μπορεί να **ορίσει** το **CSRF token** της συνεδρίας και αυτή η τιμή θα διατηρηθεί μετά την είσοδο του θύματος), ο **επιτιθέμενος μπορεί να ορίσει αυτή τη γνωστή τιμή και στη συνέχεια να την εκμεταλλευτεί** (σε αυτή την περίπτωση, ο επιτιθέμενος μπορεί να κάνει το χρήστη να εκτελέσει ένα CSRF αίτημα καθώς γνωρίζει το CSRF token).
|
||
- Ακριβώς όπως η ρύθμιση της τιμής, ο επιτιθέμενος θα μπορούσε επίσης να αποκτήσει ένα μη εξουσιοδοτημένο cookie που δημιουργήθηκε από τον διακομιστή, να αποκτήσει το CSRF token από αυτό και να το χρησιμοποιήσει.
|
||
|
||
### Cookie Order
|
||
|
||
Όταν ένας περιηγητής λαμβάνει δύο cookies με το ίδιο όνομα **που επηρεάζουν μερικώς την ίδια εμβέλεια** (domain, υποτομείς και διαδρομή), ο **περιηγητής θα στείλει και τις δύο τιμές του cookie** όταν και οι δύο είναι έγκυρες για το αίτημα.
|
||
|
||
Ανάλογα με το ποιος έχει **την πιο συγκεκριμένη διαδρομή** ή ποιο είναι το **παλαιότερο**, ο περιηγητής θα **ορίσει πρώτα την τιμή του cookie** και στη συνέχεια την τιμή του άλλου όπως στο: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
|
||
|
||
Οι περισσότερες **ιστοσελίδες θα χρησιμοποιούν μόνο την πρώτη τιμή**. Έτσι, αν ένας επιτιθέμενος θέλει να ορίσει ένα cookie είναι καλύτερα να το ορίσει πριν οριστεί ένα άλλο ή να το ορίσει με μια πιο συγκεκριμένη διαδρομή.
|
||
|
||
> [!WARNING]
|
||
> Επιπλέον, η ικανότητα να **ορίσετε ένα cookie σε μια πιο συγκεκριμένη διαδρομή** είναι πολύ ενδιαφέρουσα καθώς θα μπορείτε να κάνετε τον **θύμα να εργάζεται με το cookie του εκτός από την συγκεκριμένη διαδρομή όπου το κακόβουλο cookie θα σταλεί πρώτα**.
|
||
|
||
### Protection Bypass
|
||
|
||
Μια πιθανή προστασία κατά αυτής της επίθεσης θα ήταν ότι ο **διακομιστής ιστού δεν θα αποδέχεται αιτήματα με δύο cookies με το ίδιο όνομα αλλά με δύο διαφορετικές τιμές**.
|
||
|
||
Για να παρακάμψει το σενάριο όπου ο επιτιθέμενος ορίζει ένα cookie αφού το θύμα έχει ήδη λάβει το cookie, ο επιτιθέμενος θα μπορούσε να προκαλέσει μια **cookie overflow** και στη συνέχεια, μόλις το **νόμιμο cookie διαγραφεί, να ορίσει το κακόβουλο**.
|
||
|
||
|
||
{{#ref}}
|
||
cookie-jar-overflow.md
|
||
{{#endref}}
|
||
|
||
Μια άλλη χρήσιμη **παράκαμψη** θα μπορούσε να είναι να **URL encode το όνομα του cookie** καθώς κάποιες προστασίες ελέγχουν για 2 cookies με το ίδιο όνομα σε ένα αίτημα και στη συνέχεια ο διακομιστής θα αποκωδικοποιήσει τα ονόματα των cookies.
|
||
|
||
### Cookie Bomb
|
||
|
||
Μια επίθεση Cookie Tossing μπορεί επίσης να χρησιμοποιηθεί για να εκτελέσει μια **Cookie Bomb** επίθεση:
|
||
|
||
|
||
{{#ref}}
|
||
cookie-bomb.md
|
||
{{#endref}}
|
||
|
||
### Άμυνες
|
||
|
||
#### **Χρησιμοποιήστε το πρόθεμα `__Host` στο όνομα του cookie**
|
||
|
||
- Εάν ένα όνομα cookie έχει αυτό το πρόθεμα, **θα γίνεται αποδεκτό** σε μια οδηγία Set-Cookie μόνο εάν είναι επισημασμένο ως Secure, έχει σταλεί από μια ασφαλή προέλευση, δεν περιλαμβάνει ένα χαρακτηριστικό Domain και έχει το χαρακτηριστικό Path ορισμένο σε /
|
||
- **Αυτό αποτρέπει τους υποτομείς από το να επιβάλλουν ένα cookie στο apex domain καθώς αυτά τα cookies μπορούν να θεωρηθούν ως "domain-locked"**
|
||
|
||
### Αναφορές
|
||
|
||
- [**@blueminimal**](https://twitter.com/blueminimal)
|
||
- [**https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers**](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers)
|
||
- [**https://github.blog/2013-04-09-yummy-cookies-across-domains/**](https://github.blog/2013-04-09-yummy-cookies-across-domains/)
|
||
- [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg)
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|