Dos soluciones para CSRF en OWASP para ASP.NET WebForms

Estoy confundido acerca de las diferencias entre esas dos soluciones de OWASP ASP.NET Web Froms Guidance

Solución uno:

  

Si bien viewstate no siempre es apropiado para el desarrollo web, usarlo   Puede proporcionar mitigación CSRF. Para hacer que ViewState proteja contra   Los ataques CSRF que necesita para configurar ViewStateUserKey:

protected override OnInit(EventArgs e) {
    base.OnInit(e); 
    ViewStateUserKey = Session.SessionID;
} 

Solución dos:

  

Si no usa Viewstate, busque la página maestra predeterminada de   La plantilla predeterminada de formularios web de ASP.NET para un token manual anti-CSRF   utilizando una cookie de doble envío.

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;
}

protected void master_Page_PreLoad(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
       // Set Anti-XSRF token
       ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey;
       ViewState[AntiXsrfUserNameKey] = Context.User.Identity.Name ?? String.Empty;
    }
    else
    {
       // Validate the Anti-XSRF token
       if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue || 
          (string)ViewState[AntiXsrfUserNameKey] != (Context.User.Identity.Name ?? String.Empty))
       {
          throw new InvalidOperationException("Validation of Anti-XSRF token failed.");
       }
    }
}

Lo que no recibí es este comentario sobre el primer enfoque: "Para que ViewState se proteja contra los ataques CSRF, debe configurar ViewStateUserKey". Mirando el código para la segunda solución, claramente usando ViewSate en el código, asumo que el autor significa que "usar ViewState para mantener el estado de control". Entonces, si EnableViewState está configurado como falso para la página o la página maestra, ¿el primer enfoque no funcionará en absoluto?

Actualización: Un mejor comentario sobre el segundo enfoque en OWASP Anti CSRF Tokens ASP.NET

  

Desde Visual Studio 2012, el mecanismo anti-CSRF se ha mejorado.

     

La nueva estrategia sigue utilizando ViewState como la entidad principal para CSRF   protección, pero también hace uso de tokens (que puede generar como   GUIDs) para que pueda establecer ViewStateUserKey en el token en lugar de   que el ID de sesión, y luego validarlo contra la cookie.