.net - ucrtbased - simbolos visual studio
¿Cuál es el riesgo de desplegar símbolos de depuración(archivo pdb) en un entorno de producción? (4)
Al tener símbolos de depuración, un atacante puede determinar variables globales, compensaciones de funciones, etc., de interés.
Entonces pudo ver que su sistema tiene una función como:
AddAdminUser(string name, string password);
Y sepa su compensación. Si su programa está en peligro, podría llamar a esta función para otorgarse privilegios de administrador.
O algo así como:
typedef enum {Basic, NTLM} AuthenticationMode;
AuthenticationMode g_authenticationMode;
Y sabe qué bits cambiar para cambiar su aplicación a un modo inseguro.
Alternativamente, esto tomaría bastante tiempo de ingeniería inversa para averiguarlo. Sin embargo, no es una cantidad de tiempo insuperable.
Pero . . . todo esto implica que su atacante ya está en una posición en la que puede poner en peligro su programa. Si ese es el caso, ya has perdido.
Si tiene un buen motivo comercial para desplegar símbolos pdb, continúe. La implementación de PDB no te hará inseguro. Si no tiene una buena razón para implementar, no debe hacer esto, ya que facilitará los ataques.
También puede crear archivos PDB públicos; estos despojan a ciertos elementos de información, pero le dan suficientes símbolos para generar un seguimiento de pila y realizar una depuración básica. Los detalles estan here Microsoft implementa los PDB públicos en su servidor de símbolos para que todos los utilicen.
EDITAR: La mayoría de lo que dije se aplica a las preocupaciones sobre la implementación de PDB para código nativo. Creo que muchas de estas preocupaciones también se trasladan a .NET, aunque los metadatos de ensamblado ya transmiten bastante de esto.
Tengo una aplicación que registra rastreos de excepción y quería que esos rastreos de pila incluyeran nombres de archivos y números de línea cuando se implementan en producción. Descubrí cómo implementar los símbolos de depuración con el ensamblado, pero en el proceso de investigar el problema me encontré con esta pregunta , lo que implica que no es una buena idea incluir archivos pdb en un entorno de producción. Un comentario de la respuesta aceptada dice "... la información de depuración puede revelar datos confidenciales y ser un vector de ataque. Dependiendo de la aplicación".
Entonces, ¿qué tipo de información confidencial podría estar expuesta? ¿Cómo se pueden usar los símbolos de depuración para comprometer una aplicación? Tengo curiosidad sobre los detalles técnicos, pero lo que realmente estoy buscando es una forma práctica de evaluar el riesgo de incluir símbolos de depuración para cualquier aplicación y entorno de producción determinados. O para decirlo de otra manera: ¿qué es lo peor que podría pasar?
EDITAR: pregunta de seguimiento / aclaración
Entonces, según las respuestas de todos hasta ahora, parece que esta pregunta se puede simplificar un poco para las aplicaciones .NET. Este fragmento del blog de John Robbins vinculado en la respuesta de Michael Maddox me saltó:
Un .NET PDB solo contiene dos elementos de información, los nombres de los archivos de origen y sus líneas y los nombres de las variables locales. Toda la otra información ya está en los metadatos .NET por lo que no es necesario duplicar la misma información en un archivo PDB.
Para mí, esto reitera lo que otros han estado diciendo sobre Reflector, con la implicación de que el verdadero problema es el acceso a las asambleas. Una vez que esto ha sido determinado, la única decisión a tomar con respecto a los PDB es si le interesa exponer nombres de archivos, números de líneas y nombres de variables locales (suponiendo que no muestre rastros de pila a los usuarios finales). ¿O lo simplifiqué demasiado?
Alguien puede "restaurar" el código fuente completo de su aplicación. Si es de código abierto, no necesita preocuparse. Si tiene algo de IP (algoritmos, protección, licencias), probablemente no sea una buena idea.
Es cierto que herramientas como Reflector pueden reconstruir partes de tu código incluso sin archivos PDB, pero las ofuscaciones pueden ayudar (bueno, solo un poco).
Aquí hay otra pregunta para mirar:
¿Hay problemas de seguridad dejando los archivos de depuración PDB en los servidores en vivo?
Y más información sobre archivos PDB:
Archivos PDB: lo que todo desarrollador debe saber
En general, siempre incluyo archivos pdb en mis implementaciones, las ganancias son demasiado grandes como para ignorarlas.
Si nunca expone un rastro de pila a sus usuarios (y generalmente no debería), no hay ningún riesgo de seguridad adicional de desplegar archivos PDB.
Cuando ocurre un seguimiento de la pila visible del usuario, el usuario puede ver el trazado completo de la pila, incluido el nombre del archivo y los números de línea del archivo. Esto podría darles una idea de cómo está diseñada su aplicación, lo que podría ayudarlos si piratea.
Una amenaza de seguridad más grande es algo así como Reflector que cuando se usa en sus archivos DLL les permitirá ver su código fuente, con o sin archivos pdb.
Si se está implementando en un entorno de producción en su propia organización, entonces no es un problema de seguridad.
Si está vendiendo su software a otras entidades, entonces el archivo .pdb puede darle una ventaja a alguien interesado en ingeniería inversa, que puede o no ser un problema para usted.
Sin embargo (para ser claros), no quiere que sus rastros de pila se muestren al cliente, ya sea que los .pdbs estén disponibles o no. Pero si solo está registrando las huellas y presentando una página de error "bonita" al cliente, no es un problema.