Come fa un token CSRF a prevenire un attacco e come posso usarlo / evitarlo in modo sicuro per la mia API JSON?

Naviga le tue risposte
21

Sto provando a far comunicare un'applicazione iOS con un sito web di Ruby on Rails utilizzando JSON. Durante il tentativo di pubblicare un login per creare una sessione utente, ho scoperto che mi mancava un token CSRF. Non avevo idea di cosa fosse, quindi ho iniziato a esaminarlo e ho trovato alcune soluzioni che dicevano di rimuovere la protezione CSRF se il formato della chiamata è "application / json". Ma sembra che questo lasci il sito vulnerabile?

Sono emersi alcuni risultati relativi ai moduli JS aventi lo stesso problema. Le risposte dovevano essere aggiunte nel token CSRF. Che all'atto dell'ispezione, appare anche nel tag meta contenuto nelle intestazioni di pagina.

Quindi questo mi lascia in confusione, ecco le mie domande:

  • In che modo il token protegge qualcosa se può essere letto in una chiamata precedente alla chiamata in attacco? Un sito dannoso può non effettuare semplicemente una richiesta, analizzare il messaggio ricevuto e inviare un'altra richiesta con il token?
  • Sarebbe sicuro disabilitare il token-check sull'azione di login post e fargli rimandare il token insieme alla risposta di successo? Se no, qualche suggerimento migliore?
posta Dan2552 22.12.2012 - 22:43
fonte

1 risposta

21

Un riassunto di come funzionano gli attacchi CSRF in questo modo:

  1. Tu, buon utente, mentre sei loggato in un sito web A, visita la pagina di un altro sito B.
  2. Quella pagina fa un GET (può essere un POST, un po 'più complesso da impostare in alto) a una pagina X sul sito A (a cui è stato effettuato l'accesso), ad es. . Il tuo browser obbliga, utilizzando la tua sessione / cookie già autenticato
  3. Pagina X design causa cambiamenti nello stato del tuo account - gli esempi classici sono "trasferimento da X dollari a B" (meno realistico) o "imposta la riga di stato dell'utente su PWNED" (più realistico)

Ci sono diversi modi in cui un token CSRF può essere implementato, ma l'idea è che una semplice richiesta GET a un URL modificante lo stato X non funzionerà a meno che non sia inclusa una ulteriore informazione mutevole (il token), ad es. deve essere "X? token = 123123213". Poiché il token cambia ragionevolmente spesso, il passaggio 2 sopra non funzionerà. L'aspirante attaccante non conosce il token corrente.

La tua domanda 1: l'autore dell'attacco non vede il contenuto della pagina X, ti costringe solo a visitarlo.

La tua domanda 2 - dato che si tratta di azioni tutte già registrate, è più o meno opportuno non utilizzare la protezione CSRF nella pagina di accesso. C'è una possibilità che tu possa essere forzato ad accedere come qualcun altro e comunque non notarlo,

link

Una classe più generale di problemi è link

    
risposta data 23.12.2012 - 02:13
fonte

Leggi altre domande sui tag

Rails: protezione contro l'iniezione di codice e XSS IKEv2 vs OpenVPN