Con cookie anonimi

Se sei felice di generare token sicuri che sono impostati come cookie di utenti anonimi, ma non di archiviarli lato server, potresti semplicemente invio doppio cookie .

es. Utente legittimo:

1. Anon utente naviga verso la pagina di login, riceve il cookie che viene inviato al browser.
2. Anon esegue l'accesso e il browser invia il cookie come intestazione e come valore nascosto del modulo.
3. Utente ora loggato

Questo non può essere maltrattato dall'attaccante in quanto ora succederà:

1. L'utente malintenzionato crea un account host nel dominio trusted
2. L'utente malintenzionato crea una richiesta di accesso nel browser della vittima con le credenziali dell'account host Tuttavia, l'utente malintenzionato non ha accesso al valore del cookie della vittima e non può crearlo come token CSRF nel corpo della richiesta. L'attacco fallisce.

Anche se il tuo sito è accessibile solo tramite HTTPS e imposti correttamente la Bandiera protetta , devi fare attenzione con questo approccio come attaccante potrebbe potenzialmente MiTM qualsiasi connessione dalla vittima a qualsiasi sito Web HTTP (se l'autore dell'attacco è opportunamente collocato, ovviamente), reindirizzali al tuo dominio su HTTP, che è anche MiTM e quindi imposta il valore del cookie richiesto. Questo sarebbe un attacco Correzione della sessione . Per evitare questo, è possibile visualizzare il valore del cookie nell'intestazione e nel campo modulo nascosto ogni momento in cui questa pagina (di accesso) viene caricata (su HTTPS) anziché riutilizzare un valore di cookie già impostato. Questo perché sebbene un browser possa impostare il Flag sicuro, invierà comunque i cookie senza il Flag sicuro su una connessione HTTPS e il server non sarà in grado di stabilire se è stato impostato il Flag sicuro. (Gli attributi dei cookie come il Flag di sicurezza sono visibili solo quando il cookie è impostato, non quando viene letto. L'unica cosa che il server può vedere è il nome e il valore del cookie.) Implementazione di HSTS sarebbe una buona opzione per la protezione nei browser supportati.

Si consiglia di impostare X-Frame-Options a prevenire un attacco di tipo click jacking (altrimenti l'attaccante potrebbe usare la funzionalità del sito per riempire il proprio nome utente e password in attesa che l'utente clicchi e li invii insieme al valore CSRF).

Senza cookie anonimi

Se non si desidera impostare i cookie per gli utenti anonimi (che potrebbero quindi sospettare di essere monitorati dal lato server), è possibile utilizzare il seguente approccio: Un modulo di accesso a più fasi.

Il primo stadio è la solita combinazione nome utente / password.

Dopo che il modulo è stato inviato, reindirizza a un altro modulo. Questo modulo è protetto da un cookie di token di autenticazione intermedia speciale e un token CSRF. L'autenticazione qui consentirà l'inoltro dell'autenticazione della seconda fase, ma non consentirà altre azioni sull'account (tranne eventualmente un logout completo). Questo abiliterà il token CSRF ad essere associato e utilizzato da questo account utente solo su questa sessione intermedia.

Ora è solo quando viene inviato questo modulo, inclusi il token cookie e il valore nascosto del modulo CSRF che l'utente è completamente autenticato con il dominio. Qualsiasi utente malintenzionato che tenta un attacco CSRF non sarà in grado di recuperare il token CSRF e il suo tentativo di accesso completo avrà esito negativo.

L'unico inconveniente è che l'utente dovrà fare clic manualmente per completare il login, che può essere un'esperienza utente goffo. È consigliabile impostare X-Frame-Options per evitare che questo sia usato in combinazione con un attacco di click jacking di riparazione dell'interfaccia utente. Qualsiasi invio automatico con JavaScript sarebbe vantaggioso per l'utente malintenzionato e farebbe sì che il loro attacco potesse avere successo, quindi al momento posso vedere solo un clic manuale da parte dell'utente che lavora.

Ora funzionerebbe in questo modo:

1. L'utente malintenzionato crea un account host nel dominio trusted
2. L'utente malintenzionato crea una richiesta di accesso nel browser della vittima con le credenziali dell'account host ma non può procedere oltre la fase due per diventare completamente autenticato
3. L'hacker induce la vittima a utilizzare il sito attendibile - ma poiché non sono completamente autenticati, il sito agirà come se l'utente non fosse autenticato

Quindi un requisito leggermente di nicchia, ma hey un CSRF valido. Ci sono un paio di scelte su come puoi rispondere a questo che mi viene in mente

• Tecniche di anti-automazione standard come un CAPTCHA. Ovviamente non è il più facile da usare delle soluzioni, ma può aiutare a mitigare altri attacchi contemporaneamente.
• Avere un token anti-CSRF standard che è legato alle informazioni fornite dal client, che è pre-autenticazione disponibile. Un'opzione ovvia sarebbe quella di legarlo all'indirizzo IP sorgente. Non è perfetto (i sistemi dietro i proxy avrebbero lo stesso indirizzo) ma ridurrebbe il rischio un po '. Un'altra opzione sarebbe quella di legare il token a specifiche identità del browser. Se guardi Panopticlick puoi vedere che i browser forniscono informazioni identificative in modo che sia possibile creare un'impronta digitale basata su quella e emettere un Anti Token -CSRF per ogni impronta digitale che contatta il sito. Di nuovo non perfetto ma rende l'attacco più difficile da eseguire.

Vorrei proporre una variante del Pattern token crittografato che funziona come segue: quando un client richiede una pagina HTML che richiede la protezione CSRF ...

1. Il server verifica l'esistenza di un cookie sessionId . Se manca, il server imposta un nuovo cookie HttpOnly contenente un valore pseudocasuale crittograficamente strong. Nota che questo valore non è memorizzato sul server ma protegge ancora contro l'accesso CSRF (un utente malintenzionato non può autenticarsi senza passare attraverso il modulo di accesso).
2. Se l'utente è disconnesso, restituire una pagina HTML che attiva l'autenticazione per operazioni non sicure. Torna al passaggio 1.
3. Se l'utente ha effettuato l'accesso, il server crittografa [sessionId + nonce] utilizzando una chiave segreta e incorpora il valore (che chiameremo csrfToken ) nel file HTML. Non è importante dove csrfToken è incorporato, a condizione che la funzione Form o Javascript che effettua la richiesta possa accedervi. nonce è un valore pseudocasuale crittograficamente strong utilizzato per prevenire attacchi brute-force sulla chiave segreta, ma non viene utilizzato durante il processo di convalida.
4. I moduli inviano csrfToken utilizzando un campo nascosto con lo stesso nome. Le funzioni Javascript presentano csrfToken utilizzando un'intestazione di richiesta personalizzata denominata csrf-token .
5. Il server decrittografa csrfToken e confronta il suo valore con sessionId . Se i due non corrispondono, il server restituisce 401 Unauthorized e attiva l'autenticazione.

Puoi applicare una qualsiasi delle tecniche anti-CSRF standard, che si tratti del modello di token sincronizzatore o di doppio invio. Il primo è generalmente più sicuro, perché i cookie possono essere sovrascritti dai sottodomini.

Hai affermato che il pattern token sincronizzatore funziona solo dopo l'autenticazione, ma non è questo il caso. Un utente malintenzionato non ha accesso al token di un utente, indipendentemente dal fatto che l'utente sia autenticato o meno.

Ovviamente l'attaccante può visitare la pagina di accesso e ottenere un token anti-CSRF valido. Ma questo token solo funziona per l'attaccante. Se la vittima fa una richiesta, allora il token non viene accettato, perché non è presente nella sessione della vittima. Infatti, la sessione sarà completamente vuota alla prima richiesta.