Ho una richiesta che utilizza un token una tantum incorporato nella pagina per garantire la protezione CSRF - un utente malintenzionato potrebbe ingannare i miei utenti a fare una richiesta illecita, ma non può ottenere il token e anche se essi può essere cambiato con ogni richiesta e può scadere.
Finora, così sicuro.
Voglio implementare la sincronizzazione in background con un operatore del servizio, in modo che un utente possa pubblicare dati offline e quindi inviarli successivamente quando ottengono una connessione.
Tuttavia, ciò significa che la pagina non è disponibile per ottenere il token CSRF e qualsiasi token collegato con la richiesta quando l'utente lo crea potrebbe non essere valido al momento dell'invio effettivo dei dati.
Questo sembra essere un problema generale con qualsiasi sito web progressivo, qual è la migliore pratica per gestirlo?
Penso che la sincronizzazione in background possa richiedere un nuovo token, applicarlo ai dati da inviare e quindi inviarlo, e che sia ancora un loop che un utente malintenzionato di CSRF non può sfruttare, ma non lo sono certo. Qualcuno può confermare questo in entrambi i modi?
Al momento i token CRSF assicurano che la richiesta provenga da una pagina specifica, che dovrà essere modificata affinché qualsiasi processo in background funzioni. Invece ci sarà una sorta di servizio token CSRF, quindi saremo in grado di garantire che l'utente sia stato in precedenza e recentemente in grado di fare una richiesta da quel servizio. E 'ancora una protezione adeguata contro CSRF?