Protezione CSRF e app per pagina singola

25

Sto scrivendo un'app web client spessa utilizzando Angular.js (app per pagina singola) e mi chiedevo quali sono le migliori pratiche per proteggere l'app utilizzando un token CSRF.

Devo inviare un token CSRF quando l'app viene caricata per la prima volta, quindi riutilizzare quel token ad ogni richiesta? Dovrei avere un meccanismo per aggiornare il token? Esistono altre protezioni piuttosto che un token CSRF che avrebbe più senso per un'applicazione per una sola pagina?

    
posta Olivier Lalonde 25.05.2013 - 18:31
fonte

2 risposte

17

Bene ecco come ho finito per implementare CSRF:

Alla prima richiesta, imposta un token CSRF come cookie. Ogni successiva richiesta AJAX include il token CSRF come intestazione HTTP X-CSRF-Token .

Django ha una buona documentazione su come farlo in modo pulito con jQuery: link

Modifica: un approccio alternativo prevede che le whitelist contengano l'intestazione X-Requested-With . Sembra che sia che cosa Rails . Ma come @damio ha sottolineato di seguito, il X-Requested-With è un rischio per la sicurezza, Django e Rails ripristinati torna a non usarlo e forzare un token.

    
risposta data 26.05.2013 - 05:40
fonte
14

Sei fortunato! Circa 2 settimane fa mi è stata fatta la stessa domanda, e dopo un po 'di grattacapi mi è venuta in mente quanto segue. Si prega di tenere presente che questo non è ben recensito, quindi vedremo come andranno i commenti e le votazioni. Personalmente, penso che sia una buona tecnica.

1. Prima richiesta

Una volta ricevuta la prima richiesta di caricamento dell'applicazione, generare un identificatore casuale sicuro e memorizzarlo in una variabile di sessione sul server, quindi inviarlo al client. Lo incorporerei nella pagina appena prima </body> .

<script>setToken('<% print SESSION[TOKEN] %>');</script>
</body>

Il tuo setToken() assegnerebbe il valore del token alla variabile in cui manterrai il token.

2. Richieste successive

Ad ogni richiesta aggiungerai quel token all'elenco dei parametri, come token=TOKEN , e il servizio lo controllerebbe rispetto a quello memorizzato nella variabile di sessione.

3. Aggiornamento del token

Non è veramente obbligatorio, ma è una buona idea aggiornare il token ogni tanto, diciamo 15 minuti. Quando ricevi una richiesta dopo che il token scade (hai tempo di scadenza nella variabile di sessione), rispondi normalmente (agisci ottimisticamente) ma nella risposta dici al client che il vecchio token è scaduto e dovrebbe iniziare a usare il nuovo.

Il client reagisce dicendo al server che ora conosce il nuovo token, una volta che il server riceve quella richiesta inizia ad usare il nuovo token e risponde al client con un messaggio OK, una volta che il client riceve 200 OK significa che sono entrambi sincronizzati e che il client inizia a utilizzare il nuovo token.

Nota: un elemento chiave del processo è l'utilizzo HTTPS. Non vuoi un uomo in mezzo per annusare il token. Ma poi di nuovo, un MitM sarebbe in grado di fiutare i cookie e dirottare comunque la sessione.

    
risposta data 25.05.2013 - 20:47
fonte

Leggi altre domande sui tag