¿Debo usar AntiForgeryToken en todos los formularios, incluso en el inicio de sesión y el registro?

78

Estoy ejecutando un sitio bastante grande con miles de visitas todos los días y una base de usuarios bastante grande. Desde que comencé a migrar a MVC 3, he estado poniendo el AntiForgeryToken en varios formularios, que modifican los datos protegidos, etc.

Algunas otras formas, como el inicio de sesión y el registro, también usan AntiForgeryToken ahora, pero en primer lugar me estoy poniendo en duda sobre su necesidad, por un par de razones ...

El formulario de inicio de sesión requiere que el póster conozca las credenciales correctas. Realmente no puedo pensar en ninguna forma en que un ataque CSRF se beneficiaría aquí, especialmente si verifico que la solicitud provino del mismo servidor (verifique el encabezado del Referer).

El token AntiForgeryToken genera valores diferentes cada vez que se carga la página. Si tengo dos pestañas abiertas con la página de inicio de sesión y luego intento publicarlas, la primera se cargará correctamente. El segundo fallará con una excepción AntiForgeryTokenException (primero cargue ambas páginas, luego intente publicarlas). Con páginas más seguras, esto es obviamente un mal necesario, con las páginas de inicio de sesión, parece una exageración, y solo es buscar problemas.

Es posible que existan otras razones por las que uno debería usar o no el token en las formas. ¿Tengo razón al suponer que el uso del token en cada forma de publicación es una exageración y, en caso afirmativo, qué tipo de formularios se beneficiarían de él y cuáles de ellos definitivamente no se beneficiarían?

P.S. Esta pregunta también se hace en StackOverflow, Pero no estoy del todo convencido. Pensé que lo pediría aquí, para más cobertura de seguridad

    
pregunta Artiom Chilaru 11.02.2011 - 22:08
fuente

2 respuestas

68

Sí, es importante incluir tokens anti-falsificación para las páginas de inicio de sesión.

¿Por qué? Debido a la posibilidad de ataques de "inicio de sesión CSRF". En un ataque CSRF de inicio de sesión, el atacante registra a la víctima en el sitio de destino con la cuenta del atacante. Considere, por ejemplo, un ataque a Alice, que es un usuario de Paypal, por un malvado atacante Evelyn. Si Paypal no protegió sus páginas de inicio de sesión de los ataques CSRF (por ejemplo, con un token anti-falsificación), el atacante puede registrar silenciosamente el navegador de Alice en la cuenta de Evelyn en Paypal. Alice es llevada al sitio web de Paypal y Alice ha iniciado sesión, pero ha iniciado sesión como Evelyn. Supongamos que Alice hace clic en la página para vincular su tarjeta de crédito a su cuenta de Paypal e ingresa su número de tarjeta de crédito. Alice cree que está vinculando su tarjeta de crédito a su cuenta de Paypal, pero en realidad la ha vinculado a la cuenta de Evelyn. Ahora Evelyn puede comprar cosas y cargarlas a la tarjeta de crédito de Alice. Ups. Esto es sutil y un poco oscuro, pero lo suficientemente serio como para incluir tokens anti-falsificación para el objetivo de acción de formulario utilizado para iniciar sesión. Consulte este documento para obtener más detalles y algunos ejemplos reales de dichas vulnerabilidades.

¿Cuándo está bien omitir el token anti-falsificación? En general, si el objetivo es una URL y el acceso a esa URL no tiene efectos secundarios, no es necesario que incluya el token anti-falsificación en esa URL.

La regla general es: incluir un token anti-falsificación en todas las solicitudes POST, pero no es necesario para las solicitudes GET. Sin embargo, esta regla general es una aproximación muy cruda. Supone que todas las solicitudes GET estarán libres de efectos secundarios. En una aplicación web bien diseñada, ese debería ser el caso, pero en la práctica, a veces los diseñadores de aplicaciones web no siguen esa pauta e implementan controladores GET que tienen un efecto secundario (esto es una mala idea, pero no es raro) . Es por eso que sugiero una guía basada en si la solicitud tendrá un efecto secundario al estado de la aplicación web o no, en lugar de basarse en GET vs POST.

    
respondido por el D.W. 12.02.2011 - 03:32
fuente
2

Donde podría ser necesario tener el token en una página de inicio de sesión es cuando debe evitar que alguien lo inicie de manera malintencionada en el sitio con credenciales específicas. Puedo ver que este es el caso si alguien está encuadrado por algo que requiere iniciar sesión con un usuario particular. Dicho esto, es un ejemplo un poco artificial.

    
respondido por el Steve 12.02.2011 - 02:59
fuente

Lea otras preguntas en las etiquetas