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

55

Per un REST-api sembra che sia sufficiente controllare la presenza di un'intestazione personalizzata per proteggersi dagli attacchi CSRF, ad es. client invia

"X-Requested-By: whatever"

e il server controlla la presenza di "X-Requested-By" e rilascia la richiesta se l'intestazione non viene trovata. Il valore dell'intestazione è irrilevante. Ecco come funziona CsrfProtectionFilter di Jersey 1.9 ed è descritto in questo post del blog: link . Il post sul blog si collega anche ai documenti NSA e Stanford che affermano che l'intestazione personalizzata è di per sé una protezione sufficiente:

The first method involves setting custom headers for each REST request such as X-XSRF-Header. The value of this header does not matter; simply the presence should prevent CSRF attacks. If a request comes into a REST endpoint without the custom header then the request should be dropped.

HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to prevent web sites from sending requests to each other unless specifically allowed by policy. This means that a website www.bad.com cannot send a request to http://bank.example.com with the custom header X-XSRFHeader unless they use a technology such as a XMLHttpRequest. That technology would prevent such a request from being made unless the bank.example.com domain specifically allowed it. This then results in a REST endpoint that can only be called via XMLHttpRequest (or similar technology).

It is important to note that this method also prevents any direct access from a web browser to that REST endpoint. Web applications using this approach will need to interface with their REST endpoints via XMLHttpRequest or similar technology.

Fonte: Linee guida per l'implementazione di REST

Sembra tuttavia che la maggior parte degli altri approcci suggerisca di generare un token e anche di convalidarlo sul server. È questo over-engineering? Quando un approccio "presenza di" è sicuro e quando è richiesta anche la convalida del token?

    
posta Mads Mobæk 30.10.2012 - 10:59
fonte

4 risposte

30

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:

risposta data 30.10.2012 - 11:07
fonte
25

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
risposta data 20.05.2014 - 03:42
fonte
12

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.

    
risposta data 30.10.2012 - 16:47
fonte
3

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.

    
risposta data 27.06.2014 - 05:45
fonte

Leggi altre domande sui tag