今天，有人告诉我，我们应该始终将每个异常都包装在框架的顶层。 原因是原始异常可能包含堆栈跟踪或消息中的敏感信息，尤其是堆栈跟踪。
不知道，有什么规则/原则/模式吗？
最佳答案
Today, someone told me that we should always wrap every exception at the top level of the framework.
“总是”似乎有点多。
与任何其他设计决策一样，您应该考虑成本和 yield 。
Because the original exception may contains sensitive information in the stacktrace or message, especially the stacktrace.
的确；异常可能包含敏感信息，并且堆栈跟踪可以被攻击者使用。
are there any rules/principles/patterns?
是的。在你做任何其他事情之前，特别是在你进行设计或代码更改之前，建立一个威胁模型。您问的是一个安全问题，因此您绝对必须了解威胁，然后才能设计出减轻漏洞的良好策略。
您的威胁模型回答的核心问题应该是“我的应用程序的信任边界是什么？数据何时以及如何跨越边界？什么这会暴露哪些漏洞？结果是攻击者可以利用哪些威胁？”
如果您不能准确理解什么是信任边界、漏洞、威胁和攻击者，那么在您尝试设计安全系统以减轻威胁漏洞之前，了解这些词的含义。 “编写安全代码 2”是一个不错的起点。 (我关于代码安全的书的第 5 章有一些关于消除异常漏洞的好建议，但它已经绝版了。也许有一天我会把它放在博客上。)
数据可以在任一方向跨越信任边界；不受信任的客户端可能正在向您的服务器发送格式错误的数据，而您的服务器可能正在向不受信任的客户端发送敏感的私有(private)数据。
您的问题具体涉及的威胁模型的特定方面是异常形式的数据。我没有骗你，在我们推出 .NET 1.0 之前，你实际上可以让框架给你一个异常，其文本类似于“你没有权限确定目录 C:\foo 的名称”。 (太好了。感谢您让我知道。我现在一定不会使用该信息来攻击用户。)
显然，在我们发货之前很久就已经修好了，但人们每天都在做道德上等同的事情。如果您有跨越信任边界的数据，您应该假设不受信任端的恶意用户将尝试在受信任端引发异常，并尝试从这些异常中尽可能多地了解系统。 不要让攻击者的工作更轻松。
您询问是否应包装所有异常。或许。如果您确实遇到了问题——如果包含敏感数据的异常可以跨越信任边界，那么包装异常可能是正确的做法。但也许这还不够。也许您根本不需要跨边界抛出异常，即使异常可以被清除。也许正确的做法是继续保持完全红色警报并说“嘿，我们收到了一个意外异常，该异常是由来自潜在敌对第三方的错误数据引起的，所以让我们(1)禁止他们的 IP，或(2)将他们重定向到蜜 jar 服务器，或 (3) 提醒安全部门，或 (4) 其他。”什么是正确的解决方案取决于您尚未说明的威胁。
正如我所说，您需要做的第一件事就是对威胁建模。不要在没有彻底了解威胁的情况下做出安全决策。
关于c# - 是否有必要在顶层包装每个异常？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9357807/