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

Question

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

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

编辑：后续问题/澄清

因此，根据到目前为止每个人的回答，对于.NET应用程序来说，这个问题似乎可以稍微简化一下。这一点来自 John Robbins 博客链接在 迈克尔·马多克斯的回答让我大吃一惊：

.NET PDB 仅包含两部分 信息、源文件名和 他们的行和局部变量 名称。所有其他信息是 已经在 .NET 元数据中了 不需要重复相同的 PDB 文件中的信息。

对我来说，这重申了其他人对 Reflector 的看法，这意味着真正的问题是对程序集的访问。一旦确定了这一点，关于 PDB 的唯一决定就是您是否关心公开文件名、行号和局部变量名称（假设您一开始就不向最终用户显示堆栈跟踪）。或者我是否过于简单化了？

Answer 1

这是另一个需要注意的问题：

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

有关 PDB 文件的更多信息：

PDB 文件：每个开发人员必须了解的内容

一般来说，我总是在部署中包含 pdb 文件，收益太大，不容忽视。

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

当用户可见的堆栈跟踪发生时，用户可以看到完整的堆栈跟踪，包括文件名和文件行号。这可以让他们了解您的应用程序的架构，这可能会在黑客攻击时帮助他们。

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

Answer 2

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

如果您将软件出售给其他实体，那么 .pdb 文件可以为对逆向工程感兴趣的人提供帮助 - 这对您来说可能是问题，也可能不是问题。

但是（需要明确的是），您不希望向客户端显示堆栈跟踪 - 无论 .pdbs 是否可用。但如果您只是记录跟踪并向客户端呈现一个“漂亮”的错误页面，那么这不是问题。

Answer 3

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

所以他可以看到你的系统有一个类似的功能：

AddAdminUser(string name, string password);

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

或者类似的东西：

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

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

或者，这将需要相当多的逆向工程时间才能弄清楚。然而，这并不是不可克服的时间。

但 。 。 。这一切都意味着您的攻击者已经能够危害您的程序。如果是这样的话，你就已经输了。

如果您有充分的商业理由来部署 pdb 符号，请继续。部署 PDB 不会让您变得不安全。如果您没有充分的理由进行部署，则不应这样做，因为这会使攻击变得稍微容易一些。

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

编辑：我所说的大部分内容都适用于围绕为本机代码部署 PDB 的担忧 - 我认为人们也将很多这些担忧转移到 .NET，尽管程序集元数据已经传达了相当多的内容。

Answer 4

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

确实，即使没有 PDB 文件，像 Reflector 这样的工具也可以重建部分代码，但混淆可以有所帮助（好吧，只是一点点）。