在生产环境中部署debugging符号（pdb文件）的风险是什么？
我有一个应用程序loggingexception痕迹，我希望这些堆栈跟踪在生产环境中包含文件名和行号。 我想出了如何部署带有程序集的debugging符号，但是在研究这个问题的过程中，我遇到了这个问题 ，这意味着在生产环境中包含pdb文件并不是一个好主意。 接受的答案评论说：“…debugging信息可以泄露敏感数据，并成为一个攻击媒介，取决于你的应用程序是什么。
那么可能会暴露什么样的敏感数据呢？ debugging符号如何被用来危害应用程序？ 我对技术细节很好奇，但是我真正想要的是评估包含任何给定应用程序和生产环境的debugging符号风险的实用方法。 或者换句话说：可能发生的最坏的事情是什么？
编辑：后续问题/澄清
所以根据目前所有人的答案，似乎这个问题可以简化一点.NET应用程序。 从迈克尔·马多克斯（Michael Maddox）的回答中 ， 约翰·罗宾斯（John Robbins）的这篇博客引起了我的注意：
.NET PDB只包含两条信息，源文件名和它们的行以及本地variables名称。 所有其他信息已经在.NET元数据中，因此不需要在PDB文件中复制相同的信息。
对我来说，这里重申了其他人对Reflector的评论，其含义是真正的问题是访问组件。 一旦确定了，关于PDB的唯一决定是你是否在意暴露文件名，行号和局部variables名（假设你没有向最终用户展示堆栈跟踪）。 还是我过分简化了这个太多了？
这是另一个需要考虑的问题：
在现场服务器上是否存在PDBdebugging文件的安全问题？
有关PDB文件的更多信息：
PDB文件：每个开发者必须知道的
总的来说，我总是在我的部署中包含pdb文件，收益太大而无法忽略。
如果您从不向用户公开堆栈跟踪（通常不应该），那么部署PDB文件没有任何额外的安全风险。
当用户可见的堆栈跟踪发生时，用户可以看到完整的堆栈跟踪，包括文件名和文件行号。 这可以让他们了解如何构build您的应用程序，这可能会帮助他们，如果黑客。
一个更大的安全威胁就像reflection器 ，当你的DLL使用时，将允许他们查看您的源代码，有或没有PDB文件。
如果你在自己的组织中部署到生产环境，那么这不是一个安全问题。
如果您将软件出售给其他实体，那么.pdb文件可以给有兴趣进行逆向工程的人一条腿 – 对您而言这可能是也可能不是问题。
然而（清楚），你不希望你的堆栈跟踪显示给客户端 – 无论.pdbs是否可用。 但是，如果您只是logging这些痕迹，并向客户端显示一个“漂亮”的错误页面，则不是问题。
通过debugging符号，攻击者可以确定感兴趣的全局variables，函数偏移量等。
所以他可以看到你的系统有这样一个function：
AddAdminUser(string name, string password); 并知道它的抵消。 如果你的程序被攻破，他可以调用这个函数给自己pipe理员权限。
或者类似的东西：
typedef enum {Basic, NTLM} AuthenticationMode; AuthenticationMode g_authenticationMode;
并知道要将应用程序切换到不安全模式需要翻转什么位。
或者，这将需要相当多的逆向工程时间来弄清楚。 然而，不是一个无法逾越的时间。
但是。 。 。 这一切都意味着你的攻击者已经处于可以妥协你的程序的位置。 如果是这样，你已经输了。
如果您有良好的业务理由来部署pdb符号，请继续。 部署PDB不会让你不安全。 如果你没有足够的理由来部署，你不应该这样做，因为它会使攻击变得更容易。
您也可以创build公共PDB文件 – 这些文件剥离某些信息，但给您足够的符号来生成堆栈跟踪并进行基本的debugging。 细节在这里 。 Microsoft将在其符号服务器上部署公共PDB以供所有人使用。
编辑：我所说的大部分适用于部署PDB的原生代码的担忧 – 我认为很多这些问题也转移到.NET，即使汇编元数据已经传达了相当一部分。
有人可以“恢复”你的应用程序的完整源代码。 如果是开放源代码，则不必担心。 如果它有一些IP（algorithm，保护，许可证），这可能不是一个好主意。
诚然，像Reflector这样的工具可以在不使用PDB文件的情况下重新构build代码的一部分，但是混淆可以帮助（稍微有点儿）。
