asp.net security iis-7.5 crash-dumps

¿Cómo se evita que las contraseñas y otra información confidencial aparezcan en un volcado de ASP.NET?



security iis-7.5 (2)

¿Cómo se puede evitar que las contraseñas y otros datos confidenciales enviados y recibidos de las páginas web de ASP.NET en los archivos de volcado de IIS / ASP.NET?

pasos para reproducir

  1. Con Visual Studio 2010, cree una aplicación de intranet MVC 3 de ASP.NET.
  2. Configúralo para usar IIS 7.5.
  3. Enciéndalo y registre una cuenta (digamos bob123 como usuario y Pa $$ w0Rd como contraseña. Supongo que se crea la base de datos SQL Express y que el sitio es completamente funcional.
  4. Usando el administrador de tareas, haga clic derecho en el proceso w3wp y cree un volcado.
  5. Abra el volcado en un editor capaz de mostrar su contenido como hexadecimal, como SlickEdit.
  6. Busque "Pa $$ 0Rd" y "Pa% 24% 24w0Rd" en el volcado hexadecimal. Debería poder encontrar varias copias almacenadas como ASCII, Unicode o codificadas.

Tenga en cuenta que no importa si utiliza HTTPS porque solo cifra la comunicación. ASP.NET almacena esos datos en claro en la memoria o en el disco.

El problema

La sabiduría común tiene que cifrar los datos confidenciales y no almacenarlos a la vista. Sin embargo, un empleado puede recibir un volcado de una aplicación IIS / ASP.NET y descubrir contraseñas y otros datos confidenciales de los usuarios porque esta información no está encriptada, ni la memoria utilizada por ASP.NET se borra después del uso.

Esto los pone en riesgo simplemente porque tienen acceso a ellos. El volcado a veces se comparte con socios (como Microsoft) para ayudarles a diagnosticar problemas en su código. Es una parte necesaria para diagnosticar algunos problemas realmente complejos en la aplicación.

Cosas que miré

  1. Utilice SecureString para contraseñas y otros datos confidenciales. Sin embargo, el proveedor de membresía de ASP.NET, junto con otros marcos como WCF, a menudo acepta contraseñas como System.String, lo que significa que esas copias todavía estarán en el volcado.
  2. Miré para ver si hay algo en el marco para borrar una copia de System.String cuando ya no se está utilizando. No pude encontrar nada.
  3. Se investigó si se puede poner a cero la memoria utilizada para las solicitudes y respuestas una vez que IIS haya terminado, pero no pude encontrar nada.
  4. Investigué si uno puede cifrar archivos que recibe IIS (como HttpPostFile) para que no se almacenen de forma clara. Podemos recibir documentos que son extremadamente confidenciales y se realizan todos los pasos para cifrarlos y protegerlos en el servidor. Sin embargo, alguien puede extraerlos de forma clara de un volcado de IIS.

Lo que esperaba era decirle a IIS / ASP.NET que una solicitud / respuesta específica contiene datos confidenciales y que IIS / ASP.NET borrará la memoria cuando haya terminado de usarla.

Por definición, un archivo de volcado vuelca toda la memoria que usa la aplicación en el momento en que se volcó. Si tuviera que crear un filtro para que se excluyeran ciertas cosas, nunca podría estar seguro de que tenía suficientes datos para solucionar un problema.

¿Se sentiría cómodo entregando sus bases de datos / ajustes de configuración a un tercero? Si no, entonces probablemente tampoco deberías entregar archivos de volcado. (En mi humilde opinión)

Sé que esto no responde directamente a la pregunta, pero ¿por qué no analizar este problema de manera diferente?

Fácilmente podría juntar algunos javascript para hacer el lado del hash del cliente. Combinaría la contraseña con algo aleatorio, como un guid que envía el servidor y es válido solo para un solo uso. El intercambio de datos ya no contendría la contraseña y el hash podría compararse fácilmente con el servidor. Solo sería válido para la sesión, por lo que alguien que mire los datos del volcado no podría usar el hash para "autenticarse" en el futuro.

En el lado del archivo, ¿cómo se están cargando estos archivos? directamente desde una página web? Hay bastantes bibliotecas de javascript que hacen cifrado (blowfish) y definitivamente usaría esta opción al enviar un archivo confidencial. Tiene una penalización de velocidad, pero puede estar seguro de que los datos están seguros.