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

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

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

与部署的DLL匹配的PDB 应该位于生产服务器某处的ZIP文件中。他们应该很容易被别人而不是你自己找到,以防你不在身边帮忙。

也看到 PDB Files: What Every Developer Must Know 约翰·罗宾斯著。

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

我认为没有其他风险。

如果服务器是IIS,则为否。如果这些文件保存在正确的位置(website\bin),则不会向公众公开。偶尔我会在web服务器上发现中间(obj目录)文件——这似乎是无意中公开二进制文件的一种常用方式。任何PDB可见的情况下,DLL也可见,这更糟糕。

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

我假设您在真正的服务器上运行的任何其他程序——服务,等等——都是完全不可公开访问的。

其中一个可能的解决方案是 异常处理策略 即:

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

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

• From Lokad

• From Microsoft

• Theory

现在,人们肯定要猜程序集名称,这可能不太可能,但为什么要冒险呢?

从…起 Scott Guthrie :

1. ASP.NET页面的编译需要更长的时间(因为禁用了某些批处理优化)
2. 代码执行速度可能较慢(因为启用了一些其他调试路径)
4. 不会缓存从WebResources.axd处理程序下载的脚本和图像

在machine.config中设置deployment retail=true:

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

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

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