Eri*_*ric 3 c# exception-handling
今天,有人告诉我,我们应该始终将每个例外都包含在框架的顶层.原因是原始异常可能包含堆栈跟踪或消息中的敏感信息,尤其是堆栈跟踪.
我不知道,有没有任何规则/原则/模式？
Eri*_*ert 15
今天,有人告诉我,我们应该始终将每个例外都包含在框架的顶层.
"总是"似乎有点多了.
与任何其他设计决策一样,您应该考虑成本和收益.
因为原始异常可能包含堆栈跟踪或消息中的敏感信息,尤其是堆栈跟踪.
确实; 异常可能包含敏感信息,攻击者可以使用堆栈跟踪.
有没有任何规则/原则/模式？
是.在进行任何其他操作之前,尤其是在进行设计或代码更改之前,请制作威胁模型.您正在提出安全问题,因此在制定良好的策略来缓解漏洞之前,您绝对必须了解这些威胁.
威胁模型回答的核心问题应该是" 我的应用程序的信任边界是什么？数据何时以及如何跨越边界？这会暴露哪些漏洞？攻击者可以在哪些威胁上取得成功？ "
如果您不确切地了解信任边界,漏洞,威胁和攻击者是什么,那么在尝试设计安全系统以减轻威胁漏洞之前,请先了解这些词语的含义."编写安全代码2"是一个很好的起点.(我的代码安全性书中的第5章对消除异常漏洞提出了一些很好的建议,但它已经绝版了.也许我会在这些日子里把它放在博客上.)
数据可以在任一方向上跨越信任边界; 不受信任的客户端可能正在向您的服务器发送格式错误的数据,并且您的服务器可能正在向不可信任的客户端发送敏感的私有数据.
您的问题专门解决的威胁模型的特定方面是异常形式的数据.我没有告诉你,在我们发布.NET 1.0之前你实际上可以让框架给你一个例外,其中的文本类似于"你没有权限确定目录C:\ foo的名称".(太棒了.谢谢你让我知道.我现在肯定不会用这些信息来攻击用户.)
很明显,人们在我们发货之前很久就已经修好了,但是人们每天都在做道德等同.如果您有跨越信任边界的数据,您应该假设不受信任的一方的恶意用户将尝试在可信方面引起异常,并且将尝试从这些异常中尽可能多地了解系统.不要让攻击者的工作更轻松.
您询问是否应该包装所有异常.也许.如果实际上你遇到了问题 - 如果包含敏感数据的异常可以跨越信任边界,那么包装异常是正确的.但也许还不够.也许你不需要在边界上抛出异常,即使异常可以被消除.也许正确的做法是继续全红警报并说"嘿,我们得到了一个潜在敌对的第三方的不良数据引起的意外异常,所以让我们(1)禁止他们的IP,或者(2)将他们重定向到蜜罐服务器,或(3)警告安全部门,或(4)其他东西." 正确的解决方案取决于您尚未说明的威胁.
就像我说的那样,你需要做的第一件事就是模拟威胁.在不彻底了解威胁的情况下,不要做出安全决策.