逻辑缺陷深度解析：从访问控制绕过到加密漏洞的利用

引言

应用程序的复杂性是安全应用的最大敌人。随着Web应用程序变得越来越复杂，无数逻辑缺陷也随之而生。与易于自动化的技术性漏洞不同，业务逻辑错误源于开发人员对系统行为的期望与攻击者操纵它们的方式之间的差距。

在本文中，我们将探讨如何识别并利用业务逻辑缺陷，以绕过限制、提升权限并引入可利用的行为。

什么是业务逻辑漏洞？

业务逻辑漏洞发生在应用程序的工作流程可以被利用，从而违反预期的业务规则时，即使代码完全按照编写的方式执行。它们源于实现与实际行为之间的差距，当开发人员对用户行为做出假设但未能考虑边界情况，或在复杂的工作流程中未能持续验证状态转换时，就会出现这些漏洞。

然而，值得注意的是，并非所有未记录的行为都会导致安全漏洞。因此，理解何时识别的逻辑错误对组织构成安全威胁至关重要，尤其是在参与漏洞赏金计划时。

为此，我们必须审视三个严重性评分指标，并自问识别的行为是否对其中任何一项产生影响：

机密性：识别的逻辑缺陷是否允许查看其他情况下无法访问的机密信息？
完整性：识别的逻辑缺陷是否允许修改通常受保护的数据？
可用性：您能否部分或完全拒绝对单个组件甚至整个应用程序的访问，使其无法使用？

回答这些问题将有助于确定您面对的是实际的安全弱点还是简单的功能性错误。

一些实际例子：

复杂的访问矩阵：企业应用程序中的权限配置文件，复杂的权限控制通常会导致访问控制漏洞。
业务规则验证不完整：退款系统可能检查订单是否存在，但未检查是否已退款，从而允许重复退款。
信任客户端数据：依赖用户提供的价格、货币、数量或用户ID而不进行服务器端验证的应用程序，容易受到操纵，也可能导致注入攻击。
关键操作中的竞争条件：如果账户余额检查未正确锁定，两个同时的提款请求可能都成功，从而导致透支。
有缺陷的状态管理：多步骤流程（如结账流程）可能允许用户跳过步骤、重放步骤或访问不应达到的状态。

不可利用行为的示例

如前所述，并非所有逻辑缺陷都被视为安全弱点。有些只是表现出无法进一步升级的奇怪行为，通常是在内部QA测试中未发现的功能性错误。

几个无法被视为安全威胁的实际例子：

修改仅属于您自己的数据，即使应用程序前端阻止其被更改。
不影响授权或金钱的错误计算。
性能或效率问题：能够创建无限数量的数据对象，其唯一影响是（略微）降低客户端性能。

上述所有示例都是逻辑缺陷，没有实际的安全影响。需要注意的是，一些组织可能希望了解此类缺陷，而另一些组织则会将其视为可接受的风险。

利用业务逻辑错误

导致访问控制失效的逻辑缺陷

Web应用程序中的权限配置文件并不少见。它们为管理员账户提供了在单个租户内为用户或组设置权限的功能。然而，权限定义越细化，就越复杂。当多个权限规则在单个用户或用户组上强制执行时，这可能导致访问控制问题。

另一个例子是在引入意外行为时未能强制执行访问控制。请考虑以下代码片段，您能发现其中的问题吗？

1

// 代码示例：通过order_initiation_id参数操纵，可能导致访问其他用户订单数据的漏洞

在上述代码片段中，我们可以看到结账确认路由根据会话对象中的订单ID检索订单信息。如果我们仔细查看结账流程中的前一个步骤，可以注意到订单ID是从order_initiation_id主体参数中读取的。这里的问题在于，开发人员从未考虑验证此订单ID以确保其唯一、不存在，并且最重要的是属于当前客户。

考虑到这一点，我们可以将order_initiation_id设置为我们想要的任何值，完成结账，并可能访问其他客户的机密数据。

导致注入攻击的逻辑缺陷

不一致的输入验证通常会导致注入攻击。考虑到这一点，您应该注意输入验证有限或不存在的场合。考虑以下示例。

下面的应用程序旨在禁止包含XSS、SSTI或SQLi负载的格式错误的电子邮件地址。

1

// 代码示例：初始注册时对邮箱输入进行了安全过滤

但是，在注册后，您决定退订所有营销邮件，此时您会看到一个新的门户，允许您配置所有电子邮件首选项，包括更改您的电子邮件。如果这个相同的门户与主应用程序同步更改，它可能根本不验证您的输入，并允许您将电子邮件更改为包含类似我们先前尝试的负载：

1

// 代码示例：在另一个功能点（如偏好设置）修改邮箱时缺乏验证，允许注入SSTI等攻击载荷

这种缺乏一致输入验证的情况可能导致注入攻击，正如我们在上面的示例中所观察到的那样。

导致价格操纵漏洞的逻辑缺陷

与注入攻击类似，逻辑缺陷也可能导致价格操纵漏洞，主要是由于对用户参数的处理不当。请看下面的例子，您能识别其中的弱点吗？

1

// 代码示例：结算时从用户可控的currency参数读取货币代码，未经验证即传递给支付网关

在上述代码片段中，我们可以注意到在第15行，货币代码是从用户可控制的源读取的。然而，通过仔细检查代码，我们可以观察到负责计算结账价格的代码并未考虑这一点。相反，它在没有进一步验证的情况下将此值转发给第三方支付网关以完成结账。

实际上，这意味着我们可以将货币代码从USD调整为JPY，从而降低我们的结账价格。

上述缺陷源于一个简单的疏忽，可能使恶意买家能够以大幅折扣的价格购买已售出的商品。

导致加密缺陷的逻辑错误

逻辑错误也可能导致加密缺陷，例如，由于随机生成器弱或敏感令牌的不安全存储。不正确的处理也会打开安全缺口，使攻击者能够预测或生成全新的令牌。

此类缺陷的一个例子是JSON Web Token实现中对none算法的支持。让我们仔细看一个例子。

1

// 代码示例：JWT验证时未处理"none"算法，导致认证绕过

在第27行，您可以密切观察到开发人员如何未能考虑攻击者向经过身份验证的端点发送未签名JWT令牌的情况。缺乏适当的处理源于疏忽，在这种情况下，导致了完全的身份验证绕过。

为了测试此类情况，您必须尝试理解开发人员在应用程序中开发某些功能时通常采用的实现路径。

结论

业务逻辑缺陷常常被低估，因为它们要求研究人员对目标具有一定的经验和知识，而这很少被提供。在本文中，我们探讨了测试逻辑缺陷的重要性，以及这种弱点如何导致有影响的漏洞。

因此，您刚刚学到了一些关于绕过业务逻辑缺陷的新知识……现在是时候将您的技能付诸实践了！您可以通过在易受攻击的实验室和CTF上进行练习开始，或者……浏览我们在Intigriti上的70多个公开漏洞赏金计划，谁知道呢，也许在您下次提交时就能获得赏金！