Quando dovrei generare un nuovo token CSRF

Question

Quando dovrei generare un nuovo token CSRF

Naviga le tue risposte

#1 da (4 voti)

8

Sto costruendo un metodo di prevenzione CSRF nel nostro framework applicativo. Io uso, tra l'altro, il sito OWASP .

Abbiamo scelto il meassure di prevenzione "Double Submit Cookies", descritto al OWASP Scheda cheat CSRF

Gli stati del cheat sheet:

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value...

Sembra che un utente debba effettuare il login per primo, prima di generare il token CSRF (ovvero "valore pseudocasuale crittografato").

Ma come posso proteggere i moduli accessibili senza autenticazione? Pensa alla "password dimenticata" e al modulo di accesso.

Penso che il testo dovrebbe essere "Quando un utente inserisce un sito, il sito dovrebbe generare un valore pseudocasuale (crittograficamente strong) ..."

Questo è anche più facile da implementare, come ho fatto nel modo seguente:

L'applicazione recupera la richiesta GET: genera un cookie CSRF (di sessione) (se il cookie non è già presente nella richiesta)
(else) L'applicazione richiama la richiesta non GET (POST, PUT, ecc.): convalida il cookie CSRF con il token CSRF nella richiesta.

Mi manca un aspetto importante qui?

csrf

posta Julian 15.12.2014 - 21:40

fonte

1 risposta

Leggi altre domande sui tag csrf

Implicazioni sulla sicurezza dell'uso della codifica Base64 con crittografia Importa la piattaforma su cui un file viene scansionato per rilevare malware?

score 4 · Accepted Answer

In genere, non si proteggono i moduli accessibili senza autenticazione. Lo scopo di un attacco CSRF è in genere che un utente malintenzionato manipoli un utente autenticato per eseguire un'azione sul sito con i dati dell'aggressore e la sessione autenticata dell'utente vittima. I moduli che non richiedono l'autenticazione in genere non sono vulnerabili a essere manipolati in questo modo.

Quindi, le mitigazioni CSRF sono tipicamente incorniciate usando un linguaggio che presuppone / richiede all'utente di essere autenticato in modo che la vulnerabilità esista. Lumping di moduli non autenticati in modifiche del modello di minaccia a uno che può essere valido per una determinata interazione, ma non standard.

Il tuo approccio

Formare una prospettiva di sicurezza, il tuo approccio sembra buono. Elimina la possibilità di generare un POST o PUT senza un GET precedente, ma per un'interfaccia basata su browser che in genere non dovrebbe essere un problema, e per questo specifico modello di minaccia, è esattamente ciò di cui hai bisogno.