.net - studio - ¿Hay algún problema de seguridad que deje los archivos de depuración PDB en los servidores activos?
no se puede encontrar o abrir el archivo pdb visual studio (7)
¿Hay algún problema de seguridad al mantener los archivos .NET PDB en el servidor real?
Sé que lanzar excepciones puede llevar un poco más de tiempo, pero ¿quién lanza excepciones durante la ejecución normal de todos modos? :-)
¿Pero desde una perspectiva de seguridad? ¿cualquier problema?
Básicamente, los PDB están justo debajo del código fuente cuando se trata de buscar, y ASP.NET/IIS tampoco impide que se descarguen.
Ahora seguro que la gente tendría que adivinar el nombre de la asamblea, y eso puede ser poco probable, pero ¿por qué correr el riesgo?
Creo que un argumento razonable es que no dejar los PDB en los servidores activos es un riesgo. En el caso de que la producción se bloquee y los problemas no puedan reproducirse en dev o UAT, es mucho más lento (y quizás imposible) diagnosticar dónde se está produciendo el error.
Como mínimo, los PDB que coinciden con las DLL implementadas deben estar en un archivo ZIP en el servidor de producción en algún lugar. Deben ser fácilmente ubicadas por personas que no sean usted mismo en caso de que no esté cerca para ayudar.
También vea Archivos PDB: Lo que todo desarrollador debe saber por John Robbins.
El único problema que puede encontrar al publicar archivos .PDB en su sitio web es cuando se produce una excepción, y se olvidó de establecer la propiedad CustomErrors en web.config. El seguimiento de la pila se mostrará con los nombres de los archivos y los números de línea, lo que puede ser un problema de seguridad.
No creo que haya otros riesgos.
Hmm - Me inclino por el lado de la precaución de seguridad en esto. Creo que deberías tener PDB, pero no en servidores de producción. Además, deberías tener Debug desactivado en cualquier sistema en vivo. La depuración es desagradable, y no la quieres cuando no la necesitas.
De Scott Guthrie :
- La compilación de páginas ASP.NET lleva más tiempo (ya que algunas optimizaciones de lotes están deshabilitadas)
- El código puede ejecutarse más lento (ya que algunas rutas de depuración adicionales están habilitadas)
- Se utiliza mucha más memoria dentro de la aplicación en tiempo de ejecución
- Los scripts y las imágenes descargadas del controlador WebResources.axd no se almacenan en caché
Establezca la implementación retail = true en su machine.config:
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
Esto anula la configuración de depuración, error y seguimiento, lo que evitará cualquier divulgación de errores fuera de la computadora.
Entonces, ahora que ha desactivado la depuración, no hay errores ni rastreos, ¿por qué desplegaría los PDB en el servidor de producción? Guárdalos en otro lugar, tal vez incluso tu servidor de desarrollo. El script de promoción de código de Dev a Producción puede excluir específicamente a los PDB, pero archivarlos para que estén disponibles si alguna vez necesita realizar una depuración de la producción.
Si el servidor es IIS, no. Estos archivos no se expondrán al público si se mantienen en los lugares correctos (sitio web / bin). Ocasionalmente, he encontrado archivos intermedios (directorio obj) en los servidores web: esta parece ser una forma favorita de publicitar accidentalmente binarios. Cualquier caso en el que sus pdbs sean visibles, sus archivos también son visibles, lo que es peor.
Como lo señala Active, el seguimiento de la pila es bastante útil para un hacker con o sin números de línea. Mantenlo en privado.
Supongo que cualquier otro programa que esté ejecutando en un servidor real (servicios, etc.) no es de acceso público en absoluto.
Si presenta excepciones fallidas al usuario final (también conocido como Pantalla amarilla de la muerte), puede suponer un riesgo de que el atacante obtenga una mejor visión de su sistema.
Una de las posibles soluciones: tener una política de manejo de excepciones que:
- Registra todas las excepciones con el seguimiento de pila original, información adicional y un ID de excepción único (Guid).
- Reemplaza la excepción activada con un envoltorio que contiene solo la ID de excepción (para referencia y retroalimentación) y un mensaje saneado (es decir, sin cadenas de conexión) con información de seguimiento de pila descartada.
Ejemplos de bloques de manejo de Excepciones de Código Abierto en .NET:
Si su sistema no es seguro con los PDB, probablemente no sea seguro sin ellos. Obviamente, depende de cuán valiosos sean los mejores informes de errores para usted. Personalmente, lo valoro mucho, así que tiendo a desplegar los PDB.