程序员征服安全：基础设施即代码系列 - 业务逻辑

“基础设施即代码”系列到此就告一段落了。希望大家在攻克 Docker、Ansible、Kubernetes、Terraform 和 CloudFormation 的安全问题时收获颇丰。在结束之前，我们还要带大家掌握最后一个漏洞：业务逻辑漏洞。

准备好测试一下自己的技能了吗？快来挑战最后的通关任务：

如果还有些地方不太明白，请继续阅读：

我们今天要重点讨论的漏洞是 业务逻辑 缺陷。当开发人员未能正确实现业务逻辑规则时，就会产生此类缺陷，这可能导致应用程序在遭受恶意用户攻击时变得脆弱。根据每个应用程序的用途和功能，业务逻辑缺陷可能会导致权限提升、资源滥用或执行各种非预期的业务流程。

与许多漏洞不同，业务逻辑规则的错误实现往往非常隐蔽。需要格外警惕，以确保它们不会潜入应用程序和代码中。

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

为了说明业务逻辑缺陷有多容易产生，我们来看一个 Docker Compose 文件定义的 Docker 环境示例。为了让容器能够执行特定功能，开发人员可能会在 Docker Compose 文件中使用如下所示的标准资源策略：

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"

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

为了防止用户占用过多资源，开发人员可能会尝试更好地定义每个容器的承载能力。因此，新代码可能会包含一个放置约束：

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"
   placement:
     constraints:
       - "node.labels.limit_cpu == 100M"
       - "node.labels.limit_memory == 0.5"

乍一看，这似乎解决了 业务逻辑 缺陷。然而，新的放置约束并不会影响 Docker 容器服务的资源使用限制，它仅用于选择调度容器的节点。在这种情况下，DoS 攻击仍然可能发生。攻击者只需先攻破一个 Docker 容器，之后便能无限制地耗尽资源。

由此可见，思考业务逻辑缺陷并通过编程消除它们是一项棘手的工作。

消除业务逻辑缺陷

应对业务逻辑缺陷的关键在于意识到它们的存在。在编写新代码时，必须时刻保持警惕，防止它们进入你的环境。业务规则和最佳实践应在应用程序开发的各个阶段（包括设计、实现和测试）得到明确定义和检查。

例如，为了防止业务逻辑缺陷导致上述的 DoS 攻击，最佳实践是限制你创建的每个 Docker 容器所能使用的资源量。具体来说，limits 部分必须指定 Docker 容器可以使用的 CPU 数量和内存大小。示例如下：

deploy:
 resources:
   limits:
     cpus: "0.5"
     memory: 100M
   reservations:
     cpus: "0.5"
     memory: 50M

将上述代码作为策略使用，可以消除环境中的重大业务逻辑缺陷，并防止 DoS 攻击。即使攻击者攻破了其中一个 Docker 容器，这种方法依然有效。在这种情况下，攻击者也无法利用已获得的立足点来耗尽资源。

威胁建模有助于明确各种攻击的发生方式，并确保通过业务逻辑规则来预防和限制这些攻击。基于合规性规则和已知滥用案例进行测试，也有助于发现那些被遗漏的业务逻辑缺陷。

业务逻辑缺陷是应用程序中最隐蔽的漏洞之一，但其危险程度丝毫不亚于其他高调的风险。了解这些缺陷的成因并采用最佳实践，可以在应用开发阶段将其拒之门外，确保它们不会进入生产环境，从而避免被那些深谙其道的攻击者利用。

请访问 Secure Code Warrior 博客页面，深入了解此类漏洞，以及如何保护您的组织和客户免受其他安全缺陷的侵害。您还可以 申请演示 Secure Code Warrior 培训平台中的 IaC 挑战，以保持您的网络安全技能精进且与时俱进。