在生产环境中部署调试符号（pdb文件）有什么风险？

我有一个记录异常跟踪记录的应用程序，我希望这些堆栈跟踪在生产环境中部署时包括文件名和行号。我想出了如何通过程序集部署调试符号，但是在研究这个问题的过程中，我遇到了这个问题，这意味着在生产环境中包括pdb文件不是一个好主意。对已接受答案的评论说：“ ...调试信息可以泄露敏感数据并成为攻击媒介。这取决于您的应用程序是什么。”

那么什么样的敏感数据可能会被暴露呢？调试符号如何用于危害应用程序？我对技术细节感到很好奇，但是我真正想要的是一种评估任何给定应用程序和生产环境中包括调试符号的风险的实用方法。或换一种说法：可能发生的最坏情况是什么？

编辑：后续问题/澄清

因此，根据到目前为止的每个人的答案，.NET应用程序似乎可以简化此问题。约翰·罗宾斯（John Robbins）博客中的这一点链接到迈克尔·马多克斯（Michael Maddox）的答案中，使我大跌眼镜：

.NET PDB仅包含两条信息，即源文件名及其行以及本地变量名。所有其他信息已经在.NET元数据中，因此无需在PDB文件中重复相同的信息。

对我来说，这重申了其他人对Reflector的看法，这意味着真正的问题是对程序集的访问。一旦确定了这一点，关于PDB的唯一决定就是您是否关心公开文件名，行号和本地变量名（假设您最初并未向最终用户显示堆栈跟踪）。还是我简化得太多了？

这是另一个要考虑的问题：

将PDB调试文件留在实时服务器上是否存在任何安全问题？

有关PDB文件的更多信息：

PDB文件：每个开发人员都必须知道

通常，我总是在部署中包含pdb文件，这样做的好处太大了，不容忽视。

如果您从不向用户公开堆栈跟踪信息（通常不应该这样做），那么部署PDB文件实际上就不会存在任何其他安全风险。

当发生用户可见的堆栈跟踪时，用户可以看到完整的堆栈跟踪，包括您的文件名和文件行号。这可以使他们对您的应用程序的架构有一些了解，如果遭到黑客入侵，这可能会对他们有帮助。

更大的安全威胁是像Reflector这样的东西，当在您的DLL上使用Reflector时，它们将允许它们查看带有或不带有pdb文件的源代码。

如果要在自己的组织中部署到生产环境，那么这不是安全问题。

如果您要将软件出售给其他实体，则.pdb文件可以使对逆向工程感兴趣的人受益匪浅-对您而言可能是问题，也可能不是问题。

但是（要清楚），您不希望将堆栈跟踪显示给客户端-.pdb是否可用。但是，如果您只是记录跟踪信息并向客户端显示一个“漂亮的”错误页面，那不是问题。

通过使用调试符号，攻击者可以确定感兴趣的全局变量，函数偏移量等。

这样他就可以看到您的系统具有以下功能：

AddAdminUser(string name, string password);

并知道其偏移量。如果您的程序受到威胁，他可以调用此函数来给自己管理员特权。

或类似的东西：

typedef enum {Basic, NTLM} AuthenticationMode;
AuthenticationMode g_authenticationMode;

并且知道要翻转什么才能将应用程序切换到不安全模式。

另外，要弄清楚这需要花费大量的逆向工程时间。但是，这不是一个无法克服的时间。

但是。。。这一切都意味着您的攻击者已经可以攻击您的程序。如果是这样，您已经迷路了。

如果出于商业原因需要部署pdb符号，请继续。部署PDB不会使您感到不安全。如果您没有充分的理由进行部署，则不应该这样做，因为这样做会使攻击稍微容易一些。

您还可以创建公共PDB文件-这些文件会带走某些信息，但会为您提供足够的符号以生成堆栈跟踪并进行基本调试。详细信息在这里。Microsoft将公共PDB部署在其符号服务器上，以供所有人使用。

编辑：我所说的大部分内容都适用于为本机代码部署PDB的问题-尽管组装元数据已经传达了很多这样的问题，但我认为很多这些问题也会留给.NET。

有人可以“恢复”应用程序的完整源代码。如果它是开源的，则无需担心。如果它具有某些IP（算法，保护，许可证），则可能不是一个好主意。

的确，诸如Reflector之类的工具即使没有PDB文件也可以重建部分代码，但是混淆可以提供帮助（嗯，只是一点点）。