多层应用程序中的异常处理
web应用程序中的错误和异常处理可能会带来安全问题，通常以拒绝服务(即服务因错误处理不善而崩溃时)和信息泄露(即包含系统敏感细节的异常被传播给用户/攻击者)的形式出现。
为了解决这一问题，系统需要优雅地失败，尽可能地揭示故障的细节和恢复。当涉及到异常时，托管语言具有简单而又易于理解的异常处理机制。然而，在我的整个研究过程中，我没有找到关于如何在现代web应用程序中构建适当的异常处理机制的建议，这种机制包括数据库和客户端应用程序之间的几层逻辑。
例如，Spring框架有控制器(提供API和处理HTTP请求)、服务(包含大部分业务逻辑)和存储库(处理应用程序和数据库之间的通信)。此外，该服务还可以与提供各种功能(即文件访问、算法计算)的实用组件和模块进行接口。下面的数据流图说明了该体系结构。
通过检查异常的起源，我们可以看到，计算引擎、存储库和文件访问实用程序(可能)可以(潜在)显示系统的一些细节，如果在与不同的数据存储(即有关SQL数据库、知识库模式等的信息)接口时抛出异常。
接下来的问题是，开发人员应该在哪里处理这些异常，并降低信息披露和拒绝服务的风险？
一种似乎适合我的方法是在异常出现时处理它们，并将它们封装到特定于应用程序的异常中。应用程序中具有跨越信任边界(例如文件系统、Internet)的数据流的部分应该清理所有异常，方法是将它们包装为“更友好”的自定义异常(由开发人员创建)，以防止信息泄露的任何风险进一步传播，以及本地化任何组件故障。然后，内部组件应该知道如何更合适地处理应用程序异常。
这种方法的主要缺点是异常处理机制更加复杂，因为它需要为每一类本机(和适用的)异常引入特定于应用程序的异常。
这种方法是否有其他的优点和缺点，是否有一种更好地处理安全和工作负载之间平衡的替代设计？
回答 2
Security用户
发布于 2019-08-26 21:16:08
投票结束这一点，因为这不是一个安全问题。这是一个关于软件工程和体系结构的问题：
处理异常的最佳地方是尽可能接近异常发生的地方--功能的分离完全是抽象的--远程更高级别是独立的，因为他们不知道底层发生了什么，因此他们无法提供关于事件的有意义的消息，而不处理自动响应。尽管如此，跟踪(可能是分布式的)事务是至关重要的，以便
- 准确记录因果关系
- 解决数据问题
这意味着入口点在出现异常时有一个非常特定的角色；它需要使用与子组件消息一起传播的唯一标识符标记事务。
Security用户
发布于 2018-11-29 19:58:01
你提到
开发人员应该在哪里处理这些异常，并降低信息披露和拒绝服务的风险？
您的服务或程序的异常应该由程序/服务本身作为一般规则来处理。如果服务不处理生成的异常，那么这可能是一个安全问题，这取决于错误。
正确的方法将是验证API的正确使用，例如，如果您的服务使用可以引发ConnectionError或BadURI的函数ConnectionError或BadURI，则程序有责任正确处理以避免在执行过程中出现未知路径。
我为运行在后端的软件提供了一个很好的实践，例如，服务通常有一个方法运行来处理HTTP请求、SMTP或其他任何东西，而且这个方法总是在一个try块上，并捕获所有异常。一旦你准备好了，你就可以开始深入到你的代码中去，做更多的指定异常块，并验证你的系统是稳定的，希望这对你有所帮助。
https://security.stackexchange.com/questions/198739
复制相似问题
腾讯云开发者
