Che cosa definisce una vulnerabilità CSRF?

Question

Che cosa definisce una vulnerabilità CSRF?

#1 da (8 voti)

2

Come parte della mia posizione presso la società con cui sono impiegato, eseguo manualmente il test di penetrazione della nostra applicazione web (ancora in sviluppo) per le vulnerabilità. Durante i test, ho provato a vedere se la nostra applicazione Web era vulnerabile a CSRF. Per farlo, ho eseguito l'applicazione nella scheda A e autenticato con l'app Web. Nella scheda B ho aperto la console JavaScript e ho eseguito:

window.location.replace("http://privilegedLocationInWebApp.com");

Il reindirizzamento ha avuto esito positivo, indirizzando la scheda B a una pagina autenticata all'interno dell'applicazione Web.

Più tardi nel corso della giornata a casa, ho deciso di giocare e vedere quali altri siti sono vulnerabili a questo in quanto mi ha colpito come qualcosa che è probabilmente trascurato e testarlo non causa alcun danno alla pagina web (cioè non sto provando SQL li inietta o fa danni). Il tentativo di reindirizzare tale scheda su una scheda non autenticata con una scheda separata già autenticata ha avuto esito positivo su più siti, alcuni dei quali sembrano essere un po 'troppo importanti per consentire tale vulnerabilità.

Questa è davvero una vulnerabilità della CSRF? O è semplicemente trascurato dai proprietari di siti Web e app web poiché queste richieste sono tutte richieste GET ma un tentativo di eseguire un POST potrebbe essere rifiutato in quanto ciò rappresenterebbe una vera vulnerabilità CSRF?

web-application vulnerability csrf

posta dFrancisco 15.01.2018 - 15:24

fonte

1 risposta

Leggi altre domande sui tag web-application vulnerability csrf

È possibile conoscere la chiave se abbiamo il valore originale e l'hash utilizzando HmacSHA1? Perché Chrome mi dice che la direttiva CSP 'require-sri-for' è implementata dietro un flag che è attualmente disabilitato?

score 8 · Accepted Answer

Qui ci sono una serie di equivoci:

Le schede non possono essere "autenticate" o "non autenticate". Se si utilizzano sessioni basate su cookie per l'autenticazione, è la presenza del cookie di sessione che consente l'accesso. Quel cookie appartiene alla sessione del browser e non a una scheda specifica.
Caricamento di una "posizione privilegiata", ovvero una pagina a cui un utente non autenticato non dovrebbe avere accesso, non è una prova di CSRF.

La vittima potrebbe aprire una nuova scheda, inserire l'URL nella posizione privilegiata e avere accesso ad essa, giusto? Tutto quello che hai fatto è farlo con un po 'di JavaScript. Come hai potuto, come attaccante, sfruttare questo? Non potresti! Il principio Single Origin del browser ti impedisce di leggere qualsiasi dato e non hai indotto il server a eseguire un'azione.

Quindi cosa rappresenterebbe la corretta CSRF? Affinché ciò sia utile, devi fare in modo che il server faccia qualcosa: creare un utente, eliminare un post, modificare un'impostazione, qualunque cosa. Come dici tu, normalmente richiederebbe una richiesta POST, ma su una pagina progettata male potrebbe essere possibile anche con GET. Ad ogni modo, questo è quello che dovresti cercare!