OWASP CSRFGuard obtiene el token a través de XMLHttpRequest: ¿por qué?

4

Quiero usar el CSRFGuard Project para proteger una aplicación web heredada contra ataques CSRF. La última versión publicada de la dependencia de Maven es 3.1.0, que es lo que uso.

Esto es parte del código JavaScript que se incluye en cada página protegida:

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];

Es un archivo JS separado generado por un servlet dedicado, con encabezados sin caché.

No entiendo por qué el nombre y el valor del token no están integrados directamente en el JavaScript generado, sino que se obtienen mediante una llamada AJAX síncrona (!).

¿Existe alguna vulnerabilidad si la cambio para incluir el token directamente?

    
pregunta Michael Böckling 08.12.2016 - 18:41
fuente

1 respuesta

2
  

¿Existe alguna vulnerabilidad si la cambio para incluir el token directamente?

Oh, sí.

Luego, un atacante podría incluir ese script en su página:

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

Ydejaqueejecuteestecódigo:

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

Entonces, tanto token_name como token_value no serán variables globales en la página del atacante a las que se puede acceder y utilizar para crear el ataque CSRF.

La razón por la que están utilizando AJAX para obtener el token es que esta solicitud fallaría si el atacante solo incluye la etiqueta de secuencia de comandos debido a la política del mismo origen.

En cuanto a por qué usan síncrono AJAX, dudo que haya una razón, excepto un diseño deficiente.

    
respondido por el Alexander O'Mara 08.12.2016 - 20:20
fuente

Lea otras preguntas en las etiquetas