2010-10-17 17 views

Respuesta

9

Básicamente, los tokens antifalsificación evitan que alguien envíe solicitudes a su sitio que son generados por un script malicioso no generado por el usuario real. Existe una cookie HTTP única (no legible mediante un script que se ejecuta en el navegador, pero que el navegador envía y al que puede acceder el servidor) que se envía al cliente, se utiliza para generar un valor de campo oculto que luego se valida con el Galleta. Al menos creo que ese es el proceso.

Hay una buena descripción de este aquí que es exactamente lo que usted está planteando https://blogs.msmvps.com/luisabreu/blog/2009/02/09/the-mvc-platform-the-new-anti-forgery-token/

0

En general, el token anti falsificación es una entrada oculta HTML que se representa para evitar los ataques CSRF. En términos generales, funciona comparando el valor que el servidor envía al cliente con lo que el cliente envía de vuelta a la publicación. ¿Eso es todo lo que estás buscando?

Probablemente deberías consultar MSDN para más detalles.

+0

me gustaría entender mejor lo que es el problema abordado. Supongo que es un poco diferente de XSS. ¿No es así? – Lorenzo

+2

@Lorenzo: 'AntiForgeryToken' se usa para defenderse contra CSRF, no contra XSS. http://en.wikipedia.org/wiki/Cast-site_request_forgery – LukeH

+0

@LukeH: Gracias por la corrección. –

6

El uso de AntiForgeryToken ayuda a mitigar los ataques cross-site request forgery.

Cuando lo utiliza, su formulario contendrá un campo oculto y una cookie correspondiente también se establecerá en el navegador.

Luego, cuando se envía el formulario, el campo oculto se compara con el valor de la cookie (suponiendo que se usa ValidateAntiForgeryTokenAttribute): si el campo y la cookie coinciden, la publicación del formulario es probablemente genuina; si no lo hacen, entonces probablemente no lo sea. (Un atacante que intente un ataque CSRF podría forjar el campo oculto, pero tampoco deberían poder forjar el valor de la cookie correspondiente.)

+0

Gracias por la respuesta. Si todos los valores del usuario se han codificado correctamente en el código, ¿todavía puede suceder esto? – Lorenzo

+0

@LukeH o alguien más: ¿cómo podría el usuario forjar el campo oculto? – ilans

2

Pues bien, hoy, vamos a ver un tipo de violación de la seguridad en una aplicación web que se llama Cross Site Request Falsificación o CSRF pirateo. CSRF es el primo menos conocido de XSS.Cross Site Request forgery es un tipo de hack donde el hacker explota la confianza de un sitio web en el usuario.

La manera más fácil de hacer esto es utilizar el atributo simbólico ValidateAnitForgery en los Detalles del producto método de acción publicar la siguiente manera

[HttpPost] 
[Authorize(Roles = "Admins")] 
[ValidateAntiForgeryToken()] 
public ActionResult Edit(ProductDetails productdetails) 
{ 
    if (ModelState.IsValid) 
    { 
    db.Entry(productdetails).State = EntityState.Modified; 
    db.SaveChanges(); 
    return RedirectToAction("Index"); 
} 
return View(productdetails); 
} 

para generar el AntiForgeryToken y de la galleta en el lado del cliente, lo declaramos como sigue en el formulario HTML en el Edit.cshtml

@using (Html.BeginForm()) { 
@Html.ValidationSummary(true) 
@Html.AntiForgeryToken() 
<fieldset> 
    <legend>ProductDetails</legend> 

...

Esto asegura que un formulario se ha publicado en el servidor era en realidad Gen generada por el mismo servidor. Por lo tanto, los formularios falsos que no tienen el AntiForgeryToken del servidor correcto son rechazados.

también refieren el ejemplo simple aquí

https://github.com/devcurry/mvc101-anti-forgery-token