Fornire un token CSRF al front-end, se non presente nelle intestazioni della richiesta

Question

Fornire un token CSRF al front-end, se non presente nelle intestazioni della richiesta

#1 da (1 voti)

1

Ho un'app web in cui, quando gli utenti richiedono una pagina, viene generato un token CSRF e immesso nella pagina jsp in un campo input nascosto.

Lo stesso token viene quindi inviato al server per ogni chiamata AJAX in un'intestazione personalizzata mentre, un token dello stato sessione è contenuto in un cookie ( secure + httpOnly ).

Ora, dato che il token CSRF è qualcosa di nuovo nella webapp, se dopo l'aggiornamento l'utente era già loggato e lui invia una richiesta, un Filter determinerà che è effettivamente registrato (a causa della sessione -state token nel cookie), ma un token CSRF valido non è contenuto nell'intestazione personalizzata, quindi il comportamento definito è di disconnetterlo.

Potrei occuparmi di questo, seguendo questo esempio OWASP . Se non è presente un token CSRF , ho intenzione di inviare una richiesta NO-CONTENT indietro e in qualche modo fornire il token.

Ecco il primo dubbio:

Il tag CSRF non deve essere inserito in un cookie ?.

Inoltre forniscono un token CSRF indietro se manca nella richiesta, il che mi sembra un po 'di anti-secure : un utente malintenzionato potrebbe aver rubato il token di sessione da cookie , inviare una richiesta e ricevere magicamente il token CSRF indietro.

Mi sento quindi confuso qui.

Devo solo inserire il token CSRF nel cookie lungo il token di stato della sessione?
Dovrei evitare di fornire un token CSRF se non ne è impostato nessuno, ma esiste un cookie di stato sessione?
Quale può essere una soluzione alternativa per il mio caso?

Note:

Prima di controllare il token CSRF, verifico le intestazioni origin e referer , come consigliato qui .

Non ho intenzione di implementare un token CSRF use-only-one-per-request .

Sebbene irrilevante in questo contesto, la comunicazione avviene tramite HTTPS

java cookies appsec csrf

posta Marko Pacak 24.01.2018 - 11:42

fonte

1 risposta

Leggi altre domande sui tag java cookies appsec csrf

Quanto tempo dovrebbe essere valida una JWT in un servizio conforme a PCI-DSS? C'è un modo per dire, guardando un pacchetto, che è successo un attacco aircrack-ng?

score 1 · Accepted Answer

Esistono diversi modi per risolvere una vulnerabilità CSRF. L'implementazione che stai guardando utilizza un metodo stateless di gestione del token CSRF . Questo è chiamato il doppio metodo del cookie inviato. Questo ti consente di risparmiare qualche sforzo se non desideri monitorare il token CSRF sul lato server.

Dal link OWASP che hai condiviso nella domanda:

A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

Il rischio per la sicurezza sorge quando il token CSRF risiede solo nel cookie e da nessun'altra parte. Questo non sarebbe sufficiente per la prevenzione CSRF in quanto sarebbe la stessa cosa di avere un altro cookie di sessione.

Nell'implementazione del cookie inviato doppio devi solo assicurarti che i valori dei token ricevuti dal cookie e dal parametro del modulo siano gli stessi. In caso di attacco CSRF, la richiesta falsificata conterrà il token nel cookie ma il valore del token dal parametro from / custom header sarà assente. Quindi porta al rilevamento e alla prevenzione della CSRF.

Per rispondere alla tua altra domanda sulla restituzione di un token CSRF se la richiesta è autenticata ma non contiene già un token. Questo dipende interamente dal tipo di esperienza utente che vuoi che i tuoi utenti abbiano. In alcuni casi può essere corretto reindirizzare l'utente a una pagina di accesso.

Supponiamo che tu restituisca il token nel cookie e che ci sia un tentativo CSRF. In tal caso Same Same Policy impedirebbe a qualsiasi dominio dannoso di accedere a il valore del cookie direttamente e quindi la successiva richiesta falsata fallirebbe per gli stessi motivi sopra riportati.

Per ulteriori considerazioni sulla sicurezza in caso di implementazione di cookie con doppia presentazione:

Doppia vulnerabilità dei cookie di invio