E 'un vero attacco CSRF?

Question

E 'un vero attacco CSRF?

#1 da (3 voti)
#2 da (0 voti)

0

Ho risolto un'applicazione di moduli web asp.net che presenta una serie di vulnerabilità scoperte da un'azienda esterna di test delle penne.

Recentemente ho implementato un doppio cookie di invio con la libreria di asp.net AntiForgery. Inoltre, imposta ViewStateUserKey per usare sessionId.

I pen-tester hanno fornito uno script POC CSRF all'interno di una pagina html. Tenta di caricare un file sul sito web. Quando provo ad usarlo, non riesce e gli errori di viewstate non validi sono registrati sul server web.

Ho scoperto che i tester di penna utilizzano un login valido per creare lo script POC, ma poi usano lo stesso login della vittima di destinazione.

Lo script POC non deve essere creato da un altro login valido? Non è barare usando lo stesso login per creare lo script di attacco così come la vittima?

asp.net csrf

posta ParleParle 15.12.2017 - 01:24

fonte

2 risposte

Leggi altre domande sui tag asp.net csrf

Come modificare un codice esadecimale senza corrompere il file [in bypass di av]? Antivirus vs Firewall con antivirus

score 3 · Answer 1

Sì, è un vero attacco CSRF.

Ricorda che un attacco CSRF è progettato per essere eseguito con un link forgiato esterno inviato a qualcuno che ha già effettuato l'accesso, per fare in modo che facciano un'azione nella loro sessione che non intendevano fare.

Un classico esempio potrebbe essere il tuo sito web bancario, verrai registrato e qualcuno ti invierà un'email esterna con un link contraffatto.

Quindi ricevi quel link contraffatto nella tua email, fai clic sul link, apre una nuova scheda nel tuo browser, supponendo che tu abbia già effettuato l'accesso e il comando nell'URL venga eseguito direttamente nella sessione corrente della tua banca .

Ad esempio, il modo per trasferire fondi tramite una query GET potrebbe essere qualcosa come: https://mybankingwebsite.com/transfer/500/to/attacker-bank-account

Quindi ora chiunque usi la tua banca e che ha effettuato l'accesso e clic su quel link invierà 500 $ a attacker-bank-account . Ma non eri tu che volevi fare quel comando, il link proveniva da qualche altra parte, ma viene eseguito nel tuo contesto di conto bancario registrato. Questo è un CSRF.

Facebook era vulnerabile anche agli attacchi CSRF e a molti altri siti. Ad esempio, un link contraffatto in Facebook potrebbe causare la pubblicazione di qualcosa sulla tua bacheca che non avresti mai voluto.

score 0 · Answer 2

Secondo OWASP ViewStateUserKey è un modo accettabile per prevenire CSRF a causa della sua unicità nel contesto dell'utente e della sessione. Anche l'utilizzo degli stessi credenziali di accesso di quello nello script PoC non ha molto senso in questo caso. Suggerirei di parlare direttamente con l'auditor e chiedere quale fosse la sua intenzione con questo copione.

Inoltre, solo in base al meccanismo ViewState non impedirà CSRF nella tua applicazione. Cosa succede se invii direttamente richieste AJAX al tuo back-end? In questo caso potrebbe essere necessario implementare un'intestazione personalizzata con un token CSRF e controllare e convalidare questo token nel server.