|
|
Publicado en 20/2/2021 19:57:29
|
|
|
|
Para prevenir ataques CSRF, asp.net mvc proporciona la función anti-falsificación ValidateAntiForgeryToken, y en la nueva versión del asp.net framework central, Microsoft proporciona la función AutoValidateAntiforgeryToken, específicamente ValidateAntiForgeryToken y AutoValidateAntiforgeryToken ¿Cuál es la diferencia? Este artículo lo explicará en detalle.
Concepto CSRF
La falsificación de solicitudes cruzadas CSRF, al igual que los ataques XSS, es extremadamente dañina; puedes entenderlo así: el atacante roba tu identidad y envía una solicitud maliciosa en tu nombre, que es completamente legítima para el servidor, pero realiza una acción que el atacante espera, como enviar correos electrónicos y mensajes a tu nombre, robar tu cuenta, añadir administradores del sistema o incluso comprar bienes. transferencias de moneda virtual, etc. Web A es un sitio web con una vulnerabilidad CSRF, Web B es un sitio web malicioso creado por un atacante, y el Usuario C es un usuario legítimo de Web A.
ASP.NET MVC contra ataques de la CSRF
En la página de visualización, utiliza @Html.AntiForgeryToken() para añadir una etiqueta y, cuando el usuario acceda a la página, el backend generará automáticamente un código html oculto con la etiqueta, de la siguiente manera:
<nombre de entrada="__RequestVerificationToken" tipo="oculto" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
ValidateAntiForgeryToken y AutoValidateAntiforgeryToken son diferentes
AutoValidateAntiforgeryTokenAuthorizationFilter hereda el ValidateAntiforgeryTokenAuthorizationFilter, pero solo reescribe el método ShouldValidate en él.
AutoValidateAntiforgeryToken que provoca la validación de los tokens anti-falsificación para todos los métodos HTTP inseguros.Los métodos HTTP distintos a GET, HEAD, OPTIONS y TRACE requieren un token anti-falsificación。 Esto puede aplicarse como un filtro global para activar por defecto la validación de tokens anti-falsificación de la aplicación.
El inicio de sesión del hipervínculo es visible.
AutoValidateAntiforgeryTokenAttribute valida la llamada a AutoValidateAntiforgeryTokenAuthorizationFilter, que hereda de ValidateAntiforgeryTokenAuthorizationFilter,El método ShouldValidate ha sido reescrito, devolver true significa que debe validarse, y si devuelve false no se validará, como se muestra en la figura siguiente:
Analiza el código fuente:
AutoValidateAntiforgeryTokenAttribute permite aplicar globalmente la validación de tokens anti-falsificación a todos los métodos inseguros, como POST, PUT, PATCH y DELETE. Así que no necesitas añadir la propiedad [ValidateAntiForgeryToken] a cada acción que la requiera.
Para usarlo, añade el siguiente código al método de la clase Inicio de tu ConfigureServices:
Si necesitas ignorar la autenticación antifalsificación, puedes añadir [IgnorarAntifalsificaciónTokenAtribuye a la acción.
A veces puede que necesites etiquetar varias solicitudes en un controlador mientras necesitas otras que no necesitan ser falsificadas, como diversas operaciones basadas en GET. Hay varias herramientas que puedes usar para hacer el proceso más cómodo y cómodo. La primera es la propiedad AutoValidateAntiforgeryToken. Se comporta como la propiedad ValidateAntiForgeryToken. Sin embargo, ignorará automáticamente las acciones que llaman los métodos diseñados para la recuperación de datos: GET, HEAD, OPTIONS y TRACE. Esto permite añadir rápida y fácilmente métodos antifalsificación a todos los métodos que pueden modificar datos sin afectar la forma en que se recuperan.
El siguiente código es un ejemplo de la propiedad AutoValidateAntiforgeryToken:
En este ejemplo, ambas operaciones normales de Índice (GET) funcionarán independientemente de la fuente, mientras que tanto la operación de Índice con el método POST como la operación RemoveUser como método Delete requerirán que el cliente use un token antifalsificación.
Personaliza la información relevante
Mucha gente puede preguntarse si el nombre del dominio oculto generado puede ser reemplazado por el suyo propio, y si el nombre de la cookie puede cambiarse por el suyo.
La respuesta es sí, vamos a demostrar brevemente:
En el método ConfigureServices de Startup, añade lo siguiente para modificar el nombre predeterminado en consecuencia.
Nota: La mayor diferencia entre asp.net núcleo y asp.net es,Core permite pasar parámetros de validación solicitando un encabezado¡, no para formar formularios!
cadena const privada AntiforgeryTokenFieldName = "__RequestVerificationToken";
cadena const privada AntiforgeryTokenHeaderName = "RequestVerificationToken";
Puedes ver el código fuente:El inicio de sesión del hipervínculo es visible.
Código de prueba:
Resultado: Al intentar acceder al método test1 se devuelve un error 400, acceder al método test2 devuelve el parámetro str que hemos pasado, y puedes ver que la función AutoValidateAntiforgeryToken no intercepta la solicitud GET.
(Fin)
|
Anterior:Fiddler reemplaza enlaces, solicita redireccionesPróximo:[giro] SQL Server SQL Count
|
Propietario|
Publicado en 8/7/2023 22:07:08
|
