Considera un punto finale come di seguito. Immaginiamo che questo endpoint aggiorni un indirizzo dell'utente che ha eseguito l'accesso, modificando il codice postale. L'indirizzo da aggiornare è identificato dall'ID dell'indirizzo ( kUj3Nkg10
).
È importante sottolineare che l'identificatore è una stringa alfanumerica, non un numero intero incrementale. Se si trattava di un intero incrementale, allora potrebbe essere previsto. L'alfanumerico non può essere previsto o indovinato ragionevolmente.
Per chiarire, nell'esempio, l'ID dell'indirizzo è stato generato casualmente, ma una volta che esiste, non cambia mai. L'ID non è basato su dati specifici dell'utente o dell'indirizzo.
Inoltre, un aggiornamento degli indirizzi è solo un esempio, non ha importanza per ciò che effettivamente fa la richiesta. Potrebbe essere l'aggiornamento di un numero di telefono o la rimozione di un indirizzo email. La chiave è che questo alfanumerico è usato per identificare l'entità e che nessun token CSRF è presente.
Argomento per considerarlo un CSRF
Un token CRSF vive e rimane valido per la sessione corrente (o forse anche più breve). L'ID univoco in questione rimane lo stesso (probabilmente per sempre). Pertanto è necessario utilizzare un token CSRF. È possibile che l'identificatore possa essere utilizzato altrove nell'app e reso disponibile per un altro utente.
Argomento per non considerarlo un CSRF
È improbabile che l'autore dell'attacco abbia mai ottenuto l'ID univoco. Potrebbe essere vicino ad essere altrettanto difficile da ottenere un token CSRF vero e proprio.
OWASP definisce un CSRF come:
Any application that accepts HTTP requests from an authenticated user without having some control to verify that the HTTP request is unique to the user's session.
Penso che l'esempio sopra soddisfi la definizione OWASP, perché l'ID indirizzo non è univoco per la sessione dell'utente.