在生产环境中部署debugging符号(pdb文件)的风险是什么?

我有一个应用程序loggingexception痕迹,我希望这些堆栈跟踪在生产环境中包含文件名和行号。 我想出了如何部署带有程序集的debugging符号,但是在研究这个问题的过程中,我遇到了这个问题 ,这意味着在生产环境中包含pdb文件并不是一个好主意。 接受的答案评论说:“…debugging信息可以泄露敏感数据,并成为一个攻击媒介,取决于你的应用程序是什么。

那么可能会暴露什么样的敏感数据呢? debugging符号如何被用来危害应用程序? 我对技术细节很好奇,但是我真正想要的是评估包含任何给定应用程序和生产环境的debugging符号风险的实用方法。 或者换句话说:可能发生的最坏的事情是什么?

编辑:后续问题/澄清

所以根据目前所有人的答案,似乎这个问题可以简化一点.NET应用程序。 从迈克尔·马多克斯(Michael Maddox)的回答中 , 约翰·罗宾斯(John Robbins)的这篇博客引起了我的注意:

.NET PDB只包含两条​​信息,源文件名和它们的行以及本地variables名称。 所有其他信息已经在.NET元数据中,因此不需要在PDB文件中复制相同的信息。

对我来说,这里重申了其他人对Reflector的评论,其含义是真正的问题是访问组件。 一旦确定了,关于PDB的唯一决定是你是否在意暴露文件名,行号和局部variables名(假设你没有向最终用户展示堆栈跟踪)。 还是我过分简化了这个太多了?

这是另一个需要考虑的问题:

在现场服务器上是否存在PDBdebugging文件的安全问题?

有关PDB文件的更多信息:

PDB文件:每个开发者必须知道的

总的来说,我总是在我的部署中包含pdb文件,收益太大而无法忽略。

如果您从不向用户公开堆栈跟踪(通常不应该),那么部署PDB文件没有任何额外的安全风险。

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

一个更大的安全威胁就像reflection器 ,当你的DLL使用时,将允许他们查看您的源代码,有或没有PDB文件。

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

如果您将软件出售给其他实体,那么.pdb文件可以给有兴趣进行逆向工程的人一条腿 – 对您而言这可能是也可能不是问题。

然而(清楚),你不希望你的堆栈跟踪显示给客户端 – 无论.pdbs是否可用。 但是,如果您只是logging这些痕迹,并向客户端显示一个“漂亮”的错误页面,则不是问题。

通过debugging符号,攻击者可以确定感兴趣的全局variables,函数偏移量等。

所以他可以看到你的系统有这样一个function:

AddAdminUser(string name, string password); 

并知道它的抵消。 如果你的程序被攻破,他可以调用这个函数给自己pipe理员权限。

或者类似的东西:

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

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

或者,这将需要相当多的逆向工程时间来弄清楚。 然而,不是一个无法逾越的时间。

但是。 。 。 这一切都意味着你的攻击者已经处于可以妥协你的程序的位置。 如果是这样,你已经输了。

如果您有良好的业务理由来部署pdb符号,请继续。 部署PDB不会让你不安全。 如果你没有足够的理由来部署,你不应该这样做,因为它会使攻击变得更容易。

您也可以创build公共PDB文件 – 这些文件剥离某些信息,但给您足够的符号来生成堆栈跟踪并进行基本的debugging。 细节在这里 。 Microsoft将在其符号服务器上部署公共PDB以供所有人使用。

编辑:我所说的大部分适用于部署PDB的原生代码的担忧 – 我认为很多这些问题也转移到.NET,即使汇编元数据已经传达了相当一部分。

有人可以“恢复”你的应用程序的完整源代码。 如果是开放源代码,则不必担心。 如果它有一些IP(algorithm,保护,许可证),这可能不是一个好主意。

诚然,像Reflector这样的工具可以在不使用PDB文件的情况下重新构build代码的一部分,但是混淆可以帮助(稍微有点儿)。