¿Es suficiente comprobar el referente para protegerse contra un ataque CSRF?

Esta es una pregunta de hace 3 años con cuatro respuestas diferentes que básicamente indican lo mismo: Siga la norma, use tokens, no intente usar referer.

Si bien los tokens todavía se consideran la opción más segura, usar el referer es a menudo mucho más fácil, y también es bastante seguro. Solo asegúrese de mirar todas las solicitudes PUT/POST/PATCH/DELETE y considerarlo un ataque si falta un referente o si proviene del dominio equivocado. Realmente pocos (si es que hay alguno) proxies eliminan el referer para este tipo de peticiones.

Consulte también la recomendación de OWASP sobre la comprobación del encabezado de referencia como protección CSRF:

Comprobación Del Encabezado Del Remitente

Aunque es trivial falsificar el encabezado referer por su cuenta navegador, es imposible hacerlo en un ataque CSRF. Comprobación de la referer es un método comúnmente utilizado para prevenir CSRF en embebido dispositivos de red porque no requiere un estado por usuario. Este convierte a un referente en un método útil de prevención de CSRF cuando la memoria es escaso.

Sin embargo, la comprobación del remitente se considera un más débil de Protección CSRF. Por ejemplo, las vulnerabilidades de redirección abierta pueden ser se usa para explotar solicitudes basadas en GET que están protegidas con un referer comprobar. Cabe señalar que las solicitudes GET nunca deben incurrir en un estado cambiar ya que esto es una violación de la especificación HTTP.

También hay errores comunes de implementación con las comprobaciones de referencia. Para ejemplo si el ataque CSRF se origina a partir de un dominio HTTPS se omitirá el referer. En este caso la falta de un referente debe ser considerado como un ataque cuando la solicitud está realizando un estado cambio. También tenga en cuenta que el atacante tiene una influencia limitada sobre la referer. Por ejemplo, si el dominio de la víctima es "site.com" entonces un atacante tienen el exploit CSRF se originan desde "site.com.attacker.com" lo que puede engañar a una implementación de verificación de referencia rota. Se puede utilizar XSS para evitar a comprobación de referencia.

La única respuesta correcta es "Entre otras cosas, usar el referente no funcionará para los usuarios cuyos navegadores (o proxies corporativos) no envíen referentes."Dicho esto, eso es muy poco común hoy en día. Todas las personas que dicen que los referentes pueden ser falsificados están llenas de eso. No puede falsificar un referente a menos que tenga control sobre el navegador de la otra persona de alguna otra manera (XSS/Trojan/etc). Si necesita referentes para el uso de la aplicación, son tan efectivos como los tokens CSRF. Sólo asegúrate de que eres haciendo 100% seguro de que su cheque es correcto (por ejemplo. si está utilizando expresiones regulares, asegúrese de marcar desde el principio " ^ " del referente).

No no es suficiente, es muy fácil para el atacante hacer que PARA el cliente, como usted pide, todo lo que el atacante tiene que hacer es conseguir que el usuario haga clic en un enlace creado por él, a partir de ese punto, es game over

El atacante copiará el formulario utilizado en el sitio original, y falsificará el resto porque ahora el código está en su propio sitio, luego lo enviará al sitio de la víctima

Como mencionas en la pregunta, los tokens son la norma cuando se trata de prevenir CSRF

Siga la norma: use tokens.

Comprobar el referente en realidad no hace nada, porque la solicitud viene de esa página de todos modos! El problema que está tratando de evitar es que la página se solicita sin que el usuario haga nada; no que la página se golpee en sí misma.

Los tokens son la forma de protegerse contra esto. Generar uno, guárdela en la sesión, y escribir en el HTML, entonces, el momento de la publicación, que marque la recibe, y ver si coincide con el que usted espera. Si no lo hace, fracasas. De cualquier manera, se genera un nuevo token después.

También puede ser relevante considerar que esto arruinará a las personas si tienen varias páginas; por lo que puede que le guste hacer un token diferente por página.