Web应用程序中的常见安全漏洞( 四 ) _安全漏洞

}
这种预防措施看起来很小，但如果不采取措施，在某些上下文中，暴露敏感数据可能成为针对您的系统使用的优秀工具。
缺少什么方法访问控制?即使在应用程序级别，也不能只对其中一个层应用授权。有时，必须确保完全不能调用特定用例(例如，如果当前经过身份验证的用户的特权不允许调用) 。
假设您有一个设计简单的web应用程序。该应用程序有一个公开端点的控制器。控制器直接调用一个服务，该服务实现了一些逻辑，并使用了通过存储库管理的持久化数据(图1.9) 。设想这样一种情况，授权仅在端点级别完成(假设您可以通过REST端点访问该方法) 。开发人员可能倾向于只在控制器层应用授权规则，如图1.9所示。

文章插图
图 1.9
开发人员在控制器层应用授权规则。但是存储库不知道用户，也不限制数据的检索。如果服务请求的帐户不属于当前经过身份验证的用户，则存储库将返回这些帐户。
虽然图 1.9 所示的情况工作正常，但仅在控制器层应用授权规则可能会留下出错的空间。在这种情况下，一些未来的实现可能不测试就公开该用例，或者不测试所有授权需求。在图 1.10 中，您可以看到如果开发人员添加另一个依赖于同一存储库的功能会发生什么。
可能会出现这些情况，您可能需要在应用程序的任何层处理这些情况，而不仅仅是在存储库中。我们将在后面讨论更多与这个主题相关的事情。在那里，您还将了解如何在需要时对每个应用程序层应用限制，以及应该避免这样做的情况。

文章插图
图 1.10
新添加的 TransactionController 在其依赖关系链中使用 AccountRepository 。开发人员还必须在此控制器中重新应用授权规则。但是，如果存储库本身确保不公开不属于经过身份验证的用户的数据，情况就会好得多。

使用已知漏洞的依赖尽管不一定与 Spring Security 直接相关，但仍然是应用程序级安全的重要方面，但我们需要注意的依赖项。有时，并非具有漏洞的开发应用程序，而是用于构建功能的依赖项，例如库或框架。请始终注意您使用的依赖项，并消除任何已知包含漏洞的版本。
幸运的是，我们可以通过向您的 Maven 或 Gradle 配置中添加插件来快速完成静态分析的多种可能性。如今，大多数应用程序都是基于开源技术开发的。甚至 Spring Security 都是一个开源框架。这种开发方法很棒，并且可以快速发展，但这也使我们更容易出错。
开发任何软件时，我们都必须采取所有必要的措施，以避免使用任何具有已知漏洞的依赖项。如果发现使用了这种依赖关系，则不仅必须快速纠正此问题，还必须调查应用程序中是否已经利用了该漏洞，然后采取必要的措施。

【Web应用程序中的常见安全漏洞】