Un cliente solo envía formularios utilizando XMLHttpRequest con el uso de un encabezado ( X-Header: [any value would be correct] ) para protegerse contra los ataques de falsificación de solicitudes en sitios cruzados.
Sé que esta no es la forma correcta de prevenir las vulnerabilidades de CSRF, pero ¿cómo explotaría este tipo de vulnerabilidad de CSRF?
El requisito es enviar una solicitud HTTP con un encabezado personalizado.
Este es un método muy similar al uso del encabezado de X-Requested-With , solo que se usa X-Header en su lugar ( ninguno de los cuales son encabezados estándar, aunque X-Requested-With podría considerarse un estándar de facto ).
Este es un método válido para prevenir CSRF ya que solo se permiten los siguientes encabezados de dominio cruzado:
- aceptar
- Aceptar-Idioma
- contenido-lenguaje
- ID del último evento
- Tipo de contenido
cualquier otra causa que se emita una solicitud "previa al vuelo" en los navegadores compatibles con CORS. Los navegadores que no sean CORS ignorarán otros encabezados.
Mientras la configuración de CORS no permita el encabezado y el dominio que usa el atacante, este es un método válido.
Si CORS estaba habilitado y permitía el dominio del atacante, entonces otros métodos de protección CSRF como el Synchronizer Token Pattern también fallaría porque el atacante podría hacer una solicitud GET para recuperar el valor del token (suponiendo que el encabezado access-control-allow-credentials esté configurado como verdadero). Tenga en cuenta que la falta de CORS no impide que el navegador realice las solicitudes , solo impide que se lean las respuestas.
Entonces, parece que estás fuera de suerte para un exploit CSRF, a menos que otro error / característica de Flash o complemento del navegador te permitirá agregar el encabezado a la solicitud.
Lea otras preguntas en las etiquetas web-application csrf