Protezione CSRF per AJAX quando si utilizzano più schede del browser

Naviga le tue risposte
9

Diciamo che ho quell'applicazione web che ha una protezione CSRF secondo Pattern token di sincronizzazione . Il server si aspetta un token CSRF valido in ogni richiesta POST quando l'utente è autenticato. Ora immagina il seguente scenario:

  1. L'utente apre una scheda del browser (scheda anonymous ) e avvia alcune funzionalità AJAX che periodicamente legge dal server (ad esempio un timestamp). L'utente non è autenticato in questa scheda.

  2. L'utente apre una nuova scheda del browser (scheda authenticated ) ed esegue un accesso lì. Se ora carica il framework AJAX, il token CSRF viene scritto nel codice sorgente del framework AJAX da parte del server include e viene memorizzato nella variabile token .

  3. Se il prossimo sondaggio automatico viene eseguito dalla scheda anonymous , il cookie di sessione viene inviato indicando un utente connesso ma questa scheda non ha mai ricevuto un token CSRF poiché il framework AJAX è stato caricato prima eseguire il login sulla scheda authenticated .
    Ciò comporterà un errore generato dal server perché ha ricevuto un token di sessione valido senza token di protezione CSRF.

Come posso superare questo?

Modifica
Le cose peggiorano ancora se l'utente

  • esegue un login nella scheda 1 ( user1 )
  • apre la scheda 2
  • esegue un logout nella scheda 2
  • esegue un nuovo accesso nella scheda 2 (utente diverso, user2 )

In questo caso, la prima scheda fornisce il token CSRF precedentemente valido di user1 ma il cookie di sessione inviato appartiene a user2 registrato nella scheda 2. Questo deve portare a un errore emesso dalla protezione CSRF (a proposito, in termini di codici di errore HTTP: cosa usare? 403 sembra come se potesse essere usato, ma non sono sicuro).

Sentirsi ora come l'intera cosa CSRF potrebbe essere risolta in modo molto bello in teoria, ma potrebbe usare un po 'di riflessione in tempi di AJAX.

Esiste una soluzione canonica per il problema sopra descritto? Oppure gli utenti accettano semplicemente di dover ricaricare una pagina a causa di elementi di sicurezza - cose che non ti piacciono?

    
posta eckes 12.11.2012 - 09:04
fonte

2 risposte

4

Potresti avere un flag nelle tue richieste anonime per far sapere loro che sono sempre trattati come anonimi, nonostante la presenza del cookie di autenticazione.

es. { "Anon" : "true" }

Ciò causerà sempre la restituzione dei risultati pubblici della richiesta e nessun log auth o CSRF token di richiesta verrà considerato nella logica.

    
risposta data 12.11.2012 - 10:21
fonte
0

Per quanto ho visto, tutte le schede del browser e le finestre aperte sullo stesso sito web condividono gli stessi dati dei cookie. Un cookie impostato in una scheda è visibile in tutte le altre schede.

Per quanto riguarda la protezione CSRF in un'azione POST HTTP, c'è un valore incorporato nell'output HTML. Puoi includere un valore in HTML che ottiene il POST indietro che può dire al back-end di ignorare qualsiasi token di autenticazione che potrebbe essere presente.

Dovresti aggiungere questo token HTML a ogni pagina web che utilizza la protezione CSRF e aggiornare ogni POST di Javascript per inviare questo valore quando si gestiscono richieste di servizio.

È un po 'peloso, a seconda di quanto sia complesso il tuo sito, ma può essere fatto.

    
risposta data 13.11.2012 - 00:01
fonte

Leggi altre domande sui tag

Hai ancora problemi con lo scrypt? Esiste un database pubblico di nomi mutex associati al malware?