Pregunta

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

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

Descubrí que el token generado en forma html cambia constantemente cada vez que se presenta un nuevo formulario.

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

Y hay otra función, que es '' sal '' para el antiForgeryToken , pero realmente sé para qué sirve esto, incluso si no usamos "sal" para generar el token, el token cambiará todo el tiempo, entonces, ¿por qué tener esa función?

¿Fue útil?

Solución

Mucha información sobre 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 solicitudes entre sitios (CSRF). Es un comportamiento bastante estándar hacer clic en 'Guardar' para enviar 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 algunas cookies o autenticación basada en Windows.

¿Qué sucede si un atacante lo atrae a un sitio que envía exactamente el mismo formulario en un IFRAME oculto? Sus cookies se envían intactas y el servidor no ve la solicitud como algo diferente a una solicitud legítima. (Como descubrió gmail: http: //www.gnucitizen. org / blog / google-gmail-e-mail-secuestro-técnica / )

El token antifalsificación evita 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 antifalsificación utilizando el ataque descrito anteriormente).

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

  

La sal es solo una cadena arbitraria. Un valor de sal diferente significa que se generará un token antifalsificació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 fuente y eche un vistazo a las clases AntiForgeryDataSerializer, AntiForgeryData.

Otros consejos

Has preguntado algunos problemas no relacionados:

  1. No sé por qué su software de seguridad informa 'sesión fija'. Intente leer la documentación que viene con el informe
  2. El token antifalsificación:

Esto se usa (presumiblemente) 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, la solicitud será rechazada. Además, (puede) evitar la publicación duplicada del mismo artículo. Si hace clic en "publicar" dos veces, el token probablemente cambiará (cada solicitud), y este caso se detectará mediante 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 solicitudes entre sitios), en estos días.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top