javascript - ejemplo - html form without csrf protection solutions

¿Cómo evita el token el ataque csrf?

Question

He leído acerca de CSRF y cómo se usa el Patrón de token del sincronizador impredecible para evitarlo. No entendí muy bien cómo funciona.

Tomemos este escenario:

Un usuario se registra en un sitio con este formulario:

<form action="changePassword" method="POST">
<input type="text" name="password"><br>
<input type="hidden" name="token" value=''asdjkldssdk22332nkadjf'' >
</form>

El servidor también almacena el token en la sesión. Cuando se envía la solicitud, compara el token en los datos del formulario con el token en la sesión.

¿Cómo evita eso CSRF cuando el pirata informático puede escribir código JavaScript que:

1. Enviar una solicitud GET al sitio
2. Reciba el texto html que contiene el formulario de solicitud.
3. Busque el texto html para el token CSRF.
4. Haga la solicitud maliciosa utilizando ese token.

¿Me estoy perdiendo algo?

Answer 1

El atacante no puede usar JavaScript para leer el token del sitio, ya que sería una solicitud de origen cruzado y el acceso a los datos está bloqueado (de forma predeterminada) por la Política del mismo origen ( MDN , W3C ).

Toma esto por ejemplo:

var xhr = new XMLHttpRequest();
xhr.open("GET", "http://google.com");
xhr.addEventListener(''load'', function (ev) {
console.log(this.responseText);
});
xhr.send();

La consola JS reporta:

XMLHttpRequest no puede cargar http://google.com/ . No hay ningún encabezado '' Access-Control-Allow-Origin '' presente en el recurso solicitado.

Answer 2

Es importante darse cuenta de que los ataques CSRF solo ocurren en el navegador. La sesión del usuario con el servidor de destino es utilizada por el servidor malicioso para falsificar solicitudes. Entonces, ¿cómo sucede el # 1? Dos opciones: puede realizar la solicitud # 1 desde el servidor malicioso, pero eso simplemente devolverá un token CSRF para la sesión del servidor , o podría hacer la solicitud # 1 usando AJAX que, como se identificó correctamente, devolvería el token CSRF del usuario víctima.

Los navegadores han implementado el control de acceso HTTP por esta misma razón. Debe usar el encabezado Access-Control-Allow-Origin para restringir qué dominios pueden realizar solicitudes AJAX a su servidor. En otras palabras, su servidor se asegurará de que el navegador no permita que el sitio malicioso realice el # 1. Desafortunadamente, los documentos que he leído sobre el tema no son muy claros al respecto, pero creo que eso se debe a que los servidores por defecto no envían un encabezado Access-Control-Allow-Origin menos que estén configurados para hacerlo. Si necesita permitir las solicitudes AJAX, debe confiar en cualquier origen en el encabezado para no realizar un ataque CSRF, puede bloquear selectivamente partes sensibles de su aplicación para no permitir solicitudes AJAX, o usar el otro Access-Control-* encabezados para protegerse.

El uso de un token de sincronizador es una de las formas en que una aplicación puede confiar en la Política del mismo origen para evitar CSRF manteniendo un token secreto para autenticar las solicitudes.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Debería leer sobre Intercambio de recursos entre orígenes (CORS).