Cookie Tossing
Descrizione
Se un attaccante può controllare un sottodominio o il dominio di un'azienda o trova un XSS in un sottodominio, sarà in grado di eseguire questo attacco.
Come indicato nella sezione Hacking dei Cookies, quando un cookie è impostato su un dominio (specificandolo) verrà utilizzato nel dominio e nei sottodomini.
Pertanto, un attaccante sarà in grado di impostare su dominio e sottodomini un cookie specifico facendo qualcosa del genere document.cookie="session=1234; Path=/app/login; domain=.example.com"
Questo può essere pericoloso poiché l'attaccante potrebbe essere in grado di:
Fissare il cookie della vittima all'account dell'attaccante quindi se l'utente non si accorge, effettuerà le azioni nell'account dell'attaccante e l'attaccante potrebbe ottenere informazioni interessanti (controllare la cronologia delle ricerche dell'utente nella piattaforma, la vittima potrebbe inserire la sua carta di credito nell'account...)
Se il cookie non cambia dopo il login, l'attaccante potrebbe semplicemente fissare un cookie (session-fixation), aspettare che la vittima effettui il login e poi usare quel cookie per effettuare il login come la vittima.
A volte, anche se i cookie di sessione cambiano, l'attaccante può usare quello precedente e riceverà anche il nuovo.
Se il cookie imposta un valore iniziale (come in flask dove il cookie può impostare il token CSRF della sessione e questo valore verrà mantenuto dopo che la vittima effettua il login), l'attaccante può impostare questo valore noto e poi abusarne (in questo scenario, l'attaccante potrebbe quindi far eseguire all'utente una richiesta CSRF poiché conosce il token CSRF).
Proprio come impostare il valore, l'attaccante potrebbe anche ottenere un cookie non autenticato generato dal server, ottenere il token CSRF da esso e usarlo.
Ordine dei Cookie
Quando un browser riceve due cookie con lo stesso nome che influenzano parzialmente lo stesso ambito (dominio, sottodomini e percorso), il browser invierà entrambi i valori del cookie quando entrambi sono validi per la richiesta.
A seconda di chi ha il percorso più specifico o quale sia il più vecchio, il browser imposterà prima il valore del cookie e poi il valore dell'altro come in: Cookie: iduser=CookiePiùSpecificoEPiùVecchio; iduser=Menospecifico;
La maggior parte dei siti web utilizzerà solo il primo valore. Quindi, se un attaccante vuole impostare un cookie è meglio farlo prima che ne venga impostato un altro o impostarlo con un percorso più specifico.
Inoltre, la capacità di impostare un cookie in un percorso più specifico è molto interessante poiché sarà possibile far lavorare la vittima con il suo cookie tranne nel percorso specifico dove il cookie malizioso impostato verrà inviato prima.
Bypass della Protezione
Una possibile protezione contro questo attacco potrebbe essere che il server web non accetterà richieste con due cookie con lo stesso nome ma con due valori diversi.
Per aggirare lo scenario in cui l'attaccante sta impostando un cookie dopo che alla vittima è già stato dato il cookie, l'attaccante potrebbe causare un overflow del cookie e quindi, una volta che il cookie legittimo è eliminato, impostare quello malizioso.
pageCookie Jar OverflowUn altro utile bypass potrebbe essere codificare l'URL del nome del cookie poiché alcune protezioni controllano la presenza di 2 cookie con lo stesso nome in una richiesta e quindi il server decodificherà i nomi dei cookie.
Bomba di Cookie
Un attacco di Cookie Tossing potrebbe anche essere utilizzato per eseguire un attacco di Cookie Bomb:
pageCookie BombDifese
Usa il prefisso __Host nel nome del cookie
__Host nel nome del cookieSe un nome del cookie ha questo prefisso, sarà accettato solo in una direttiva Set-Cookie se è contrassegnato come Sicuro, è stato inviato da un'origine sicura, non include un attributo Dominio e ha l'attributo Percorso impostato su /
Questo impedisce ai sottodomini di forzare un cookie sul dominio principale poiché questi cookie possono essere considerati "bloccati dal dominio"
Riferimenti
Last updated