Protección CSRF con encabezados personalizados (y sin validar el token)

La seguridad se trata de la defensa en profundidad. Simplemente, comprobar que el valor es suficiente en este momento , pero las tecnologías y los ataques futuros pueden aprovecharse para romper su protección. La prueba de la presencia de un token logra la defensa mínima absoluta necesaria para hacer frente a los ataques actuales. Agregar el token aleatorio mejora la seguridad contra potenciales futuros vectores de ataque. El uso de un token por solicitud también ayuda a limitar el daño causado por una vulnerabilidad XSS, ya que el atacante necesita una forma de robar un token nuevo para cada solicitud que realice.

Este es el mismo razonamiento utilizado en los algoritmos criptográficos modernos, donde n rounds se considera un mínimo para la seguridad, pero 2n+1 rounds (por ejemplo) se eligen en la implementación oficial para garantizar un margen de seguridad decente.

Lectura adicional:

• CSRF con JSON POST
• ¿Por qué actualizar el token CSRF por solicitud de formulario?

TL; DR: verificar la existencia de un encabezado no estándar como "X-Requested By" debería ser suficiente para protegerse contra los ataques CSRF sin verificar el valor del encabezado.

Los encabezados no estándar no se pueden establecer en un ataque CSRF

El sitio del framework Play lo desglosa realmente bien:

  

En pocas palabras, un atacante puede obligar a un navegador de víctimas a realizar los siguientes tipos de solicitudes:

     

• Todas las solicitudes GET
  
• solicitudes POST con cuerpos de tipo application / x-www-form-urlencoded, multipart / form-data y text / plain
  

Un atacante no puede:

     

• obligue al navegador a usar otros métodos de solicitud como PUT y DELETE
  
• obligue al navegador a publicar otros tipos de contenido, como application / json
  
• obligue al navegador a enviar nuevas cookies, aparte de las que el servidor ya ha configurado
  
• Obligue al navegador para establecer encabezados arbitrarios, aparte de los encabezados normales que el navegador agrega a las solicitudes
  

Esto tiene sentido si considera los vectores de ataque para CSRF:

• solicitudes GET (por ejemplo, < img & gt ;, < iframe >), que no pueden establecer encabezados.
• < form > enviado por un usuario, que se limita a unos pocos encabezados específicos.
• < form > enviado por JavaScript (HTMLFormElement.submit ()), que se limita a unos pocos encabezados específicos.

JavaScript está sujeto a la política del mismo origen , por lo que solo puede agregar encabezados no estándar si es que De las siguientes condiciones se mantienen:

• es "in-domain" (es decir, cargado desde el mismo dominio que el objetivo de la solicitud).
• está permitido hacerlo a través de CORS .

Los ataques XSS están fuera del alcance de esta pregunta

Los encabezados no estándar se pueden configurar en un ataque XSS. El uso de un encabezado no estándar para evitar ataques CSRF no hace que un sitio sea más (o menos) vulnerable a los ataques XSS, independientemente del valor del encabezado. Tanto los encabezados no estándar como los tokens CSRF son vulnerables a los ataques XSS. Si el atacante XSS puede establecer un encabezado no estándar en una solicitud (por ejemplo, XHR en el dominio), ciertamente puede obtener acceso a un conjunto de token CSRF en una cookie o incrustado en DOM o en una variable de JavaScript.

Referencia

Hay una pregunta de SO similar aquí que es confuso pero llegó a la misma conclusión.

Algunos ejemplos de dichos encabezados no estándar en la naturaleza:

• "X-Request-By" (mencionado por OP) reconocido por Jersey / others
• "X-Request-With" establecido por jQuery
• "X-XSRF-TOKEN" establecido por Angular
• "X-CSRF-TOKEN" reconocido por el Play framework

EDITAR: este csrf-request-builder estaba explotando una vulnerabilidad en Flash que ahora se ha corregido. Es posible enviar solicitudes complejas con JavaScript, sin embargo, si especifica elementos adicionales del encabezado, se realizará una solicitud de preflight OPTIONS http enviado antes de la solicitud real.

He verificado que Jersy es vulnerable a CSRF y que los desarrolladores de Jersy han sido notificados. Es posible aprovechar esta vulnerabilidad utilizando Flash y la posibilidad de otras tecnologías de secuencias de comandos. Jersy es vulnerable porque el encabezado http "X-Requested-By" no está en encabezado de la lista negra de flash .

Utilicé el CSRF-Request-Builder con los siguientes argumentos para crear una solicitud de publicación:

file://var/code/CSRF-Request-Builder/csrf_payload.html#url=http://google.com&X-Requested-By=1&body={'test':1}

Nunca debe venir con su propio método de prevención de CSRF a menos que realmente entienda la explotación de CSRF. La CSRF Prevention Cheat sheet es un gran recurso.

enlace hace un punto muy importante: la Política de Mismo Origen (SOP) se ocupa de evitar la lectura de respuestas entre dominios, no con la escritura de solicitudes.

Esto significa que, si bien es posible que pueda escribir encabezados personalizados en el futuro, es extremadamente improbable que alguna vez pueda leer la respuesta de una solicitud de varios dominios. Como tal, las mejores protecciones CSRF implican leer un valor secreto del servidor, escribirlo y hacer que el servidor valide el valor.

No necesariamente necesitas un estado del lado del servidor para lograr esto ( Double-Submit Las cookies y Patrón de token cifrado son dos ejemplos de esto) pero debe validar algunos valores secretos en el servidor.