Jaggedno está en línea actualmente
- toms shoes outlet
- 16373
|
En la prevención de ataques CSRF, asp.net mvc proporciona ValidateAntiForgeryToken características contra ataques de falsificación, en la nueva versión del asp.net core framework Microsoft proporciona AutoValidateAntiforgeryToken características, específicas ValidateAntiForgeryToken y AutoValidateAntiforgeryToken cuál es la diferencia, este artículo hará una explicación detallada.
mvc ajax con AntiForgeryToken para prevenir ataques CSRF
h ttps:// www.itsvse.com/thread-4207-1-1.html
ASP.NET CSRF Attack Ajax Request Encapsulation
h ttps:// www.itsvse.com/thread-8077-1-1.html
CSRF Cross-Site Request Forgery (Cross-Site Request Forgery), con ataques XSS, hay un gran peligro, se puede entender de esta manera: el atacante robó su identidad, en su nombre para enviar una solicitud maliciosa al servidor esta solicitud es completamente legítimo, pero completó el atacante espera que el Una operación, como en su nombre para enviar correo, enviar mensajes, robar su cuenta, añadir el administrador del sistema, e incluso comprar bienes, las transferencias de moneda virtual y así sucesivamente. Lo siguiente: Web A es el sitio web con la vulnerabilidad CSRF, Web B es el sitio web malicioso construido por el atacante, y el usuario C es el usuario legítimo del sitio web Web A.
ASP.NET MVC contra ataques CSRF
En la página de vista, utilice @Html.AntiForgeryToken() para añadir un token, cuando el usuario visite la página, el back-end generará automáticamente un código html oculto a partir del token, como sigue:
<input name="__RequestVerificationToken" type="hidden" value="" CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_ KUUDbK-LS4HD16pJusFRppj-dEGc" />
Diferencia entre ValidateAntiForgeryToken y AutoValidateAntiforgeryToken
AutoValidateAntiforgeryTokenAuthorizationFilter hereda de ValidateAntiforgeryTokenAuthorizationFilter y sólo anula el método ShouldValidate.
AutoValidateAntiforgeryToken Atributo que provoca la validación del token antifalsificación para todos los métodos HTTP inseguros. Los tokens antifalsificación son necesarios para todos los métodos HTTP excepto GET, HEAD, OPTIONS y TRACE. Puede aplicarse como filtro global para activar la validación del token antifalsificación de la aplicación por defecto.
h ttps:// github.com/dotnet/aspnetcore/blob/c925f99cddac0df90ed0bc4a07ecda6b054a0b02/src/Mvc/Mvc.ViewFeatures/src/Filters/ AutoValidateAntiforgeryTokenAuthorisationFilter.cs
AutoValidateAntiforgeryTokenAttribute valida la llamada a AutoValidateAntiforgeryTokenAuthorizationFilter. AutoValidateAntiforgeryTokenAuthorizationFilter hereda de ValidateAntiforgeryTokenAuthorizationFilter y anula el método ShouldValidate. true significa que debe ser validado, return false no será validado, como se muestra en la siguiente figura:
Analiza el código fuente:
AutoValidateAntiforgeryTokenAttribute permite aplicar la validación de token antifalsificación de forma global a todos los métodos inseguros como POST, PUT, PATCH y DELETE.Por lo tanto, no es necesario añadir el atributo [ValidateAntiForgeryToken] a cada acción que lo requiera. a todas las acciones que lo necesiten.
Para utilizarlo, añada el siguiente código al método de la clase Startup de su ConfigureServices:
Si necesitas ignorar la autenticación anti-falsificación, puedes añadir el atributo [IgnoreAntiforgeryToken ] a la acción.
A veces puedes encontrarte con la necesidad de tokenizar múltiples peticiones en un controlador, mientras que al mismo tiempo necesitas que algunas peticiones no sean falsificadas, como varias operaciones basadas en GET. Hay varias herramientas que puedes utilizar para hacer el proceso más fácil y cómodo. La primera es la propiedad AutoValidateAntiforgeryToken. Se comporta de forma similar al atributo ValidateAntiForgeryToken. Sin embargo, ignora automáticamente las acciones invocadas por los métodos diseñados para la recuperación de datos: GET, HEAD, OPTIONS y TRACE.Esto le permite añadir rápida y fácilmente métodos anti-falsificación a todos los métodos que pueden cambiar datos sin afectar a los métodos que recuperan los datos.
El siguiente código es un ejemplo de la propiedad AutoValidateAntiforgeryToken:
En este ejemplo, tanto las operaciones de Indexación normales (GET) funcionarán, independientemente de la fuente, mientras que las operaciones de Indexación con métodos POST y las operaciones RemoveUser como métodos Delete requerirán que el cliente utilice un token anti-falsificación.
Personalización de la información relevante
Puede que haya mucha gente que piense que el nombre del campo oculto generado puede cambiarse por el suyo, y el nombre de la cookie puede cambiarse por el suyo ~~.
La respuesta es sí, he aquí una sencilla demostración:
En el método ConfigureServices de Startup, añadir el siguiente contenido para cambiar el nombre por defecto en consecuencia.
Nota: La mayor diferencia entre asp.net core y asp.net es que core soporta pasar parámetros de validación a través de la cabecera de la petición, ¡no del formulario!
private const string AntiforgeryTokenFieldName = "__RequestVerificationToken";
private const string AntiforgeryTokenHeaderName = "RequestVerificationToken";
Puede ver el código fuente: https: //github.com/dotnet/aspnetcore/blob/c925f99cddac0df90ed0bc4a07ecda6b054a0b02/src/Antiforgery/src/Internal/ DefaultAntiforgery.cs
Código de prueba:
Resultado: Al intentar acceder al método test1 devuelve un error 400, y al acceder al método test2 devuelve el parámetro str que pasamos, por lo que se puede ver que la función AutoValidateAntiforgeryToken no intercepta las peticiones GET.
(fin)
|
Anterior: Fiddler reemplazar enlaces, solicitud de redirección de reenvíoNext ：[Informe]SQL Server recuento de SQL en la adición de condiciones
|
发表于 2021-2-20 19:57:29
f 
