¿Cómo se protegen contra ataques CSRF el envío de encabezados HTTP de referencia?

Para comprender esto, primero hay que entender qué es una falsificación de solicitud entre sitios.

Una falsificación de solicitud entre sitios es cuando el atacante tiene algún script o medio incrustado en un sitio web que controla, lo que hace que cualquier visitante a ese sitio solicite un recurso de un sitio diferente. Esa solicitud aparece ante ese otro sitio en el contexto del usuario. Podría, por ejemplo, agregar una imagen con la url https://othersite.example.com/delete_my_account.php?really=true a mi sitio web. Cuando visite mi sitio y haya iniciado sesión en su cuenta en othersite.example.com , su navegador solicitará esa URL, lo que causaría que othersite.example.com elimine su cuenta.

Pero hay un problema: cuando othersite.example.com puede leer su referencia, puede ver que esta solicitud es causada por alguien que interactúa con un sitio diferente. No hay una buena razón por la que un sitio web tenga un vínculo profundo a una URL que realice una acción. Cuando el otro sitio rechaza las solicitudes sin un referente, ese ataque se vuelve imposible.

Con respecto a la falsificación de referencias: tenga en cuenta que el cliente que realiza la solicitud no es el atacante. El atacante es un operador de sitio web. Lo peor que puede hacer el operador es hacer que su navegador web ejecute Javascript en el contexto de su sitio web. Si bien hay varias formas de realizar solicitudes a otros sitios web utilizando Javascript, ninguna de esas API permite falsificar el referente.

  

¿No pudo el atacante simplemente falsificar el encabezado del remitente?

No, no pueden.

Obviamente, no es posible al enviar un formulario (o los diversos métodos GET, como etiquetas de imagen o URL en CSS), y tampoco es posible a través de XMLHttpRequest, según documentación .

Dicho esto, sugeriría usar un token en su lugar, ya que la verificación del referer puede omitirse si existe una vulnerabilidad de redireccionamiento abierto y la aplicación no tiene un estado de reposo, o si permite una baja a GET y contiene vulnerabilidades de redireccionamiento abiertas Vulnerabilidades de inyección de HTML, o vulnerabilidades de inyección de CSS. También puede causar problemas de uso (como en su caso).