2014-09-24 7 views
5

Sono stato attuando gettoni ASP ARF nella mia applicazione web MVC3 e leggere sul funzionamento del CSRF exploit e come gettoni ARF difendere contro di essa. Ora mi chiedevo se gli "hacker" non potevano aggirare il controllo ARF usando un passaggio extra. Il normale scenario CSRF è come:La falsificazione di richieste anti ASP, perché l'hacker non dovrebbe fare un primo tentativo?

  1. creare un sito (che noi chiamiamo HackerSite) che i posti al sito web di destinazione BankingSite
  2. Usa ingegneria sociale (o XSS in annunci, ecc) in modo che un utente visita sito HackerSite
  3. Uno script in HackerSite invierà al BankingSite utilizzando gli utenti cookie/credenziali di distacco quindi sotto la sua/il suo nome

a causa della nostra Token ARF, il BankingSite sa di ignorare il POST proveniente dal sito H ackerSite. Perché manca il token AFR giusto. Qualcuno potrebbe dirmi perché l'hacker non è riuscito a ottenere il token facendo prima una richiesta GET sul BankingSite? Come questo:

  1. Creare un sito (che noi chiamiamo HackerSite) che i posti al sito web di destinazione BankingSite
  2. Usa ingegneria sociale (o XSS in annunci, ecc) in modo che un utente sopralluogo HackerSite
  3. uno script in HackerSite farà una richiesta GET e afferra l'ARF Token dal codice HTML nella risposta, questa richiesta sarà anche possibile impostare il token ARF nel cookie dell'utente
  4. un secondo script sul HackerSite invierà al BankingSite utilizzando i afferrato ARF gettone + utenti biscotti/credenziali così distacco sotto il suo/il suo nome

Qualcuno sa che cosa mi manca qui, e come ARF è assicurato contro un tale attacco?

+3

Penso che questo link spiegare bene il problema e la soluzione http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks Point to 'I token anti-contraffazione funzionano perché la pagina dannosa non è in grado di leggere i token dell'utente, a causa delle politiche della stessa origine. ' – Aristos

+0

La stessa origine AFAIK protegge il cookie dall'essere letto/manipolato da javascript + protegge da IFrames. Nel mio esempio ho ipotizzato che un hacker possa facilmente effettuare richieste ajax su più siti (usando, ad esempio, JSONP). Penso che potrei sbagliarmi rendendo così questo metodo di attacco non valido. Qualcuno può verificare che non è possibile effettuare richieste di ajax di richiesta cross-site (senza che il browser degli utenti venga compromesso). Si prega di – Rob

+0

ci mostrano come uno script su HackerSite.com può ottenere HTML dal BankingSite.com nel browser di un utente –

risposta

1

attaccante non conosce i cookie di vittime. Generazione di token basata su di esso. Se il tuo sito ha altri fori XSS, questo metodo non può essere di aiuto dalla vulnerabilità di CSRF.

Se si invia un'intestazione referer AJAX sarebbe HackerSite, non BankSite. Quindi non hai accesso alla parte chiusa del sito (non puoi accedere al token CSRF). È solo Http, quindi non puoi prenderlo solo con javascript. Il piano fallirà in parte quando si desidera inviare la richiesta al sito della vittima.

+0

Se ho capito CSRF destra, poi l'hacker non ha bisogno di sapere per i cookie della vittima, giusto? Facendo una richiesta GET il token ARF sarà impostato in biscotti utenti e quando si fa la richiesta POST al bankingsite, cookie dell'utente utilizzato (e quindi il cookie di token ARF destra viene inviato) – Rob

+0

Auth cookie è HttpOnly.Non può passare da javascript; – devheart

+1

Quando si effettua una richiesta (normale o tramite AJAX) tutti i cookie vengono automaticamente passati, HttpOnly o no. – Rob

Problemi correlati