È considerato un CSRF se richiede un identificatore univoco che non è un token CSRF - non legato alla sessione utente?

Question

È considerato un CSRF se richiede un identificatore univoco che non è un token CSRF - non legato alla sessione utente?

#1 da (2 voti)
#2 da (-1 voti)

1

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 ).

link

È 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.

Riferimento OWASP

web-browser web-application session-management csrf

posta ServerBloke 29.11.2014 - 16:22

fonte

2 risposte

Leggi altre domande sui tag web-browser web-application session-management csrf

è sicuro usare proxychains + tor mentre si è loggati come root È CAST5-CBC supportato da OpenSSL un metodo di crittografia autenticato?

score 2 · Answer 1

Ci sono tecniche di prevenzione CSRF che non si basano su un token CSRF associato alla sessione , dopotutto non c'è più che un modo per scuoiare un gatto. Quando si considera un sistema di protezione CSRF, cercare qualsiasi collegamento che non esiste con il modello di token di sincronizzazione CSRF comunemente usato. Ci sono tre problemi con questo sistema di protezione CSRF proposto.

Scadenza - CSRF è anche chiamato "session riding", in un certo senso un token CSRF è molto simile a un id di sessione, soprattutto entrambi devono scadere . La preoccupazione è che a un utente malintenzionato sia permesso di indovinare il valore esatto del token CSRF per un periodo di tempo illimitato.

Ripristino da attacchi : è possibile utilizzare XSS per ottenere qualsiasi valore su qualsiasi pagina utilizzando un XMLHTTPRequest() , che include token CSRF. Una volta che l'utente malintenzionato ha il token CSRF, è consentito viaggiare sulla sessione della vittima indefinitamente, perché non scade mai.

Perdita di informazioni del referer - L'invio del token CSRF nell'URL è un comportamento rischioso. Se in qualsiasi momento un utente malintenzionato può controllare il href di un tag <a> o il src di un tag <img> , un utente malintenzionato può forzare i browser a caricare il contenuto da un server Web controllato dall'utente malintenzionato, consentendo così l'attaccante per registrare il referente HTTP, che conterrà il token CSRF della vittima.

score -1 · Answer 2

Se l'ID indirizzo potrebbe essere generato da un indirizzo specificato (ad esempio, se l'ID indirizzo è una rappresentazione binaria di lat / long dell'indirizzo specificato che è quindi codificato Base64 e quindi convertito avanti e indietro tramite un servizio di geolocalizzazione ), quindi hai lo stesso rischio di CSRF come originariamente.

Ma se l'ID è casuale, sei al sicuro da CSRF.

Devi codificare la tua applicazione web per rifiutare qualsiasi query con un ID non esistente o con un ID che non appartiene all'utente in questione.

Non importa se crittografate un ID indirizzo geolocalizzato, perché l'autore dell'attacco riceve semplicemente il vecchio ID indirizzo semplicemente inserendo l'indirizzo originale della vittima nell'account degli autori degli attacchi e quindi l'ID da utilizzare per modificare l'indirizzo delle vittime .

Quindi è necessario utilizzare un ID completamente casuale per essere sicuro.