Puoi rubare cookie di sessione con attacco BREACH?

Question

Puoi rubare cookie di sessione con attacco BREACH?

#1 da (2 voti)

4

Gran parte delle discussioni sulla vulnerabilità di BREACH riguardano il furto di token CSRF basati su sessioni. Ma se riesci a rubare un token basato sulla sessione, potresti anche rubare il token di sessione stesso? Ovviamente ci sono alcuni punti più sottili dell'attacco BREACH che non capisco:)

Sono specificamente interessato a Django. In tutte le richieste per le quali il browser invia un cookie csrftoken , il browser invia anche un cookie sessionid .

Modifica :

Se la mia nuova comprensione è corretta, allora la risposta è banalmente NO. Il documento BREACH dice:

To be vulnerable to this side-channel, a web app must: (1) Be served from a server that uses HTTP-level compression, AND (2) Reflect user-input in HTTP response bodies, AND (3) Reflect a secret (such as a CSRF token) in HTTP response bodies.

Do (2) e (3) si riferiscono alla stessa cosa? Cioè, l'attacco è possibile solo se l'input dell'utente ripetuto nel corpo della risposta HTTP è LA STESSA come il segreto che stai cercando di rubare?

Se è corretto, allora ha senso.

Puoi rubare un token CSRF, perché è immesso dall'utente (generalmente tramite un modulo POST param o cookie), E può essere ripetuto di nuovo nella risposta (sia come input nascosto a un modulo, sia come cookie ), Ed è il segreto che stai cercando di rubare.

Non puoi rubare un token di sessione, perché l'utente non può alterare l'output basato su quell'input. Voglio dire, certo, l'utente può inviare un cookie di sessione alterato, ma il server (si spera) non ripeterà mai quel token di sessione non valido nella risposta.

web-application tls session-management csrf

posta simmbot 27.02.2015 - 23:26

fonte

1 risposta

Leggi altre domande sui tag web-application tls session-management csrf

Perché il mio server Web riceve così tanti ripristini TCP da alcuni client? Come bypassare la protezione dell'intestazione XMLHttpRequest per un attacco CSRF

score 2 · Accepted Answer

Quindi BREACH è un attacco specifico contro i corpi di risposta, non le intestazioni. Poiché i cookie sono inviati come intestazioni, non sono soggetti alla tecnica descritta da BREACH, ma sono stati vulnerabili ad altri attacchi di canale laterale di compressione come CRIME.

Cosa intendono per:

(2) Reflect user-input in HTTP response bodies, AND (3) Reflect a secret (such as a CSRF token) in HTTP response bodies.

È questo (2) che l'attaccante deve essere in grado di inviare l'input dell'utente che controlla che viene poi aggiunto al corpo della risposta in modo tale da poter presentare ipotesi su quale sia il segreto e (3) l'applicazione deve anche contenere il segreto che sta indovinando nel corpo della risposta.

Ciò che fa è creare un oracolo. Poiché è un attacco alla compressione, sta inoltrando ipotesi per la prima parte del segreto e, quando la sua ipotesi è corretta, farà sì che il corpo della risposta sia leggermente più corto, perché la duplicazione tra la sua ipotesi e il vero segreto sarà eliminata dal algoritmo di compressione. Quindi, in termini semplicistici, continua a indovinare un personaggio alla volta finché non ottiene il carattere successivo corretto, e il corpo della risposta diventa un byte più corto. Quindi, passa al personaggio successivo e ripete il processo fino a quando non conosce il segreto completo.