CSRF mediante la manipulación de encabezados HTTP desde el lado del cliente con JavaScript

1

Estoy intentando hacer un análisis de vulnerabilidad CSRF para mi sitio web. Mi sitio web utiliza un token anti-CSRF que es enviado por el servidor al cliente con la cookie de sesión y luego Javascript en el cliente lo extrae de la cookie y lo adjunta como un encabezado XSRF-TOKEN separado para enviar al servidor .

Intenté ataques CSRF en un formulario vulnerable XSS en mi sitio web desde BurpSuite generando PoC CSRF después de interceptar la solicitud, guardándolo en un archivo html y abriendo ese archivo en una nueva pestaña con una sesión activa en otra pestaña. Descubrí que el navegador no puede enviar el token XSRF automáticamente, pero lo hace para todas las cookies y otros encabezados.

Quiero saber si es posible crear un nuevo o manipular el encabezado XSRF-TOKEN existente desde el lado del cliente utilizando un script y enviarlo con la solicitud. ¿O si hay alguna otra manera de enviar por la fuerza el encabezado XSRF-TOKEN o cualquier otra forma de llevar a cabo el ataque CSRF? A partir de ahora, la única vulnerabilidad que conozco es que puedo abrir mi sitio web en un iframe desde otro dominio.

    
pregunta Akshay 18.09.2015 - 12:41
fuente

2 respuestas

1

JavaScript de otro dominio no puede manipular o leer el contenido de su dominio, incluso en un marco IFrame, debido a la Política del mismo origen . Por lo tanto, el escenario de ataque que describe no es un riesgo, ya que no es una vulnerabilidad.

Tenga en cuenta que Double Submit Cookies tiene otras vulnerabilidades. Consulte esta respuesta .

Una forma de eludir las protecciones CSRF es que un atacante utilice clickjacking . Para evitar esto, asegúrese de que su sitio no pueda ser enmarcado usando el encabezado X-FRAME-OPTIONS y la Política de Seguridad de Contenido frame ancestors directiva.

    
respondido por el SilverlightFox 22.09.2015 - 11:31
fuente
0

Su última oración no es sobre CSRF, sino sobre Click Jacking, estos no están relacionados.

Lo único en lo que puedo pensar para modificar el encabezado XSRF-TOKEN como atacante es cuando eres vulnerable a la Contaminación de Parámetros HTTP.

Para comprender mejor su implementación anti CSRF, sería mejor si describiera cómo se comprueban la cookie y el encabezado.

He visto implementaciones que solo verifican si el valor de la cookie es igual al valor del encabezado, lo que en mi opinión no es correcto, ya que el servidor debería verificar su valor y no solo comparar los dos.

    
respondido por el Jeroen - IT Nerdbox 18.09.2015 - 13:02
fuente

Lea otras preguntas en las etiquetas