26

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

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

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

4

7 回答 7

21

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

于 2009-06-01T07:54:19.160 回答
10

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

至少，与部署的 DLL 匹配的 PDB应该位于生产服务器上某处的 ZIP 文件中。他们应该很容易被您以外的人找到，以防您不在身边提供帮助。

另请参阅PDB 文件： John Robbins 的每个开发人员必须知道的内容。

于 2009-07-11T10:30:30.590 回答
7

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

我认为没有其他风险。

于 2009-06-01T07:56:36.737 回答
3

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

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

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

于 2009-06-01T08:09:43.233 回答
2

如果您向最终用户显示失败的异常（又名黄屏死机），那么它可能会给攻击者带来更好地了解您的系统的风险。

一种可能的解决方案 - 有一个异常处理策略：

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

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

于 2009-06-01T08:05:19.980 回答
-4

基本上，PDB 就在源代码之下，而 ASP.NET/IIS 也不会阻止它们被下载。

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

于 2009-06-01T07:50:10.650 回答
-5

嗯 - 我会在这方面倾向于安全谨慎。我认为你应该有 PDB，但不是在生产服务器上。此外，您应该在任何实时系统上关闭调试。调试是讨厌的，当你不需要它的时候你就是不想要它。

来自斯科特·格思里：

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

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

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

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

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

于 2009-06-01T15:39:58.247 回答