程序员以代码的形式征服安全基础架构系列-商业逻辑

好吧，就是这样（目前）。我们的 “基础设施即代码” 系列已经走到了尽头。我们希望你在克服 Docker、Ansible、Kubernetes、Terraform 和 CloudFormation 中的安全问题时玩得开心。但是，在我们注销之前，我们还有一个漏洞需要你掌握：业务逻辑错误。

认为你现在准备好测试自己的技能了吗？试试最后的游戏化挑战：

如果你仍然不清楚一些事情，请继续阅读：

我们今天要重点关注的漏洞是 商业逻辑 缺陷。当程序员无法正确实现业务逻辑规则时，就会发生这种情况，如果恶意用户选择利用这些规则，他们的应用程序可能容易受到不同类型的攻击。根据每个应用程序中实现的目的和功能，业务逻辑缺陷可能允许权限升级、不当使用资源或执行任意数量的意外业务流程。

与许多漏洞不同，业务逻辑规则的错误实现可能出人意料地微妙。他们需要特别警惕，以确保他们不会潜入应用程序和代码。

有哪些业务逻辑缺陷的例子？

举例说明诱发业务逻辑缺陷有多么容易，可以考虑以下使用 Docker Compose 文件定义的 Docker 环境中的示例。为了准备容器以执行功能，开发人员可以使用在 Docker Compose 文件中定义的标准资源策略，例如以下示例：

部署：
资源：
极限：
中央处理器：“0.5”
预订：
中央处理器：“0.5”

虽然表面上看起来不错，但这种容器资源策略并未正确限制资源的使用。攻击者可以利用业务逻辑缺陷实施拒绝服务 (DoS) 攻击。

为了限制用户占用太多资源，开发人员可能会尝试更好地定义每个容器可以支持的内容。因此，新代码可能包含放置限制：

部署：
资源：
极限：
中央处理器：“0.5”
预订：
中央处理器：“0.5”
放置：
限制：
-“node.labels.limit_cpu == 100M”
-“node.labels.limit_memory == 0.5"

乍一看，这似乎可以解决 商业逻辑 缺陷。但是，新的放置限制不会影响 Docker 容器服务的资源使用限制。它仅用于选择一个节点来调度容器。在这种情况下，DoS 攻击仍然是可能的。攻击者需要先入侵 Docker 容器，但之后可以无限制地消耗资源。

如您所见，考虑业务逻辑缺陷并编程消除这些缺陷可能是一项棘手的任务。

消除业务逻辑缺陷

由于业务逻辑缺陷，关键是要知道它们的存在。在编写新代码时，你需要保持警惕，不要让它们进入你的环境。在应用程序开发过程的所有阶段，包括设计、实施和测试，都应明确定义和检查业务规则和最佳实践。

例如，为了防止业务逻辑缺陷引发上例中的 DoS 攻击，最佳做法是限制您创建的每个 Docker 容器可以使用的资源量。具体而言，限制部分必须指定 CPU 的数量和 Docker 容器可以使用的内存量。一个例子是：

部署：
资源：
极限：
中央处理器：“0.5”
内存：100M
预订：
中央处理器：“0.5”
内存：50M

使用上面示例的代码作为策略可以消除环境中的主要业务逻辑缺陷并防止 DoS 攻击。即使攻击者入侵了其中一个 Docker 容器，这也能起作用。在这种情况下，攻击者仍然无法利用其立足点消耗资源。

威胁建模可以通过定义不同攻击的发生方式并确保使用业务逻辑规则来预防和限制攻击来提供帮助。基于合规规则和已知滥用案例的测试也可能有助于发现漏洞的业务逻辑缺陷。

业务逻辑缺陷是一些最微妙的漏洞，可以潜入应用程序，但其危险性不亚于其他更引人注目的风险。了解它们是如何发生的并使用最佳实践可以使它们在应用程序开发期间远离您的环境，从而确保它们永远不会进入生产环境，在那里它们会被非常熟悉如何利用它们的攻击者滥用。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 在 Secure Code Warrior 培训平台上进行这项 IaC 挑战赛，让您的所有网络安全技能不断磨练并保持最新状态。