Cookie Tossing
Description
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 Cookies Hacking, 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 come 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 in modo che se l'utente non se ne accorge, eseguirà le azioni nell'account dell'attaccante e l'attaccante potrebbe ottenere alcune informazioni interessanti (controllare la cronologia delle ricerche dell'utente nella piattaforma, la vittima potrebbe impostare 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 accedere come la vittima.
A volte, anche se i cookie di sessione cambiano, l'attaccante usa 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 sarà mantenuto dopo che la vittima effettua il login), l'attaccante potrebbe impostare questo valore noto e poi abusarne (in quel 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.
Cookie Order
Quando un browser riceve due cookie con lo stesso nome che influiscono parzialmente sullo 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=MoreSpecificAndOldestCookie; iduser=LessSpecific;
La maggior parte dei siti web utilizzerà solo il primo valore. Quindi, se un attaccante vuole impostare un cookie, è meglio impostarlo prima che un altro venga impostato 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 che nel percorso specifico dove il cookie malevolo impostato verrà inviato prima.
Protection Bypass
Una possibile protezione contro questo attacco sarebbe che il server web non accetti richieste con due cookie con lo stesso nome ma due valori diversi.
Per bypassare lo scenario in cui l'attaccante sta impostando un cookie dopo che alla vittima è già stato dato il cookie, l'attaccante potrebbe causare un cookie overflow e poi, una volta che il cookie legittimo è stato eliminato, impostare quello malevolo.
Cookie Jar OverflowUn altro utile bypass potrebbe essere URL codificare il nome del cookie poiché alcune protezioni controllano 2 cookie con lo stesso nome in una richiesta e poi il server decodificherà i nomi dei cookie.
Cookie Bomb
Un attacco di Cookie Tossing può anche essere utilizzato per eseguire un attacco Cookie Bomb:
Cookie BombDefenses
Usa il prefisso __Host nel nome del cookie
__Host nel nome del cookieSe un nome di cookie ha questo prefisso, verrà accettato in una direttiva Set-Cookie solo se è contrassegnato come Sicuro, è stato inviato da un'origine sicura, non include un attributo Domain e ha l'attributo Path impostato su /
Questo impedisce ai sottodomini di forzare un cookie al dominio principale poiché questi cookie possono essere visti come "bloccati a livello di dominio"
References
Last updated
