Acabo de leer en la red sobre una vulnerabilidad de seguridad recientemente descubierta en ASP.NET.Puede leer los detalles aquí.

El problema radica en la forma en que ASP.NET implementa el algoritmo de cifrado AES para proteger la integridad de las cookies que generan estas aplicaciones para almacenar información durante las sesiones de los usuarios.

Esto es un poco vago, pero aquí hay una parte más aterradora:

La primera etapa del ataque requiere unos pocos miles de solicitudes, pero una vez que tiene éxito y el atacante obtiene las claves secretas, es totalmente sigiloso. El conocimiento criptográfico requerido es muy básico.

En general, no estoy lo suficientemente familiarizado con el tema de seguridad / criptografía para saber si esto es realmente tan grave.

Entonces, ¿deberían todos los desarrolladores de ASP.NET temer esta técnica quepuede poseer cualquier sitio web ASP.NET en segundos ¿o que?

¿Cómo afecta este problema al desarrollador ASP.NET promedio? ¿Nos afecta en absoluto? En la vida real, ¿cuáles son las consecuencias de esta vulnerabilidad? Y, finalmente: ¿hay alguna solución que evite esta vulnerabilidad?

¡Gracias por tus respuestas!

EDITAR: Déjame resumir las respuestas que recibí

Entonces, esto es básicamente un tipo de ataque de "oráculo de relleno".@Sri proporcionó una gran explicación sobre qué significa este tipo de ataque.¡Aquí hay un video impactante sobre el tema!

Sobre la gravedad de esta vulnerabilidad: Sí, de hecho es grave.Permite al atacante conocer la clave de máquina de una aplicación. Por lo tanto, él puede hacer algomuy cosas no deseadas

En posesión de la clave de máquina de la aplicación, el atacante puede descifrar las cookies de autenticación.Incluso peor que eso, él puedegenerar cookies de autenticación con el nombre de cualquier usuario. Por lo tanto, puede aparecer como cualquiera en el sitio. La aplicación no puede diferenciar entre usted o el hacker que generó una cookie de autenticación con su nombre.También le permite descifrar (y también generar)cookies de sesión, aunque esto no es tan peligroso como el anterior.No es tan grave: puede descifrar el ViewState cifrado de páginas. (Si usa ViewState para almacenar datos confidenciales, ¡no debe hacer esto de todos modos!)Bastante inesperado: Con el conocimiento de la clave de la máquina, el atacantepuede descargar cualquier archivo arbitrario de su aplicación web, ¡incluso aquellos que normalmente no se pueden descargar! (InclusoWeb.Config, etc.)

Aquí hay un montón de buenas prácticas que obtuveno lo hagas resuelva el problema pero ayude a mejorar la seguridad general de una aplicación web.

Puede cifrar datos confidenciales con la configuración protegidaUsar cookies solo de HTTPPrevenir ataques DoS

Ahora, centrémonos en este tema.

Scott Guthrie publicó una entrada al respecto en su blogPublicación de blog de preguntas frecuentes de ScottGu sobre la vulnerabilidadLa actualización de ScottGu sobre la vulnerabilidadMicrosoft tiene un aviso de seguridad al respectoComprender la vulnerabilidadInformación adicional sobre la vulnerabilidad.

La solución

Habilite customErrors y cree una sola página de error en la quetodos los errores son redirigidos Si,incluso 404s. (ScottGu dijo que diferenciar entre 404 y 500 es esencial para este ataque). También, en suApplication_Error oError.aspx pon un código que haga un retraso aleatorio. (Genere un número aleatorio y use Thread.Sleep para dormir durante tanto tiempo). Esto hará imposible que el atacante decida qué sucedió exactamente en su servidor.Algunas personas recomendaron volver a 3DES. En teoría, si no usa AES, no encontrará la debilidad de seguridad en la implementación de AES. Resulta que esto esno recomendado en absoluto.

Algunos otros pensamientos

Parece queno todos piensa que la solución es lo suficientemente buena.

Gracias a todos los que respondieron mi pregunta. Aprendí mucho no solo sobre este problema, sino también sobre la seguridad web en general. Marqué la respuesta de @ Mikael como aceptada, pero las otras respuestas también son muy útiles.