Con l'attacco BREACH, il token CSRF basato su sessione è ancora sicuro?

Naviga le tue risposte
4

Questo è qualcosa che non sono stato in grado di comprendere, se BREACH consente la perdita di informazioni, dobbiamo mascherare o generare token CSRF in modo basato sul tempo o per richiesta per renderlo più sicuro?

Per quanto ne so, il token CSRF basato sulla sessione può proteggi l'utente da CSRF proprio bene . Ma quanto è accurato questo in contesto rispetto a SSL? Il problema qui non è più se l'attaccante può eseguire CSRF, ma se tale token CSRF può essere estratto da HTTPS con compressione attiva, può anche essere usato per filtrare altre informazioni?

Fondamentalmente sto chiedendo se questo la vecchia domanda ora ha una risposta diversa.

    
posta bitinn 11.10.2013 - 09:07
fonte

2 risposte

2

Se il tuo sito è vulnerabile a BREACH, un utente malintenzionato può indovinare qualsiasi cosa nel corpo della risposta un personaggio alla volta. L'autore dell'attacco fa più richieste, una per ipotesi, e può vedere se ha indovinato correttamente. Ad esempio, l'utente malintenzionato può provare queste ipotesi:

  • csrftoken = a
  • csrftoken = b
  • csrftoken = c
  • ecc.

Dopo un po 'calcola il primo carattere del token e passa al personaggio successivo. Come puoi vedere ci sono centinaia di richieste necessarie per indovinare l'intero token CSRF.

Questo attacco funziona solo se lo stesso token CSRF viene restituito in tutte le richieste. Se il token differisce tra le richieste, l'utente malintenzionato non può utilizzare più richieste per indovinarlo. Per proteggersi dall'attacco BREACH, il token CSRF dovrebbe essere diverso su ogni pagina.

Tuttavia, non è necessario creare un nuovo token per ogni richiesta. Basta semplicemente offuscare il token CSRF. Puoi crittografare o persino XOR il token CSRF con un po 'di sale che hai incluso nel modulo, come Django e Rails fare. Ciò significa che il token è diverso su ogni pagina, ma devi comunque controllare solo un valore nel back-end.

    
risposta data 24.11.2016 - 10:23
fonte
1

Per rispondere alla tua domanda: è ancora sicuro, se non usi i token CSRF basati su sessione E HTTP-Compression (vedi spiegazione sotto)

da breachattack.com / Sono interessato?

Se hai un corpo risposta HTTP che soddisfa ALL le seguenti condizioni, potresti essere vulnerabile:

  • Compressione HTTP La tua pagina viene pubblicata con compressione HTTP abilitata (GZIP / DEFLATE)
  • Dati utente : la tua pagina riflette i dati dell'utente tramite stringa di query o parametri POST
  • Un segreto : la pagina dell'applicazione pubblica le PII, un token CSRF, i dati sensibili

Mitigazioni / ordinati per efficacia

  1. Disabilitazione della compressione HTTP
  2. Separazione dei segreti dall'input dell'utente
  3. Randomizzazione dei segreti per richiesta
  4. Masking secrets (efficacemente randomizzato da XORing con un segreto casuale per richiesta)
  5. Protezione delle pagine vulnerabili con CSRF
  6. Lunghezza nascosto (aggiungendo un numero casuale di byte alle risposte)
  7. Limitazione della velocità delle richieste
risposta data 11.10.2013 - 09:55
fonte

Leggi altre domande sui tag

Quali sono i principali problemi che riguardano il Dalvik VM di Android? Gli script personalizzati generici evitano il rilevamento più delle applicazioni di sicurezza comuni?