Diciamo che il sito Web esempio.com ha una protezione CSRF. Invia un token CSRF in un'intestazione personalizzata e in campi di input nascosti.
Ad esempio per aggiungere una nuova cartella, la tua richiesta http deve contenere un token CSRF. Quello che ho osservato è che se fai la stessa richiesta, con il token CSRF ma senza un cookie di sessione, funziona ancora.
Se funziona in questo modo, posso creare una cartella senza cookie di sessione, ma solo con token CSRF?
In generale, no.
La protezione CSRF e l'autenticazione di sessione dovrebbero in genere essere completamente concetti separati. La responsabilità di un token CSRF è supposto essere una chiave una tantum per una richiesta - nient'altro, mentre un ID sessione o token di sessione è supposto per identificare semplicemente un utente che ha il permesso di eseguire l'azione in primo luogo.
Dovresti averli entrambi sul posto, a meno che il token CSRF mantenga entrambe le responsabilità in qualche modo (che onestamente, indicherebbe che qualcuno ha cercato di essere troppo intelligente con il loro design di sicurezza, e fallito).
Uno interessante. Se il token CSRF identifica anche l'utente, non riesco a vederlo come una vulnerabilità di per sé. Alcuni sistemi possono funzionare senza cookie (sebbene tu dica che questo è progettato per funzionare con con i cookie ) e possono passare attorno a un token di autenticazione in un campo modulo nascosto che viene utilizzato sia come identificatore di sessione sia come anti- Token CSRF.
Nel tuo caso, poiché il sistema utilizza i cookie, sembra essere un difetto di autorizzazione.
Dovresti provare qualche altro test per scoprire se si tratta di una vulnerabilità:
Nota per creare due sessioni avresti bisogno di un browser separato o potresti crearne una in privato / in incognito.
Per "sessione attiva" mi riferisco a una sessione corrente a breve termine sul sito web (ad esempio, una scadenza scorrevole di 15-30 minuti circa). Per i siti che implementano la funzionalità "ricordami", questo dovrebbe essere implementato da un meccanismo diverso che crea una nuova "sessione attiva" ogni volta che l'utente torna e un nuovo token CSRF che lo accompagna (piuttosto che creare solo una lunga sessione attiva).
Se uno dei problemi precedenti ha ancora successo, hai scoperto un difetto di gestione della sessione.
Scenario 1: se il token viene generato utilizzando un PRNG crittograficamente sicuro, un attacco di base come descrivi non è possibile, incluso se il token di sessione non viene inviato attraverso quella particolare richiesta - non lo fa lavoro pure - quindi nel complesso questo non funziona.
Scenario 2: Tuttavia, se i token generati dalla tua applicazione non sono forti e sono ignorati, questo dovrebbe funzionare ma fallirebbe se i token di sessione non lo seguissero, sempre come indicato da @ AgmLauncher nella sua risposta.
Scenario 3 : il token CSRF ha esito negativo + hai il token di sessione, ad esempio tramite XSS: funziona.
Leggi altre domande sui tag web-application xss csrf