¿Usar encabezado en lugar de cookie para CSRF enviar doble cookies?

La razón para usar el envío doble (en lugar de un token de sincronizador) es que no desea tener que hacer una búsqueda en el servidor para cada solicitud. Por lo tanto, siempre que el valor de la cookie coincida con el del parámetro de solicitud, se pasará la solicitud.

Eso funciona porque evil.com no puede leer las cookies de example.com (y, por lo tanto, enviar un parámetro de solicitud coincidente), ni establecerlas (y, por lo tanto, establecer ambas a una constante arbitraria).

Es correcto señalar que esto falla para los subdominios. Es posible para evil.example.com para establecer un coockie que se usará para example.com y, por lo tanto, omitir la prueba. Entonces, si no confía en sus subdominios, ¡no use esta solución para la protección de CSRF!

Ahora, ¿tu propuesta resuelve el problema? No. En realidad lo hace peor. Como ya no necesita leer ni modificar ningún valor de cookie, se trata de poder modificar los encabezados de solicitud. Así que esto es lo mismo que simplemente confiar en un solo encabezado con un valor constante, por ejemplo. el comúnmente utilizado:

X-Requested-With: XMLHttpRequest

Tienes dos problemas aquí:

1. Aún eres vulnerable a un ataque de evil.example.com ya que un subdominio puede modificar los parámetros de solicitud a sus padres usando document.domain .
2. También puede ser vulnerable a los ataques de evil.com , ya que ha habido que le permiten establecer encabezados para solicitudes de dominios cruzados.

No está claro lo que está intentando lograr, por lo que es difícil proporcionar información específica, pero se pueden encontrar algunas pautas básicas sobre la prevención de ataques de CSRF en Hoja de referencia de prevención de CSRF de OWasp . Con suerte, eso ayudará a guiarlo por un camino efectivo hacia sus objetivos de seguridad.