Come può l'intestazione Origin essere utilizzata per prevenire CSRF se Firefox non lo invia per le stesse richieste di origine o richieste dagli URI di dati?

3

Ho intenzione di utilizzare i token di sincronizzazione per la prevenzione CSRF, ma OWASP consiglia controllando anche le intestazioni di referrer e di origine. Ho cercato di capire la logica corretta per questo, ma i miei esperimenti suggeriscono che non esiste un modo valido per controllare a causa del modo in cui si comporta Firefox.

Firefox non invia l'intestazione di origine per le stesse richieste di origine, cosa che avrei pensato significa che devi consentire a richieste che non hanno un'intestazione di origine. Ho appena sperimentato gli URI di dati e sembra che Firefox non invii l'intestazione di origine da essi, il che significherebbe che un utente malintenzionato può semplicemente indirizzare l'utente a un URI di dati che invia automaticamente un modulo dannoso.

Questo

data:text/html;base64,PGZvcm0gYWN0aW9uPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tIiBtZXRob2Q9IkdFVCI+CjxpbnB1dCB0eXBlPSJzdWJtaXQiPgo8L2Zvcm0+

è un collegamento a un URI di dati contenente un modulo che viene inviato a example.com.

Quale è il seguente codice base64 codificato:

<form action="http://www.example.com" method="GET">
<input type="submit">
</form>

Quando lo apro in Firefox con la console Web aperta, non viene visualizzata alcuna intestazione di origine o referente.

Cosa mi manca qui? C'è qualche logica che dovrei usare sul server che consentirà attraverso le richieste di FIrefox ma non le richieste malevoli dagli URI di dati?

    
posta J Taylor 20.09.2016 - 18:22
fonte

1 risposta

5

L'intestazione Origin non è sempre sufficiente (è solo inviato su richieste POST e CORS, ma quello che hai è una richiesta GET), ma gli header di Referer e Origin sono di solito.

Per impostazione predefinita, Firefox fa invia l'intestazione Referer per le richieste di origine uguale. Questo è in parte il motivo per cui OWASP consiglia di utilizzare entrambe le intestazioni di origine e di riferimento:

To determine the source origin, we recommend using one of these two standard headers that almost all requests include one or both of:

  • Origin Header
  • Referer Header

Se entrambe le intestazioni non sono presenti, il che dovrebbe essere raro (il tuo caso base64 ne è uno), puoi scegliere di accettarlo o negarlo.

If neither of these headers is present, which should be VERY rare, you can either accept or block the request. We recommend blocking, particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.

Come dice OWASP, ci sono casi in cui queste intestazioni potrebbero non essere presenti, quindi consiglia di utilizzare un controllo aggiuntivo, di cui raccomanda l'utilizzo di token CSRF, specialmente se non si blocca quando nessuna intestazione è presente e corretta.

checking headers is a reasonable first step in your CSRF defense, but since they aren't always present, its generally not considered a sufficient defense on its own.

    
risposta data 20.09.2016 - 19:42
fonte

Leggi altre domande sui tag