Sé que los sitios de Stack Exchange no usan ASP.NET MVC incorporado @Html.AntiForgeryToken() para la prevención de ataques XSRF/CSRF. En lugar de crear una entrada oculta llamada __RequestVerificationToken con un valor realmente muy largo basado en la sección machineKey de web.config, el método Stack Exchange crea una entrada denominada fkey con MUCHO valor más sucinto. Esto es aparentemente un Guid, y en base a la evidencia del Stack Exchange Data Explorer project on Google Code, este valor está ligado a cada usuario individual, permaneciendo bastante constante hasta que ingresa o sale.¿Alguna razón para no confiar en ASP.NET AntiForgeryToken?
Además, el valor de Intercambio de pila es constante en una página y está disponible para la secuencia de comandos del cliente, de modo que las publicaciones de Ajax para la votación y cosas por el estilo también usan la ficha. Por contraste
Entonces, ¿por qué Stack Exchange marcha a su propio baterista?
- ¿Hay alguna razón para no confiar en AntiForgeryToken?
- ¿El AntiForgeryToken tiene algunas limitaciones que el equipo de Stack Exchange no estaba dispuesto a aceptar? ¿Si es así, qué son ellos?
- O tal vez AntiForgeryToken simplemente no existía (comenzó su vida en el proyecto MVC Futures) cuando se inició el desbordamiento de pila, y si tuvieran que volver a empezar desde cero, usarían AntiForgeryToken?
No he podido encontrar ninguna publicación de blog de Jeff u otros en el equipo de Stack Exchange para explicar los principios rectores de la política de prevención de XSRF en la red SE. Sería muy bueno si uno de ellos pudiera escribir un artículo, suponiendo, por supuesto, que podría hacerse en términos generales sin crear una vulnerabilidad. Sería una información realmente valiosa para aquellos de nosotros que queremos que nuestros sitios web sean seguros, pero no nos sentimos del todo cómodos confiando ciegamente en que Microsoft lo haga por nosotros.
opción 3: no existía cuando estábamos construyendo SO en 2008-2009. No puedo comentar sobre los pros y los contras del método integrado, porque nunca lo he usado. –
Otra consideración es que cualquier mecanismo de seguridad que colocamos en MVC o ASP.NET tiene que ser de propósito general. Podemos alcanzar el 95% de los casos, pero siempre habrá un grupo de clientes que tengan requisitos extraordinarios que un mecanismo integrado de propósito general nunca podría satisfacer. Por ejemplo, la implementación anti-XSRF existente no es amigable para sitios que hacen un uso intensivo de JSON o identidades basadas en reclamos, y en esos casos el desarrollador termina rodando su propia solución la mayor parte del tiempo. – Levi