Memorizzazione di token anti-CSRF nel cookie

Dici "sessione" - hai una sessione lato server? In tal caso, perché non inserire il token CSRF nella sessione anziché un cookie sul lato client? Questo è il modello normale; impedisce a un utente malintenzionato di utilizzare il proprio valore di token CSRF generato contro un altro utente nel caso in cui abbia la correzione dei cookie.

Un altro approccio a tenuta stagna che non richiede un cookie aggiuntivo, se non si dispone di storage sul lato server, è quello di creare un valore che includa l'ID utente o sessione e firmarlo utilizzando un MAC (tipicamente HMAC) con un lato server segreto. Il server può quindi verificare che il token nel modulo proviene dall'utente di cui è la sessione.

attacker can't read or set the cookie of a domain that he doesn't own

Beh, probabilmente ... di solito. Modi che l'iniezione di cookie tende ad accadere (oltre all'XSS, nel qual caso hai già perso molto peggio):

• bug del browser, tabelle / regole del dominio generico "obsolete"
• domini vulnerabili vicini (ad esempio, impostare cookie su www.example.com da test.example.com)
• che consente di pubblicare il tuo sito da un dominio di un utente malintenzionato (controlla sempre il nome host: è un nome di dominio riconosciuto)

Questi sono problemi tipicamente marginali ma dipendono da fattori potenzialmente al di fuori del controllo come autore di applicazioni. Quindi per i sistemi sensibili alla sicurezza è generalmente una buona idea non fare affidamento sul fatto che i cookie siano non fissi.

Puramente come un meccanismo anti-CSRF che mi sembra ragionevole. La protezione standard consiste nell'utilizzare un token casuale in un campo modulo nascosto e quindi controllarlo all'invio, quindi mi sembra che l'unica differenza nel tuo schema sia che invece di tenere quel token lato server lo stai confrontando con un token in un cookie. La soluzione che hai trovato suona piuttosto come l'opzione "Double Submit cookies" dal OWASP Anti -CSRF Cheatsheet

Ovviamente se ci sono altri problemi nella tua applicazione (ad esempio Cross-Site Scripting) è probabile che tu abbia problemi, ma poi l'XSS causa tutti i tipi di problemi.

Secondo i miei punti di vista questa implementazione non è completamente sicura, poiché è solo la convalida che il valore di cookie e il post param sono " stesso ed esiste ", e se c'è un CRLF Vulnerabilità dell'iniezione alias HTTP Response Splitting nell'applicazione che mi consente di impostare un altro cookie denominato "csrftoken = test" e il valore del parametro csrf post su "test" e inviare la richiesta - ignora il controllo csrf nel suo insieme dal entrambi i valori sono test e corrispondenze.

Correggimi se sbaglio.

Un utente malintenzionato può inviarti un collegamento che verrà aperto dal browser quando si ha una sessione nell'applicazione protetta. Questo può accadere anche mostrando le immagini in una email. In questo caso la richiesta dal tuo browser contiene il cookie di sessione ma non il token anti-CRSF e il server può invalidare la richiesta maliziosa dal browser della vittima. Il token di CSRF deve vivere nella sessione del server e nella pagina html, non nel cookie inviato molto tempo dal client. È inoltre consigliabile rigenerare il valore ad ogni richiesta (token una tantum) e chiedere nuovamente le credenziali di accesso per richieste speciali (cambiare password, applicare il filtro e-mail ecc.).