OWASP CSRFGuard ottiene il token tramite XMLHttpRequest - perché?

4

Desidero utilizzare il CSRFGuard Project per proteggere una webapp legacy Java contro gli attacchi CSRF. L'ultima versione delle dipendenze di Maven è 3.1.0, che è quello che uso.

Questo fa parte del codice JavaScript incluso in ogni pagina protetta:

var xhr = window.XMLHttpRequest ? new window.XMLHttpRequest : new window.ActiveXObject("Microsoft.XMLHTTP");
var csrfToken = {};
xhr.open("POST", "/JavaScriptServlet/", false);
xhr.setRequestHeader("FETCH-CSRF-TOKEN", "1");
xhr.send(null);

var token_pair = xhr.responseText;
token_pair = token_pair.split(":");
var token_name = token_pair[0];
var token_value = token_pair[1];

È un file JS separato generato da un servlet dedicato, con intestazioni no-cache.

Non capisco perché il nome e il valore del token non siano direttamente incorporati nel JavaScript generato, ma recuperati tramite una chiamata AJAX sincrona (!).

Ci sono delle vulnerabilità se lo cambio per includere direttamente il token?

    
posta Michael Böckling 08.12.2016 - 18:41
fonte

1 risposta

2

Are there any vulnerabilities if I change it to include the token directly?

Oh sì.

Quindi un utente malintenzionato potrebbe semplicemente includere lo script nella sua pagina:

<script src="http://yourserver.tld/yourpart"></script>

Elasciacheeseguaquestocodice:

vartoken_name="sample-token-name";
var token_value = "sample-token-value";

Quindi sia token_name che token_value non saranno variabili globali sulla pagina dell'hacker che è possibile accedere e utilizzare per creare l'attacco CSRF.

Il motivo per cui utilizzano AJAX per ottenere il token è che questa richiesta non riuscirebbe se l'autore dell'attacco includesse solo il tag dello script a causa della politica della stessa origine.

Per quanto riguarda il motivo per cui stanno usando sincrono AJAX, dubito che ci sia un motivo tranne un design scadente.

    
risposta data 08.12.2016 - 20:20
fonte

Leggi altre domande sui tag