asp.net-mvc - forgery - token anti csrf
¿Previene AntiForgeryToken en MVC de ASP.NET contra todos los ataques CSRF? (2)
Sí, esto es todo lo que necesitas hacer.
Siempre que genere un nuevo token en cada página protegida, con <%= Html.AntiForgeryToken() %> y siempre asegúrese de que esté marcado en cualquier acción protegida, usando [ValidateAntiForgeryToken]
Esto implementa el Patrón de token del sincronizador como se explica en la Hoja de referencia de prevención de CSRF en OWASP.
Para que una secuencia de comandos pueda realizar una solicitud aceptable, primero debe obtener el formulario, leer el token y luego publicar el token. La misma política de origen evitará que esto se permita en un navegador. Un sitio no puede realizar una solicitud http de estilo AJAX a otro sitio; sólo para sí mismo. Si por alguna razón se puede violar la misma política de origen, entonces se volverá vulnerable.
Tenga en cuenta que si tiene una vulnerabilidad de secuencias de comandos entre sitios, entonces un atacante puede abusar de la vulnerabilidad xss para eludir la protección proporcionada por la misma política de origen (porque la secuencia de comandos ahora se ejecuta desde su propio sitio, por lo que SOP tiene éxito). El script inyectado puede leer y volver a enviar el token. Esta técnica para superar la protección CSRF a través de XSS ha sido común en algunos gusanos recientemente. Básicamente, si tiene XSS, su protección CSRF es una pérdida de tiempo, así que asegúrese de no ser vulnerable a ninguno de los dos.
Otra cosa a tener en cuenta es Flash y Silverlight. Ambas tecnologías no se suscriben a la misma política de origen y, en su lugar, utilizan archivos de políticas de dominios cruzados para restringir el acceso a recursos remotos. La secuencia de comandos de Flash / Silverlight solo puede acceder a los recursos de su sitio si publica un archivo xml de políticas de varios dominios en su propio sitio. Si publica este archivo, solo permita una lista blanca de servidores de terceros de confianza y nunca permita *.
Lea más sobre CSRF en OWASP Vea también: Hoja de referencia de prevención XSS
El uso de AntiForgeryToken requiere que cada solicitud pase un token válido, por lo que las páginas web malintencionadas con un simple script que publica datos en mi aplicación web no tendrán éxito.
Pero, ¿qué sucede si un script malicioso realiza primero una solicitud GET simple (por Ajax ) para descargar la página que contiene el token antiforgery en un campo de entrada oculto, extraerlo y usarlo para hacer un POST válido?
¿Es posible, o me falta algo?
Pero, ¿qué sucede si el script malicioso realiza primero una solicitud GET simple (por AJAX) para descargar la página que contiene el token antiforgery en el campo de entrada oculto, lo extrae y lo usa para validar el POST?
Sí, esto es cierto, pero, si no termina en un navegador, NO es un ataque CSRF.
Si lo finaliza en el navegador (por ejemplo, raspando a través de una solicitud HTTP en el código del lado del servidor), entonces, ¿qué sucedería si el código del raspado obtendría un token CSRF? Sin embargo, sus usuarios legítimos y autenticados obtendrán un token diferente puesto en su máquina. Debido a que el token que levanta el raspador es diferente al que se le entregó a sus usuarios, la POST fallará.
Si desea evitar que los scripts que no son del navegador realicen publicaciones, debe adoptar otro enfoque para validar que es un ser humano.