_ _ VIEWSTATE para protegerse contra CSRF

4

No soy un desarrollador .NET y estoy tratando de entender cómo protege exactamente __ViewState contra los ataques CSRF / XSRF.

Encontré lo siguiente:

security Debate de intercambio de pila sobre un tema similar y Guía OWASP para la protección de CSRF

Estoy un poco confundido con cómo exactamente está sucediendo aquí la protección CSRF. Si observamos el siguiente código tomado del enlace OWASP mencionado anteriormente:

    private const string AntiXsrfTokenKey = "__AntiXsrfToken";
    private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
    private string _antiXsrfTokenValue;
    protected void Page_Init(object sender, EventArgs e)
{
    // The code below helps to protect against XSRF attacks
    var requestCookie = Request.Cookies[AntiXsrfTokenKey];
    Guid requestCookieGuidValue;
    if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
    {
       // Use the Anti-XSRF token from the cookie
       _antiXsrfTokenValue = requestCookie.Value;
       Page.ViewStateUserKey = _antiXsrfTokenValue;
    }
    else
    {
       // Generate a new Anti-XSRF token and save to the cookie
       _antiXsrfTokenValue = Guid.NewGuid().ToString("N");
       Page.ViewStateUserKey = _antiXsrfTokenValue;
       var responseCookie = new HttpCookie(AntiXsrfTokenKey)
       {
          HttpOnly = true,
          Value = _antiXsrfTokenValue
       };
       if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)
       {
          responseCookie.Secure = true;
       }
       Response.Cookies.Set(responseCookie);
    }
    Page.PreLoad += master_Page_PreLoad;
}

Por lo que puedo entender, el código anterior verifica si hay una cookie llamada '__AntiXsrfToken', ya presente.

Si no, se genera un nuevo valor aleatorio, que se asigna a ViewStateUserKey y también se establece como el valor de la cookie, '__AntiXsrfToken'.

Si la cookie ya está presente, el valor de la cookie simplemente se toma y se asigna a ViewStateUserKey.

Ahora, lo que no entiendo es que el punto principal de un token antiXSRF es que no debe ser detectable y, por lo tanto, no debe transmitirse en las cookies, ya que las cookies siempre serán enviadas con cada solicitud por el navegador. En el caso anterior, dado que el token AntiXsrf se está utilizando como cookies, ¿cómo lo protege? ¿Cuál es realmente el uso de ViewStateUserKey y cómo desempeña un papel en la protección contra XSRF aquí?

    
pregunta qre0ct 18.11.2014 - 07:48
fuente

2 respuestas

8

El problema es que el ejemplo de código en la guía OWASP no está completo. Específicamente, falta la implementación del método master_Page_PreLoad que se conecta en la última línea del método Page_Init .

Lo que vería si se incluyera ese método (y puedo agregarlo aquí en breve) es que el valor de ViewStateUserKey establecido por la cookie se compara con el valor de ViewState [AntiXsrfTokenKey] que se envía con el formulario Campo ViewState.

Esto es lo que proporciona la protección CSRF. Es absolutamente correcto que cuando se envíe la solicitud maliciosa, se enviará con su cookie, que tendrá su token antirrobo, y esto se establecerá en el valor ViewStateUserKey. Sin embargo, lo que no está viendo es que se está comparando con el valor del formulario que se envió. En un escenario de falsificación de solicitud entre sitios, ese valor de forma será el token anti-falsificación del atacante ; el que se agregó como el estado de visualización para que sea his ViewStateUserKey, y que no coincidirá con el valor que se encuentra en su cookie. Por lo tanto, la validación fallará y la solicitud no tendrá éxito.

Dado que no hay nada más que el código en la página OWASP actualmente, tienes razón para estar confundido.

    
respondido por el Xander 18.11.2014 - 22:57
fuente
0

Sin embargo, tenga en cuenta que, aunque se puede acceder a las cookies y las sesiones desde todas las páginas de su sitio web, los valores de ViewState no se transfieren entre las páginas, sino que contienen valores entre las devoluciones de datos:

Si su sitio web autentica a los usuarios, puede configurar la propiedad ViewStateUserKey en el controlador de eventos Page_Init para asociar el estado de vista de la página con un usuario específico. Esto ayuda a evitar ataques con un solo clic, en los que un usuario malintencionado crea una página web precargada válida con un estado de vista desde una página creada anteriormente. El atacante atrae a la víctima para que haga clic en un enlace que envía la página al servidor utilizando la identidad de la víctima.

Cuando se establece la propiedad ViewStateUserKey, la identidad del atacante se usa para crear el hash del estado de vista de la página original. Cuando la víctima es atraída para reenviar la página, los valores de hash serán diferentes porque las claves de usuario son diferentes. La página fallará la verificación y se lanzará una excepción.

Debe la propiedad ViewStateUserKey a un valor único para cada usuario, como el nombre de usuario o el identificador.

En tu código:

// Genere un nuevo token Anti-XSRF y guárdelo en la cookie

_antiXsrfTokenValue = Guid.NewGuid().ToString("N");
   Page.ViewStateUserKey = _antiXsrfTokenValue;
   var responseCookie = new HttpCookie(AntiXsrfTokenKey)
   {
      HttpOnly = true,
      Value = _antiXsrfTokenValue
   };

generará un nuevo token Anti-XSRF cada vez que se cargue la página. por lo tanto, el atacante no puede adivinar el valor. Y cada vez que cambia el valor de la cookie. Así que es muy difícil de hackear.

    
respondido por el Arunprasanth KV 18.11.2014 - 10:23
fuente

Lea otras preguntas en las etiquetas