Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/cookie-tossing.md

7.1 KiB
Raw Blame History

Cookie Tossing

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

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 Cookie, quando un cookie è impostato su un dominio (specificandolo) verrà utilizzato nel dominio e nei sottodomini.

{% hint style="danger" %} 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" {% endhint %}

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.

{% hint style="warning" %} 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. {% endhint %}

Bypass della Protezione

Una possibile protezione contro questo attacco sarebbe 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 è stato già dato il cookie, l'attaccante potrebbe causare un overflow del cookie e quindi, una volta che il cookie legittimo è eliminato, impostare quello malizioso.

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Un altro utile bypass potrebbe essere codificare l'URL del nome del cookie poiché alcune protezioni controllano 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 Bomba di Cookie:

{% content-ref url="cookie-bomb.md" %} cookie-bomb.md {% endcontent-ref %}

Difese

Utilizzare il prefisso __Host nel nome del cookie

  • Se 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

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks: