这是Stack Overflow 上原始问题的副本，它并没有得到太多的爱，在这里可能更相关：
应用程序不应该在 debug="true" 模式下运行有很多性能原因（Scott Gu 提供了很好的概述），但是这种做法是否暴露了任何攻击向量？这不是“你应该还是不应该”的问题，这一点很清楚，而是它是否引入了任何特定漏洞的问题。
我倾向于认为远程检测它的能力与已知的性能问题相结合可能会导致对服务可用性的利用，但我想要一些更明确的东西。有谁知道可以针对运行 debug="true" 的应用程序进行编排的特定攻击？
我在这里和Stack Overflow 上都对这个问题有过一些有趣的反馈。有很多与堆栈跟踪（自定义错误问题，不是调试问题）和性能（不是 [直接] 安全问题）相关的响应。
最引人注目的回应是条件编译常量 (#if DEBUG...) 可能会导致意外行为，但这更多的是功能风险（在实时环境中执行的意外代码），而不是安全风险。
我怀疑调试模式可能会根据它对应用程序的性能开销和远程检测它的能力（可能是服务连续性风险）打开一些通往其他漏洞的途径。作为OWASP Top 10 for .NET 开发人员第 6 部分：安全错误配置的一部分，我已经写下了我的结论。
因此，为了完整起见，答案似乎是在调试模式下运行没有明显的安全风险，但考虑到上述因素，这对于生产应用程序来说肯定不是一个好主意。
通过允许潜在的攻击者潜在地访问源代码、堆栈跟踪等，这无疑使他们能够集中/缩小对系统的攻击。
我还假设（尽管尚未对其进行测试）由于 debug=true 导致编译错误而不是预期的站点自定义错误，因此您可能会遇到 .net customerror 加密错误。
http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx
当 debug=true 时要记住的最重要的事情是符号在那里。可以使用 debug=true 预编译应用程序，但这是部署过程的一部分。例如，您通过构建服务器或在本地计算机上构建它并传输程序集。（每个人都在生产部署之前预编译他们的应用程序，对吧？！:)）调试也关闭了某些运行时优化。一个明显的攻击是 DoS。如果自定义错误已关闭，您还可以在调用堆栈上找到更多信息——这比自定义错误已关闭且符号不存在时更重要。
我认为如果 customErrors = off 并且 debug=true，那么更多的信息会被发送给攻击者。
说 customErrors = on 或 customErrors = RemoteOnly 更安全。这样，远程用户将始终获得通用的 ASP.NET 错误页面。有关MSDN的更多信息