¿CSRF sigue siendo un vector de ataque relevante?

  

... si un XMLHttpRequest debería enviar cookies, se debe establecer la marca withcredentials. E incluso entonces, el servidor de destino tiene que implementar un encabezado CORS para que la solicitud sea exitosa. ... qué navegadores ya implementan esas contramedidas y si son suficientes como defensa o si todavía tenemos que implementar las mitigaciones de CSRF en nuestras aplicaciones.

CORS para XHR no es una nueva mitigación e incluso no es una mitigación contra ataques que funcionaban previamente. Cuando se diseñó XMLHttpRequest , no fue posible realizar solicitudes de origen cruzado. Y solo con la introducción de CORS, estas restricciones se modificaron y reemplazaron con solicitudes de origen cruzado controladas por una política de CORS. Por lo tanto, todos los navegadores antiguos que no implementaron CORS no se vieron afectados por CSRF a través de XHR en primer lugar.

Sin embargo, CSRF sigue siendo un problema y puede seguir utilizándose de la misma manera que en el pasado. XHR no es necesario como un vector para los ataques CSRF y no funcionó en el pasado de todos modos. En su lugar, la imagen entre sitios incluye, se pueden utilizar envíos de formularios entre sitios o similares, que aún envían automáticamente las credenciales y las cookies necesarias entre sitios. El nuevo samesite attribute se puede usar para evitar esto, pero se debe establecer explícitamente Por la aplicación y no todos los navegadores lo admiten todavía.

Por lo tanto, aún hoy se necesita una protección adecuada de CSRF.

Lo que sucede si la protección CSRF no se implementa correctamente se puede ver, por ejemplo, en noticias recientes como Hackers lanzando un ataque cibernético masivo contra 800,000 DrayTek Routers by Explotación de la vulnerabilidad de día cero .

  

Las cookies y los encabezados necesarios para la autenticación no se envían de forma predeterminada en las solicitudes entre sitios.

Eso no es correcto. Si un usuario hace clic en un enlace o publica un formulario en evil.com a example.com , se incluirán las cookies. El usuario ni siquiera tiene que hacer clic en el enlace o en el botón de enviar, se puede automatizar con un script.

  

Por ejemplo, si un XMLHttpRequest debería enviar cookies, se debe establecer la marca withcredentials. E incluso entonces, el servidor de destino tiene que implementar un encabezado CORS para que la solicitud sea exitosa.

Sí, claro. Pero, ¿por qué un atacante necesita XHR cuando puedes usar una forma antigua?

  

Ahora me pregunto qué navegadores ya implementan esas contramedidas y si son suficientes como defensa o si todavía tenemos que implementar las mitigaciones de CSRF en nuestras aplicaciones.

Los navegadores no implementan ningún contador automático de medidas, por lo que aún debes hacerlo. Los sitios vulnerables seguirán siendo vulnerables sin importar la forma en que usamos los navegadores modernos.

De una manera, tienes razón, sin embargo. Las API modernas a menudo están diseñadas de manera que les otorga al menos algo de protección CSRF por defecto. Esto sucede, por ejemplo, si realiza la autenticación con un encabezado de autorización en lugar de cookies, o si solo acepta solicitudes POST con un cuerpo JSON.

Si tuviera que hacer un comentario sobre el tema, se reflejaría mejor en lo que está escrito en este artículo.

enlace

CSRF sigue siendo relevante en una condición similar a IPv4: no podremos eliminar los sistemas heredados que están al tanto de él por un tiempo, y eventualmente surgirá una permutación.

Como siempre; recuerde parchear sus sistemas niños