it-swarm-es.com

¿Debo usar AntiForgeryToken en todos los formularios, incluso para iniciar sesión y registrarme?

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 puesto el AntiForgeryToken en varias formas, que modifican los datos protegidos, etc.

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

El formulario de inicio de sesión requiere que el afiche conozca las credenciales correctas. Realmente no puedo pensar de ninguna manera que un ataque CSRF se beneficiaría aquí, especialmente si verifico que la solicitud vino del mismo Host (verificando el encabezado Referer).

El token AntiForgeryToken genera diferentes valores 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 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 pedir problemas.

Posiblemente hay otras razones por las que uno debería usar o no usar el token en sus formularios. Estoy en lo cierto al suponer que usar el token en cada formulario de publicación es excesivo, y si es así, qué tipo de formularios se beneficiarían de él y cuáles definitivamente no ¿beneficio?

PD Esta pregunta también se hace en StackOverflow, pero no estoy completamente convencido. Pensé en pedirlo aquí, para obtener más cobertura de seguridad

82
Artiom Chilaru

Sí, es importante incluir tokens antifalsificació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 contra Alice, que es 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 antifalsificación), entonces el atacante puede iniciar sesión silenciosamente en el navegador de Alice en la cuenta de Evelyn en Paypal. Alice es llevada al sitio web de Paypal, y Alice inicia sesión, pero inicia 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 en la tarjeta de crédito de Alice. Ups Esto es sutil y un poco oscuro, pero lo suficientemente grave como para incluir tokens antifalsificació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 del mundo real de tales vulnerabilidades.

¿Cuándo está bien dejar el token antifalsificación? En general, si el objetivo es una URL, y acceder a esa URL no tiene efectos secundarios, entonces no necesita incluir un token antifalsificación en esa URL.

La regla general es: incluir un token antifalsificación en todas las solicitudes POST, pero no lo necesita para las solicitudes GET. Sin embargo, esta regla general aproximada es una aproximación muy burda Supone que todas las solicitudes GET no tendrán efectos secundarios. En una aplicación web bien diseñada, debería ser así, pero en la práctica, a veces los diseñadores de aplicaciones web no siguen esa directriz e implementan los controladores GET que tienen un efecto secundario (esta es una mala idea, pero no es infrecuente). Es por eso que sugiero una guía basada en si la solicitud tendrá un efecto secundario en el estado de la aplicación web o no, en lugar de basarse en GET vs ENVIAR.

72
D.W.

Donde podría ser necesario tener el token en una página de inicio de sesión es cuando necesita evitar que alguien inicie sesión maliciosamente en el sitio con credenciales particulares. Puedo ver que este sea el caso si alguien está siendo acusado de algo que requiere iniciar sesión con un usuario en particular. Dicho esto, es un poco un ejemplo artificial.

2
Steve