在生产环境中部署调试符号（pdb文件）有什么风险？ [英] What's the risk of deploying debug symbols (pdb file) in a production environment?
问题描述
我有一个记录异常跟踪记录的应用程序，我希望这些堆栈跟踪在生产环境中部署时包括文件名和行号。我想出了如何使用程序集部署调试符号，但是在研究问题的过程中，我遇到了，这意味着在生产环境中包含pdb文件不是一个好主意。对接受的答案的评论说： ...调试信息可以泄露敏感数据并成为攻击媒介。取决于您的应用程序是什么。
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."
那又是什么类型敏感数据可能被暴露？调试符号如何用于危害应用程序？我对技术细节感到很好奇，但是我真正想要的是一种评估在任何给定应用程序和生产环境中包括调试符号的风险的实用方法。或换一种说法：最糟糕的情况是什么？
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?
编辑：后续问题/说明
因此，根据到目前为止的每个人的答案，.NET应用程序似乎可以简化此问题。 John Robbins博客链接到迈克尔·马多克斯（Michael Maddox）的答案突然出现在我身上：
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 blog linked in Michael Maddox's answer kind of leaped out at me:
A。 NET PDB仅包含两条
信息，即源文件名和
行，以及局部变量
名。所有其他信息都是.NET元数据中已经存在的
，因此，
无需在PDB文件中重复相同的
信息。
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.
对我来说，这重申了其他人对Reflector的看法，这意味着真正的问题是对程序集的访问。确定之后，关于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?
推荐答案
这里是另一个需要考虑的问题：
Here is another question to look at:
有关PDB文件的更多信息：
And more info on PDB files:
通常，我总是在部署中包括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.
发生用户可见的堆栈跟踪时，用户可以看到完整的堆栈跟踪，包括您的文件名和文件行号。这样可以使他们对您的应用程序的架构有一些了解，如果被黑客入侵可能会对他们有帮助。
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.
更大的安全威胁类似于反射器，当在您的DLL上使用该反射器时，它们将允许您查看带有或不带有pdb文件的源代码。
A bigger security threat is something like Reflector which when used on your DLLs will allow them to view your source code, with or without pdb files.
这篇关于在生产环境中部署调试符号（pdb文件）有什么风险？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
