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

Question

将 .NET PDB 文件保留在真实服务器上是否存在任何安全问题？

我知道抛出异常可能需要更长的时间，但是谁会在正常执行期间抛出异常呢？ :-)

但是从安全角度来看呢？ 有什么问题吗？

Answer 1

基本上，当涉及到查看时，PDB 就位于源代码下方，并且 ASP.NET/IIS 也不会阻止它们被下载。

现在人们肯定必须猜测程序集名称，这可能不太可能，但为什么要冒这个风险呢？

Answer 2

嗯 - 对此我倾向于安全警告。 我认为你应该有 PDB，但不要在生产服务器上。 此外，您应该在任何实时系统上关闭“调试”。 调试是令人讨厌的，当你不需要它时你就不会想要它。

来自 Scott Guthrie：

1. ASP.NET 的编译页面需要更长的时间（因为禁用了一些批量优化）
2. 代码执行速度可能会更慢（因为启用了一些额外的调试路径）
3. 运行时应用程序中使用了更多的内存
4. 从 WebResources.axd 处理程序下载的脚本和图像不会被缓存

设置部署零售machine.config 中的 =true：

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

这会覆盖调试、错误和跟踪设置，这将防止计算机本身之外的任何错误泄露。

既然您已关闭调试，没有错误或跟踪，为什么还要将 PDB 部署到生产服务器呢？ 将它们存储在其他地方，甚至可能是您的开发服务器。 从开发到生产的代码升级脚本可以专门排除 PDB，但将它们存档，以便在您需要对生产进行调试时可用。

Answer 3

将 .PDB 文件发布到网站时，您可能遇到的唯一问题是发生异常，并且您忘记在 web.config 中设置 CustomErrors 属性。 堆栈跟踪将显示文件名和行号，这可能是一个安全问题。

我认为没有其他风险。

Answer 4

我认为一个公平的论点是，不将 PDB 留在实时服务器上也是一种风险。 在生产崩溃并且问题无法在开发或 UAT 上重现的情况下，诊断错误发生的位置会更加耗时（并且可能不可能）。

至少，与部署的 DLL 匹配的 PDB 应该位于生产服务器上某处的 ZIP 文件中。 如果您不在身边提供帮助，除您之外的其他人应该可以轻松找到它们。

另请参阅 PDB 文件：每个开发人员必须了解的内容< /a> 约翰·罗宾斯。

Answer 5

如果您的系统在使用 PDB 时不安全，那么如果没有它们，系统也可能不安全。 显然，这取决于更好的错误报告对您的价值有多大。 就我个人而言，我非常看重这一点，因此倾向于部署 PDB。

Answer 6

如果服务器是 IIS，则不会。 如果将这些文件保存在正确的位置（网站\bin），则不会向公众公开。 有时我会在 Web 服务器上找到中间（obj 目录）文件 - 这似乎是意外公开二进制文件的最喜欢的方式。 在任何情况下，如果你的 pdb 可见，你的 dll 也可见，这更糟糕。

正如 activa 所指出的，堆栈跟踪对于有或没有行号的黑客来说非常有用。 保密。

我假设您可能在真实服务器上运行的任何其他程序（服务等）根本无法公开访问。

Answer 7

如果您向最终用户呈现失败的异常（也称为黄屏死机），则可能会带来攻击者更好地了解您的系统的风险。

可能的解决方案之一 - 制定异常处理策略：

1. 使用原始堆栈跟踪、附加信息和唯一的异常 ID (Guid) 记录所有异常。
2. 将引发的异常替换为仅包含异常 ID（用于参考和反馈）和带有丢弃的堆栈跟踪信息的清理消息（即：无连接字符串）的包装器。

.NET 中的开源异常处理块示例：

• 来自 Lokad

• 来自 Microsoft

• 理论