¿Vale la pena revisar el referente?

Yo diría que el uso, la falta de, la referencia como el único indicador de un ataque probablemente sea problemático ya que no puede estar seguro de que todos los clientes lo enviarán como se esperaba. En general, usar referrer como protección contra CSRF no se considera una buena idea, ya que puede ser falsificado en algunas circunstancias.

Si no hubiera otras opciones, entonces valdría la pena usarlas, pero para CSRF existen mecanismos de protección mejor establecidos (alguna información. here ) de tal manera que en la mayoría de los casos, el mejor enfoque es utilizar los mecanismos de protección incorporados del marco, a menos que tenga una razón específica por la que no funcionan en su caso de uso o son inadecuadas.

Utilidad

Sí, algunas personas no envían referers. Esto puede ser por razones de privacidad o por razones de seguridad (las URL no deben contener datos confidenciales, como los identificadores de sesión, pero eso no significa que nunca lo hagan).

Seguridad

Si su sitio web tiene una vulnerabilidad de redireccionamiento abierta, las verificaciones del remitente se pueden omitir para las solicitudes GET. Por supuesto, las solicitudes GET no deben cambiar de estado, pero eso no significa que nunca lo hagan.

Conclusión

Para evitar CSRF, usaría un token anti-CSRF. Funciona, y no tiene los inconvenientes de la comprobación del remitente.

Para obtener información sobre los beneficios generales e inconvenientes de consultar al remitente, consulte esta respuesta y para obtener información general sobre la prevención de CSRF. esta guía OWASP .

La referencia puede usarse como una indicación de que algún otro sitio web se vincula directamente a su contenido. Es posible que desee activar algunas restricciones (o simplemente iniciar sesión) cuando encuentre un referente que apunta a un sitio web diferente al suyo por motivos de ancho de banda o derechos de autor.

Sin embargo, usted no debe asumir que cada navegador le enviará un encabezado de "referencia". El RFC 7231 menciona que " no todas las solicitudes lo contienen ", mientras que Wikipedia tiene un bonito párrafo sobre la ocultación del remitente con fines de privacidad. La misma sección de RFC también se ocupa de dichas prácticas, incluso cuando un intermediario elimina el encabezado "referente" como en las corporaciones que menciona:

  

Se sabe que algunos intermediarios eliminan indiscriminadamente a Referer   campos de encabezado de las solicitudes salientes. Esto tiene el lado desafortunado.   efecto de interferir con la protección contra los ataques CSRF, que puede   Ser mucho más perjudicial para sus usuarios. Intermediarios y agente de usuario.   Las extensiones que deseen limitar la divulgación de información en Referer deberían   para restringir sus cambios a ediciones específicas, como reemplazar   nombres de dominio internos con seudónimos o truncando la consulta y / o   componentes de la ruta. Un intermediario NO DEBE modificar o eliminar el   Campo de encabezado de referencia cuando el valor del campo comparte el mismo esquema y   host como el objetivo de solicitud.

Pero como puede ver, no hay obligación de mantener la referencia: " NO DEBE " significa que aún pueden eliminarlo y cumplir con la RFC.

Hay varias razones no malintencionadas por las que un encabezado de referencia puede estar vacío:

• se accedió a la URL desde un marcador, desde dentro de un correo o simplemente se escribió la URL en el navegador
• se deshabilitó la compatibilidad con el Referer en el navegador o se eliminó al Referer mediante un firewall

Aparte de eso, el Referer podría estar deshabilitado por un atributo noreferrer en los enlaces, mediante el uso de etiquetas de actualización meta y otros métodos. Estos métodos pueden ser utilizados por un atacante, pero también pueden usarse para propósitos no relacionados con ataques.

Esto significa que solo puede considerar un encabezado de Referer vacío como un signo de ataque si tiene suficiente control sobre el cliente y puede asegurarse de que solo accederá a su aplicación de la forma que desea. Este podría ser el caso de una GUI web para administrar algún dispositivo local, pero probablemente no sea posible hacerlo con una aplicación web disponible a nivel mundial con muchos clientes diferentes y sus middleboxes (firewall, etc.).

Pero aún puede tomar un Referer inesperado no vacío como signo de un posible ataque y agregar otra capa de protección de esta manera, además de los tokens CSRF.