Recupero del dominio incrociato token CSRF utilizzando JSONP, rischioso?

Question

Recupero del dominio incrociato token CSRF utilizzando JSONP, rischioso?

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

4

Esaminando questa domanda precedente , la risposta suggerisce che l'utilizzo di GET la richiesta di recuperare un token CSRF per fare un POST è un metodo legittimo per prevenire gli attacchi CSRF.

Ho due siti Web e un modulo è usato per comunicare tra loro: un modulo di accesso. Questi due siti sono in sottodomini separati e il modulo stesso sul Sito A è: <form method="post" action="https://siteB.com/login">..</form>

Il sito B richiede un token CSRF da inviare tramite un input nascosto, quindi al caricamento della pagina, effettuo una chiamata JSONP a //siteB.com/getCSRFToken , che restituisce il token valido. Uso javascript per inserire l'elemento di input nascosto nel modulo, l'utente non è più saggio e il modulo viene inviato correttamente.

Ci sono potenziali implicazioni per la sicurezza a fare questo? SiteB è un'applicazione Node con supporto Express, quindi sto solo usando il loro middleware CSRF per gestire la generazione / scadenza.

csrf

posta Julian H. Lam 23.04.2014 - 01:40

fonte

2 risposte

2

La ragione per i token CSRF è garantire che un utente malintenzionato non possa costringerti a inviare qualcosa senza che tu lo sappia. Se un utente malintenzionato crea un modulo sul suo sito, ad esempio evil.com, può facilmente compilare il token CSRF eseguendo la stessa richiesta JSONP.

Un altro, sebbene forse difficile da implementare, è quello di avere un sitoA creare un token, inviarlo al sito B, e quest'ultimo verifica se il CSRF è valido utilizzando alcune chiamate JSON al sitoA. In questo modo, puoi garantire che il sitoA sia stato utilizzato per inviare il modulo.

È semplicemente un "questo gettone è corretto?" rispetto a "dammi un token corretto".

risposta data 23.04.2014 - 07:03

fonte

Leggi altre domande sui tag csrf

Hacking / Penetration Laws Modo sicuro per garantire l'accesso alla rete WIFI in base a parametri dinamici?

score 3 · Accepted Answer

In this case, I'm using it for a set of login/registration forms, so there's no information leakage

L'esistenza di un'API JSONP getCSRFToken senza altre limitazioni sul sito del chiamante è effettivamente un bypass completo per tutta la protezione CSRF.

Se pensi che non sia un problema, dovresti semplicemente sbarazzarti del sistema di protezione CSRF, poiché non fa nulla per te.

Se disponi di altri moduli che devono ancora essere protetti, ti consigliamo di rimuovere la protezione dai moduli di accesso / registrazione.

Se hai bisogno della protezione CSRF sui moduli di accesso, dovrai stabilire una sessione interdominio. Se il sito A e il sito B si trovano sullo stesso server, questo non è male, poiché è possibile creare un token su uno che sia leggibile dall'altro. Se sono separati, hai sessioni federate che richiedono molto più lavoro.

all they'd be able to do is allow the user to log in, right?

Potrebbe trattarsi di un problema in base al modo in cui la tua applicazione funziona. Quale sarebbe il risultato se, nel mezzo dell'utilizzo dell'applicazione, un utente potesse passare silenziosamente da un account a un altro da un sito ostile in un'altra scheda?

Se, ad esempio, l'utente non nota che il suo account è cambiato e inserisce le informazioni sensibili in un account diverso da quello di un utente malintenzionato, potrebbe essere piuttosto brutto.