¿Por qué se prefiere el patrón de token del sincronizador sobre el encabezado de origen para evitar CSRF?

En pocas palabras

• El encabezado Origin no se envía para solicitudes del mismo origen por todos los navegadores .
• Errores actuales en los navegadores populares significa que el encabezado Origin no se envía para Las solicitudes POST, lo que hace que este enfoque sea menos que inútil, ya que las solicitudes de cambio de estado siempre deben usar POST sobre GET.

Esto generaría una lógica compleja al implementar la protección CSRF.

Eso es:

Lack of Origin header = Old browser/bug OR
Lack of Origin header = Same Origin
Origin header matches domain = Same Origin
Origin header does not match = CSRF attack

Como puede ver, no es posible distinguir entre los navegadores antiguos o con errores que posiblemente realicen ataques CSRF y las solicitudes actuales legítimas de los navegadores. Usted podría agregar la detección del navegador, pero luego la lógica se vuelve más complicada. La complejidad tiende a reducir la seguridad.

Esto, por supuesto, podría parchearse en una actualización del navegador. Sin embargo, entonces su aplicación sería incompatible con versiones anteriores del navegador.

Mucho más simple sería generar un token y enviarlo con cada solicitud fuera del mecanismo de cookies.

Se debe principalmente a la historia. Las personas conocen CSRF desde principios de la década de 2000, antes de que se inventara el encabezado Origin. El concepto de "token en un campo oculto" proporcionó a los sitios una forma inmediata de solucionar el error, sin esperar a que los navegadores se actualicen. Si bien el mecanismo es un poco desordenado, resulta que es posible que los marcos proporcionen esta funcionalidad automáticamente, con poca participación de los desarrolladores de aplicaciones. En particular, .Net incluyó esto desde el principio con EVENTVALIDATION / VIEWSTATE, y es relativamente raro que las aplicaciones .Net tengan fallas de CSRF.

Cuando CSRF se tomó en serio por primera vez, algunas personas propusieron revisar el encabezado del Referer para corregir la falla. Es ampliamente conocido que el encabezado del Referer es fácil de falsificar, pero esta idea no es tan tonta como parece. Cuando un atacante hace una conexión directa a un servidor web, es fácil falsificar el encabezado del Referer. Sin embargo, en un ataque CSRF, el atacante no está haciendo una conexión directa; el navegador web de la víctima está haciendo la conexión, y el atacante no puede controlar fácilmente el encabezado del Referer. Sin embargo, este enfoque sigue siendo defectuoso. Las versiones anteriores de Flash permitían a un atacante el control libre del encabezado del Referer en un escenario de ataque CSRF. Además, algunos usuarios deshabilitan el encabezado del Referer por razones de privacidad, lo que un sitio web podría confundir con un ataque CSRF.

El encabezado de origen se ha desarrollado como un reemplazo más seguro para el encabezado de referencia. En muchos sentidos, es una solución mucho mejor para CSRF y evita la sobrecarga de administrar los tokens. Algunas aplicaciones, especialmente las aplicaciones de una sola página, usan el encabezado Origin como la única protección CSRF y son completamente seguras. Sin embargo, esta es la excepción y no la regla. El patrón del sincronizador es bien comprendido, ampliamente soportado por marcos y no tiene debilidades conocidas.

Editar : Silverlightfox me informa que lo siguiente no es cierto. Ver su respuesta para más información.

En última instancia, creo que OWASP está siendo un poco atrasado en sus consejos. En 2015 deberían recomendar verificaciones de encabezados de origen como control principal, con el patrón de sincronizador como una alternativa heredada.

Cualquier defecto en el navegador, por ejemplo, cuando permite que se establezca el encabezado de Origen en el lado del cliente (es muy poco probable con los navegadores modernos) ahora habilitará los ataques CSRF contra su aplicación.

Además, desde enlace

  

Actualmente no puede depender del encabezado de origen, porque no está implementado en todos los navegadores que están en uso activo. Aparte de eso, el Origen no se envía en todos los casos relevantes para CSRF.

También, de la respuesta de SilverlightFox a una pregunta similar en enlace ,

  

Ha habido vulnerabilidades en los navegadores anteriores, como las de IE 5.5 / 6.0, en las que ha sido posible para los atacantes eludir la Política del mismo origen y ejecutar ataques. Por lo general, puede esperar que estos parches se solucionen tan pronto como se descubran y con la mayoría de los navegadores actualizándose automáticamente, este riesgo se mitigará principalmente.

y

  

Las versiones anteriores de Flash permitían establecer encabezados arbitrarios que permitirían a un atacante enviar una solicitud con un encabezado de referencia falso desde la máquina de la víctima para ejecutar un ataque.