Protezione CSRF con intestazioni personalizzate (e senza token di convalida)

La sicurezza riguarda la difesa in profondità. È sufficiente controllare il valore al momento , ma le tecnologie e gli attacchi futuri potrebbero essere sfruttati per violare la tua protezione. Il test per la presenza di un token raggiunge la difesa minima assoluta necessaria per affrontare gli attacchi attuali. L'aggiunta del token casuale migliora la sicurezza contro i potenziali futuri vettori di attacco. L'utilizzo di un token per richiesta consente inoltre di limitare il danno causato da una vulnerabilità XSS, poiché l'autore dell'attacco ha bisogno di un modo per rubare un nuovo token per ogni richiesta effettuata.

Questo è lo stesso ragionamento usato nei moderni algoritmi crittografici, dove n round è considerato un minimo per sicurezza, ma 2n+1 round (per esempio) sono scelti nell'implementazione ufficiale per garantire un margine di sicurezza decente.

Ulteriori letture:

• CSRF con JSON POST
• Perché aggiornare il token CSRF per richiesta di modulo?

TL; DR - Controllare l'esistenza di un'intestazione non standard come "X-Requested-By" dovrebbe essere sufficiente per proteggersi dagli attacchi CSRF senza controllare il valore dell'intestazione.

Le intestazioni non standard non possono essere impostate in un attacco CSRF

Il sito di Play Framework lo scompone molto bene:

Simply put, an attacker can coerce a victims browser to make the following types of requests:

• All GET requests
• POST requests with bodies of type application/x-www-form-urlencoded, multipart/form-data and text/plain

An attacker can not:

• Coerce the browser to use other request methods such as PUT and DELETE
• Coerce the browser to post other content types, such as application/json
• Coerce the browser to send new cookies, other than those that the server has already set
• Coerce the browser to set arbitrary headers, other than the normal headers the browser adds to requests

Questo ha senso se si considerano i vettori di attacco per CSRF:

• Richiedi richieste (ad es. < img & gt ;, < iframe >) - che non possono impostare le intestazioni.
• < form > inviato da un clic dell'utente, limitato a pochi intestazioni specifiche.
• < form > inviato da JavaScript (HTMLFormElement.submit ()) - che sono limitati ad alcuni specifici header.

JavaScript è soggetto alla politica della stessa origine , quindi può aggiungere solo intestazioni non standard se una delle seguenti condizioni:

• è "in-domain" (cioè caricato dallo stesso dominio della destinazione della richiesta).
• è consentito farlo tramite CORS .

Gli attacchi XSS sono fuori portata per questa domanda

Le intestazioni non standard possono essere impostate in un attacco XSS. L'utilizzo di un'intestazione non standard per impedire attacchi CSRF non rende un sito più (o meno) vulnerabile agli attacchi XSS indipendentemente dal valore dell'intestazione. Sia le intestazioni non standard che i token CSRF sono vulnerabili agli attacchi XSS. Se l'attaccante XSS può impostare un'intestazione non standard su una richiesta (es. XHR nel dominio), può certamente accedere a un set di token CSRF in un cookie o incorporato in DOM o in una variabile JavaScript.

Riferimento

C'è una domanda SO simile qui che è fonte di confusione ma è giunta alla stessa conclusione.

Alcuni esempi di tali intestazioni non standard in natura:

• "X-Requested-By" (menzionato da OP) riconosciuto da Jersey / altri
• "X-Requested-With" impostato da jQuery
• "X-XSRF-TOKEN" impostato da Angolare
• "X-CSRF-TOKEN" riconosciuto dal Play framework

EDIT: questo il csrf-request-builder stava sfruttando una vulnerabilità in Flash che ora è stata corretta. È possibile inviare richieste complesse con JavaScript, tuttavia se si specificano ulteriori elementi di intestazione una richiesta HTTP di preflight OPTIONS sarà inviato prima della richiesta effettiva

Ho verificato che Jersy è vulnerabile a CSRF e che gli sviluppatori di Jersy sono stati avvisati. È possibile sfruttare questa vulnerabilità utilizzando Flash e altre tecnologie di scripting. Jersy è vulnerabile perché l'intestazione http "X-Requested-By" non è su lista nera dell'intestazione del flash .

Ho utilizzato il CSRF-Request-Builder con i seguenti argomenti per creare una richiesta di post:

file://var/code/CSRF-Request-Builder/csrf_payload.html#url=http://google.com&X-Requested-By=1&body={'test':1}

Non si dovrebbe mai venire con il proprio metodo di prevenzione CSRF a meno che non si comprenda veramente lo sfruttamento della CSRF. Il foglio Chec CSRF Prevention è un'ottima risorsa.

Il link rende un punto molto importante: la stessa politica di origine (SOP) riguarda la prevenzione della lettura di risposte interdominio, non con la scrittura di richieste.

Il significato, mentre potresti essere in grado di scrivere intestazioni personalizzate in futuro, è estremamente improbabile che tu possa essere in grado di leggere la risposta di una richiesta interdominio. Pertanto, le migliori protezioni CSRF implicano la lettura di un valore segreto dal server, la sua scrittura e la convalida del valore del server.

Non è necessariamente necessario lo stato lato server per eseguire questa operazione ( Double-Submit I cookie e Pattern token crittografato sono due esempi di questo) ma devi convalidare alcuni valori segreti sul server.