编码员征服安全的基础设施即代码系列--商业逻辑

好了，这就是它（目前）。我们的基础设施即代码系列已经结束了。我们希望你在征服Docker、Ansible、Kubernetes、Terraform和CloudFormation中的安全问题时感到愉快。不过在我们结束之前，我们还有一个漏洞需要你掌握：业务逻辑错误。

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

如果你对一些事情还不清楚，请继续阅读。

我们今天要关注的漏洞是业务逻辑缺陷。当编码员未能正确地实现业务逻辑规则时，就会出现这些漏洞，如果恶意用户选择利用它们，就会使他们的应用程序容易受到不同种类的攻击。根据每个应用程序的目的和实现的功能，业务逻辑缺陷可能允许特权升级、不适当的资源使用或任何数量的非预期的业务流程被执行。

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

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

作为诱发业务逻辑缺陷的一个例子，请考虑下面这个用Docker Compose文件定义的Docker环境中的例子。为了准备容器执行功能，开发者可能会使用一个标准的资源策略，在Docker Compose文件中定义，就像下面这个例子。

部署：
资源。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"

虽然这在表面上看起来很好，但这个容器的资源策略并没有正确限制资源的使用。攻击者可以利用业务逻辑的缺陷来实施拒绝服务（DoS）攻击。

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

部署：
资源。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
placement:
constraints:
- "node.labs.limit_cpu == 100M"
- "node.labs.limit_memory == 0.5"

乍一看，这似乎可以解决业务逻辑的缺陷。然而，新的放置约束并不影响Docker容器服务的资源使用限制。它只是用来选择一个节点来安排容器。在这种情况下，DoS攻击仍然是可能的。攻击者需要先破坏一个Docker容器，但之后就可以无限制地消耗资源。

正如你所看到的，思考商业逻辑的缺陷并通过编程来消除它们可能是一项棘手的工作。

消除业务逻辑缺陷

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

例如，为了防止业务逻辑缺陷导致DoS攻击，比如上面的例子，一个最佳做法是限制你创建的每个Docker容器可以使用的资源量。具体来说，限制部分必须指定一个Docker容器可以使用的CPU数量和内存数量。一个例子是。

部署：
资源。
limits:
cpus:"0.5"
memory: 100M
reservations:
cpus:"0.5"
内存。50M

使用像上面的例子那样的代码作为一个策略，可以从环境中消除一个主要的业务逻辑缺陷，并防止DoS攻击。即使攻击者破坏了其中一个Docker容器，这也是可行的。在这种情况下，攻击者仍然无法利用他们的立足点来耗尽资源。

威胁建模可以通过定义不同攻击的发生方式，并确保使用业务逻辑规则来防止和限制它们，从而起到帮助作用。基于合规规则和已知滥用案例的测试也可以帮助捕捉漏网之鱼的业务逻辑缺陷。

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

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示这个IaC挑战，以保持你的所有网络安全技能得到磨练和更新。