Risultati del Pentest: attacco CSRF discutibile

Question

Risultati del Pentest: attacco CSRF discutibile

#1 da (46 voti)
#2 da (12 voti)
#3 da (2 voti)

26

Recentemente abbiamo avuto una delle nostre applicazioni web ripetute. Tutto è andato bene, tranne che per una vulnerabilità CSRF, ed è questa scoperta che ho un osso con cui scegliere.

Alcuni background: stiamo usando ASP.NET MVC e, tra le altre cose, usiamo CSRF protection funzionalità integrate. Il modo in cui funziona è strettamente in linea con quanto OWASP consiglia : by inclusi i cosiddetti "token di sincronizzazione", uno in un cookie HTTP e un altro in un input nascosto denominato __RequestVerificationToken :

<form action="/Home/Test" method="post">
  <input name="__RequestVerificationToken" type="hidden" 
    value="6fGBtLZmVBZ59oUad1Fr33BuPxANKY9q3Srr5y[...]" />    
  <input type="submit" value="Submit" />
</form>

Effettuiamo anche scansioni regolari di Acunetix e le scansioni non hanno mai trovato moduli non protetti da CSRF.

Ora, ciò che sostengono i pentesters è che sono stati in grado di "violare" la nostra protezione CSRF con il seguente codice:

<html>
  <body>
    <form action="https://our.site/support/discussions/new" method="POST">
      <input type="hidden" name="subject" value="Subject" />
      <input type="hidden" name="content" value="Content" />

      <input type="hidden" name="__RequestVerificationToken" 
        value="_e-upIZFx7i0YyzrVd[...]" />

      <input type="submit" value="Submit Request" />
    </form>
  </body>
</html>

L'inclusione del campo __RequestVerificationToken è ciò che mi infastidisce di più: per me, è come sostenere che un attaccante ha trasferito miliardi di dollari dal mio conto in banca perché gli ho dato volontariamente il mio iPhone con cui giocherellare, e lui ho visto la password monouso inviata dalla mia banca in un SMS.

Immagino che l'unico modo in cui questo attacco possa funzionare sia se non usassimo HTTPS, fossero vulnerabili all'XSS, stessimo usando cookie non HTTP e siamo stati negligenti con la stessa politica di origine. Nessuno dei quali è vero, dal momento che nessuna di queste vulnerabilità è stata riportata da alcun pentestore o Acunetix.

Quindi la domanda è: ho sbagliato e questa è una vulnerabilità CSRF legittima o no?

penetration-test csrf

posta Anton Gogolev 23.11.2016 - 08:48

fonte

3 risposte

Leggi altre domande sui tag penetration-test csrf

È possibile modificare l'intestazione http del tuo agente utente per uso dannoso? Come potrebbe Craig Wright ottenere la chiave privata di Satoshi Nakamoto? [chiuso]

score 46 · Answer 1

Questa non sembra essere una vulnerabilità CSRF.

Se un utente malintenzionato deve conoscere un token CSRF, non si tratta di un attacco. E il tuo approccio a CSRf sembra essere corretto.

I problemi che perdono il token CSRF possono effettivamente causare un attacco CSRF, ma il problema non è la protezione CSRF non corretta, ma tali problemi (XSS, crittografia, token CSRF nell'URL e così via).

Ancora, vorrei chiedere chiarimenti al tester. Chissà, forse l'attacco funziona sempre con quel token specifico, perché è codificato da qualche parte, o perché i caratteri speciali stanno causando un qualche tipo di problema per la tua applicazione. O forse è possibile utilizzare un token da un altro utente, o forse il controllo del token non funziona affatto e accetta token arbitrari. Il rapporto avrebbe dovuto contenere più dettagli, quindi vorrei verificare con il tester su questo.

score 12 · Answer 2

È davvero strano che il __RequestVerificationToken sia incluso nella dimostrazione del concetto, poiché normalmente un utente malintenzionato non conoscerebbe il valore di questo token.

Tuttavia, la pagina può essere ancora vulnerabile a CSRF se __RequestVerificationToken non è associato correttamente alla sessione. Se il valore nella dimostrazione di concetto, _e-upIZFx7i0YyzrVd[...] , funziona per tutti, sei vulnerabile a CSRF. Se funziona solo per l'utente in cui il pentester è stato registrato, non sei vulnerabile a CSRF.

Poiché si utilizza la protezione .NET CRSF predefinita, suppongo che questo sia implementato correttamente e che il pentestore abbia commesso un errore.

score 2 · Answer 3

2

Se __RequestVerificationToken non è convalidato sul lato server e se funziona per ogni singola richiesta e utente diverso da yes, la tua applicazione è vulnerabile a CSRF.

risposta data 23.11.2016 - 10:04

fonte