asp.net-mvc - cookie - csrf token c#

¿Cuál es el uso de sal token anti-falsificación?

Question

En ASP.NET MVC 1.0, hay una nueva característica para manejar el problema de seguridad de falsificación de solicitud entre sitios:

 <%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    // ... etc
}

Encontré que el token generado en el formulario html cambia constantemente cada vez que se representa un nuevo formulario.

¿Quiero saber cómo se generan estos token? Y cuando use algún software para escanear este sitio, notificará otro problema de seguridad: la sesión se arregló. ¿Por qué? Dado que el token sigue cambiado, ¿cómo puede surgir este problema?

Y hay otra función, que es "sal" para el antiForgeryToken , pero realmente sé para qué se usó, incluso aunque no usemos "sal" para generar el token, el token cambia todo el tiempo, así que, ¿por qué? tal función?

Answer 1

Mucha información sobre el AntiForgeryToken aquí: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Esto es para evitar una falsificación de solicitud entre sitios (CSRF). Es un comportamiento bastante estándar hacer clic en ''Guardar'' para agregar un formulario y realizar alguna acción en el servidor, es decir, guardar los detalles de un usuario. ¿Cómo sabe que el usuario que envía el formulario es el usuario que dice ser? En la mayoría de los casos, usaría alguna cookie o autenticación basada en Windows.

¿Qué sucede si un atacante lo atrae a un sitio que envía exactamente la misma forma en un pequeño IFRAME oculto? Sus cookies se envían intactas y el servidor no ve la solicitud como algo diferente a una solicitud legítima. (Como ha descubierto Gmail: http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/ )

El token anti-falsificación previene esta forma de ataque al crear un token de cookie adicional cada vez que se genera una página. El token está tanto en el formulario como en la cookie, si el formulario y la cookie no coinciden, tenemos un ataque CSRF (ya que el atacante no podría leer el token anti-falsificación utilizando el ataque descrito anteriormente).

Y qué hace la sal, del artículo anterior:

La sal es sólo una cadena arbitraria. Un valor de sal diferente significa que se generará una ficha anti-falsificación diferente. Esto significa que incluso si un atacante logra obtener un token válido de alguna manera, no puede reutilizarlo en otras partes de la aplicación donde se requiere un valor de sal diferente.

Actualización: ¿Cómo se genera el token? Descargue la source y eche un vistazo a las clases de AntiForgeryDataSerializer, AntiForgeryData.

Answer 2

Usted ha pedido algunos problemas no relacionados:

1. No sé por qué su software de seguridad está reportando ''sesión arreglada''. Trate de leer la documentación que viene con el informe
2. El token anti-falsificación:

Esto se usa (probablemente) para validar que cada solicitud es válida. Entonces, considere que alguien intenta presentar un enlace a la página ?x=1 , si el token no se pasa también, la solicitud será rechazada. Además, (puede) evitar la publicación duplicada del mismo artículo. Si hace clic en ''publicar'' dos veces, es probable que el token cambie (cada solicitud), y este caso se detectará a través de algo como:

Session["nextToken"] = token;
WriteToken(token);

...

if( !Request["nextToken"] == Session["nextToken"] ){
    ...
}

// note: order in code is slightly different, you must take the token
// before regenerating it, obviously

Creo que el término para esto (el ataque que protege) se llama "CSRF" (falsificación de solicitud entre sitios), en estos días.