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

What's the risk of deploying debug symbols (pdb file) in a production environment?

提问by Matt

I have an application that logs exception strack traces and I wanted those stack traces to include file names and line numbers when deployed in production. I figured out how to deploy the debug symbols w/ the assembly, but in the process of researching the issue I ran accross this question, which implies that it's not a good idea to include pdb files in a production environment. A comment to the accepted answer says "...debugging information can give away sensitive data and be an attack vector. Depending on what your app is."

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

So what sort of sensitive data might be exposed? How can debug symbols be used to compromise an application? I'm curious about the technical details, but what I'm really looking for is a practical way to evaluate the risk of including debug symbols for any given application and production environment. Or to put it another way: what's the worst that could happen?

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

EDIT:follow-up question/clarification

编辑：后续问题/澄清

So based on everyone's answers so far, it seems like this question can be simplified a bit for .NET applications. This bit from the John Robbins bloglinked in Michael Maddox's answerkind of leaped out at me:

因此，根据到目前为止每个人的答案，对于 .NET 应用程序，这个问题似乎可以简化一些。迈克尔·马多克斯 (Michael Maddox) 的回答中链接的约翰·罗宾斯 (John Robbins) 博客中的这一点让我大吃一惊：

A .NET PDB only contains two pieces of information, the source file names and their lines and the local variable names. All the other information is already in the .NET metadata so there is no need to duplicate the same information in a PDB file.

.NET PDB 只包含两条​​信息，源文件名及其行以及局部变量名。所有其他信息都已在 .NET 元数据中，因此无需在 PDB 文件中复制相同的信息。

To me, this reiterates what others have been saying about Reflector, with the implication being that the real issue is access to the assemblies. Once that's been determined, the only decision to make with respect to PDBs is whether or not you care about exposing file names, line numbers, and local variable names (assuming that you're not showing stack traces to end users to begin with). Or have I oversimplified this too much?

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

采纳答案by Michael Maddox

Here is another question to look at:

这是另一个需要查看的问题：

Are there any security issues leaving the PDB debug files on the live servers?

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

And more info on PDB files:

以及有关 PDB 文件的更多信息：

PDB Files: What Every Developer Must Know

PDB 文件：每个开发人员必须知道的

In general, I always include pdb files in my deployments, the gains are too huge to ignore.

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

If you never expose a stack trace to your users (and generally you shouldn't), there isn't really any additional security risk of deploying PDB files.

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

When a user visible stack trace happens, the user can see the full stack trace including your file name and file line numbers. This could give them some idea of how your app is architected which would potentially help them if hacking.

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

A bigger security threat is something like Reflectorwhich when used on your DLLs will allow them to view your source code, with or without pdb files.

一个更大的安全威胁是像Reflector这样的东西，当它在你的 DLL 上使用时，它们将允许他们查看你的源代码，有或没有 pdb 文件。

回答by Michael Burr

If you're deploying to a production environement in your own organization, then it's not a security problem.

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

If you're selling your software to other entities, then .pdb file can give someone interested in reverse engineering a leg up - that may or may not be a problem for you.

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

However (to be clear), you don't want your stack traces being displayed to the client - whether or not the .pdbs are available. But if you're just logging the traces and presenting a 'pretty' error page to the client, it's not an issue.

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

回答by Michael

By having debugging symbols, an attacker can determine global variables, function offsets, etc., of interest.

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

So he could see your system has a function like:

所以他可以看到你的系统有这样的功能：

AddAdminUser(string name, string password);

And know its offset. If your program is compromised, he could call this function to give himself admin privileges.

并知道它的偏移量。如果你的程序被入侵，他可以调用这个函数来给自己管理员权限。

Or something like:

或类似的东西：

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

And knows what bit to flip to switch your application into an insecure mode.

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

Alternatively, this would take quite a bit of reverse engineering time to figure out. Not an insurmountable amount of time, however.

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

But . . . this all implies your attacker is already in a position where he can compromise your program. If that's the case, you already lost.

但 。. . 这一切都意味着您的攻击者已经处于可以破坏您程序的位置。如果是这样，你已经输了。

If you have a good business reason to deploy pdb symbols, go ahead. Deploying PDB's won't make you insecure. If you don't have a good reason to deploy, you shouldn't do this as it will make attacks slightly easier.

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

You can also create public PDB files - these strip certain pieces of information, but give you enough symbols to generate a stack trace and do basic debugging. Details are here. Microsoft deploys public PDB's on its symbol server for all to use.

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

EDIT: Most of what I said applies to the concerns around deploying PDB's for native code - I think a lot of these concerns people carry over to .NET as well, even though assembly metadata conveys quite a bit of this already.

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

回答by db_

Somebody can "restore" the complete source code of your application. If it is Open Source you do not need to worry. If it has some IP (algorithms, protection, licenses), it is probably not a good idea.

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

It is true that tools like Reflector can reconstruct parts of your code even without PDB files, but obfuscations can help (well, just a little bit).

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