¿Puede la verificación de los encabezados HTTP proteger contra CSRF? [duplicar]

Todas las protecciones CSRF que solo se basan en poner un valor predecible en un encabezado HTTP tienen los mismos problemas básicos:

• Si habilita CORS con Access-Control-Allow-Headers , es posible que de repente esté permitiendo que el encabezado X-Requested-With se establezca en el origen. Por supuesto, puede resolver esto simplemente no estableciendo una política CORS incorrecta. (El encabezado Referer es "prohibido" , y no se puede configurar sin importar su CORS política.)

• Ha habido Explosiones de Flash (y si el historial es una guía, habrá más) que permite establecer encabezados en solicitudes de origen cruzado. Claro, Flash está muriendo, pero no está muerto todavía.

• El encabezado Referer puede estar en blanco por muchos motivos legítimos (por ejemplo, eliminado por un proxy). Para que esta comprobación sea segura, tendría que bloquee las solicitudes con un encabezado en blanco , pero al mismo tiempo bloquee muchas solicitudes legítimas.

Por lo tanto, me temo que todavía debes confiar en establecer un encabezado (o alguna otra variable) en un valor que un atacante no pueda predecir. En la práctica, esto lo deja con un par de opciones, como un token clásico, una cookie de doble envío o el uso de un token de portador en el encabezado de autenticación.

Como siempre, leer OWASP brinda mucha orientación.

OWASP tiene recomendaciones sobre este tema . En resumen, deberías tener cheques de dos puntas:

1. Asegúrese de que el origen de origen sea el mismo que el origen de destino. Utilice el encabezado 'Origen' o el 'Referer', en ese orden de preferencia. Y si ninguno de los dos está presente, rechazar.
2. Hacer uso del token CSRF

Por cierto, es posible que también desee consultar La misma cookie del sitio como medio de protección contra CSRF .