Come funziona il token XSRF per richiesta? (Soluzione angolare)

6

Voglio proteggere la mia applicazione contro XSRF. Sebbene non sia in grado di capire veramente quale sia il problema e come funzioni la mia soluzione, dopo alcune ricerche ho trovato una soluzione, che Angular utilizza. Per quanto ho ottenuto, la mia soluzione richiede i seguenti passaggi:

  • Il cliente invia una richiesta per la mia SPA.
  • Invio il token XSRF (non solo HTTP per consentire a JS di leggerlo). Salvo anche questo token XSRF per la sessione degli utenti sul server.
  • Per ogni richiesta POST voglio che il mio client legga il token XSRF e imposta un'intestazione X-XSRF-TOKEN su questo token.
  • Controllerò ogni richiesta controllando se l'intestazione della richiesta e il token XSRF della sessione utente corrispondono. Se lo fanno, controllerò anche JWT per l'autenticazione, se necessario.
  • Dopo aver convalidato il token XSRF, apporterò le modifiche al database. Inoltre cambierò nuovamente il token XSRF e invierò il nuovo token all'utente e cambierà token per la sessione.

Ma non sono sicuro di come questo aiuti, se ho una vulnerabilità XSS, dal momento che qualsiasi codice JavaScript iniettato potrebbe fare lo stesso. Voglio capire il problema e come questa soluzione aiuta.

Cordiali saluti, sto anche implementando l'autenticazione basata su JWT, usando Redis per la gestione delle sessioni, su un server Express.

    
posta FurkanO 14.06.2016 - 19:03
fonte

1 risposta

6

Il piano è buono?

Il tuo piano mi sembra buono. L'utilizzo di un token CSRF è la soluzione standard per questo tipo di problema. Ma non dovresti sentirti al sicuro solo perché un estraneo su internet ti dice che è bello - assicurati di capire cosa stai facendo e perché, altrimenti sei destinato a sbagliare.

(Un punto minore: non sono sicuro che sia necessario modificare il token ad ogni richiesta.)

Quindi perché funziona?

Da questa vecchia risposta della mia:

The attacker fools the victim to visit http://evil.com that contains a form that automatically does a POST to http://bank.com/transfer?to=evilHacker&amount=1000000. If the victim is already logged in to her bank, the cookie with the session ID will be sent like usual by the browser and there is no way for the bank server to know that the victim did not actually intend to transfer the money. Note that this relies on the browser sending the cookie with the session ID to bank.com.

So how can a CSRF-token help? If the bank.com always checks that a random token unique to that session is present in the request, evil.com can not forge the request since the evil hacker running that site does not know what the token is.

Ma che mi dici di XSS?

Come dici nella tua domanda, questo non aiuta se esiste una vulnerabilità XSS. In effetti, non esiste una protezione CSRF che possa essere d'aiuto in questo caso, ma se sei vulnerabile a XSS hai più problemi dei token CSRF rubati di cui preoccuparti comunque.

Quindi l'unica cosa da fare qui è lavorare sulla tua protezione XSS.

    
risposta data 14.06.2016 - 19:26
fonte

Leggi altre domande sui tag