Un CSRF non autenticato è ancora un CSRF?

Question

Un CSRF non autenticato è ancora un CSRF?

#1 da (1 voti)

4

OWASP definisce Cross-Site Request Forgery (CSRF) come

an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.

(sottolineatura mia)

Un esempio di attacco è il collegamento http://example.com/logout inviato a un utente autenticato che, dopo aver fatto clic su di esso, viene disconnesso. Siamo riusciti a modificare lo stato del sistema (in questo caso, l'accesso dell'utente) facendo clic su un link che gli abbiamo fornito.

Ora immagina un sistema di votazione in cui tutti possano votare, indipendentemente dal fatto che siano autenticati o meno. Il sistema non tiene traccia di chi ha votato (che è ovviamente un problema).

Posso riprodurre senza limitazioni le chiamate HTTP che aumenteranno il contatore delle votazioni. L'invio di tale replay si collega a qualcun altro che farebbe clic su di esso senza effettuare il login e aumentare il contatore delle votazioni come vulnerabilità CSRF?

La mia opinione è che questo è non un CSRF perché:

ci manca la parte "autenticata" della definizione (che sarebbe per la semantica)
Credo che l'intento di questa classificazione fosse di evidenziare che un utente malintenzionato può farti eseguire comandi che altrimenti non avrebbe potuto fare (perché devi essere autenticato). Il caso del voto non autenticato sopra è IMO meglio descritto da A4 (Broken Access Control)

vulnerability csrf owasp owasp-top-ten

posta WoJ 22.04.2017 - 13:01

fonte

1 risposta

Leggi altre domande sui tag vulnerability csrf owasp owasp-top-ten

Installazione pulita: file di rischio relativi alla sicurezza Stop DNSSpoof dopo il login

score 1 · Accepted Answer

Would sending that replay link to someone else who would (without being logged in) click on it and increase the voting counter be considered as an CSRF vulnerability?

Controllo della 2013 della voce OWASP su CSRF , il loro scenario di attacco ( a mio avviso) sembra descrivere qualcosa di simile al tuo esempio:

The application allows a user to submit a state changing request that does not include anything secret. So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control

Nel caso dell'esempio, poiché non è richiesta alcuna autenticazione, tale scenario è valido in tutti i casi: un utente malintenzionato può indurre un utente a inviare una richiesta al suo sito, che causerà una modifica dello stato.

Penso che la menzione di OWASP della sessione autenticata rifletta un'ipotesi da parte loro su ciò che sarebbe necessario per effettuare cambiamenti di stato su un sito. Non credo che l'autenticazione sia in realtà parte della definizione di CSRF - la voce di wikipedia su CSRF menziona:

CSRF commonly has the following characteristics:

It involves sites that rely on a user's identity.

It exploits the site's trust in that identity.

It tricks the user's browser into sending HTTP requests to a target site.

It involves HTTP requests that have side effects.

Quindi penso che potresti considerare la tua applicazione vulnerabile a CSRF: un utente può essere costretto a pubblicare una richiesta con effetti collaterali, e quella richiesta avrà sempre successo (e potrebbe, almeno in teoria, essere legata a l'IP dell'utente, ad esempio).

Non sono sicuro che CSRF sia puramente che permetta a un utente malintenzionato di "fare qualcosa che altrimenti non potrebbero" - Penso che si possa sostenere che si tratta di fare un utente che potrebbe non aver fatto altrimenti .