¿Debo usar un token CSRF por página o por formulario?

Question

¿Debo usar un token CSRF por página o por formulario?

#1 de Polynomial (3 votos)
#2 de Xiong Chiamiov (0 votos)

1

¿Es seguro usar un token CSRF por formulario en mi página, por ejemplo:

<form>
    <input type="hidden" name="token" vale="<?=$data['login_token'];?>" />"
</form>
<form>
    <input type="hidden" name="token" vale="<?=$data['register_token'];?>" />"
</form>

O debería usar un token genérico para cada formulario, por ejemplo:

<form>
    <input type="hidden" name="token" vale="<?=$data['token'];?>" />"
</form>
<form>
    <input type="hidden" name="token" vale="<?=$data['token'];?>" />"
</form>

Tenga en cuenta que actualizaré el token en cada solicitud de página.

web-application csrf php

pregunta MisterQuacker 09.05.2016 - 21:08

fuente

2 respuestas

0

Considere contra qué está protegiendo: un atacante engaña a un usuario para que haga una solicitud que no crea que está haciendo. ¿Cómo protegerían múltiples tokens diferentes en la página contra eso más que uno solo?

respondido por el Xiong Chiamiov 09.05.2016 - 21:10

fuente

Lea otras preguntas en las etiquetas web-application csrf php

Si un pirata informático obtuviera un número de seguimiento de envío, ¿qué podría verse comprometido? ¿La mejor manera de prevenir ransomware y virus? [cerrado]

score 3 · Accepted Answer

Como esta pregunta Menciona, un único token no descargable al azar por sesión es suficiente .

Cuando comienzas a generar tokens por página o por formulario, simplemente estás limitando el impacto de un token CSRF que se está filtrando. Los casos de fuga de tokens singulares son errores relativamente raros, pero XSS es obviamente un vector común.

En ciertos casos, tiene sentido tener un token CSRF por página o por formulario, ya que cuando se combina con otras funciones de protección (por ejemplo, deshabilitar Ajax con la directiva connect-src de CSP), puede limitar la capacidad de un error XSS para comprometa los tokens CSRF a la página en la que se produjo el XSS, suponiendo que se asegure de que el token no se pueda reutilizar en otro lugar.

Algunas personas promueven la protección CSRF por página o por formulario como una forma de aumentar la seguridad cuando se utiliza un método de cookies de envío doble, pero no creo que esto sea sensato: si tiene un error que le permite leer un cookie, acabas de leer el ID de sesión.

La otra cara del argumento es que al implementar la protección CSRF más granular, agrega complejidad adicional a su código, lo que aumenta la superficie de ataque y el potencial de errores.

Personalmente, me quedo con un solo token por sesión y luego implemento otros controles anti-automatizados (por ejemplo, captcha, reingreso de contraseña) sobre esto cuando sea necesario para mayor seguridad.