【2025版】最新业务逻辑漏洞利用原理，从零基础到精通，收藏这篇就够了！

点击蓝字

关注我们

始于理论，源于实践，终于实战

老付话安全，每天一点点

激情永无限，进步看得见

什么是业务逻辑漏洞

业务逻辑漏洞是应用程序设计和实现中的缺陷。业务逻辑漏洞的出现通常是因为设计和开发团队对用户将如何与应用程序交互做出了有缺陷的假设。这些错误的假设可能导致用户输入的验证不充分。简单讲就是应用程序设计时的逻辑缺陷。

逻辑通常是应用程序及其特定功能所独有的漏洞，识别这些漏洞通常需要一定数量的人类知识，例如对业务领域的了解或攻击者在给定上下文中可能的目标。这使得它们很难使用自动漏洞扫描程序进行检测。需要手动测试人员和漏洞悬赏的方式来挖掘。

业务逻辑漏洞示例

下面的例子可以给我们提供一些逻辑漏洞的挖掘思路，在实际渗透测试过程我们需要以此为例来形成自己的挖掘漏洞思路。

对客户端控件的过度信任

客户端控件是指在Web应用中，运行在客户端浏览器上的交互元素。它们通常以HTML表单元素、JavaScript组件等形式出现，用于收集用户输入、展示数据或提供交互功能。常见的客户端控件包括文本框、下拉列表、复选框、按钮、日期选择器等。

开发者认为用户输入的数据已经通过客户端的验证，因此在服务器端没有进行二次验证。攻击者修改表面数据，而不执行适当的完整性检查和服务器端验证。攻击者可以使用一些代理软件修改请求中的价格，从而以代价购买产品。

无法处理非常规输入

应用程序逻辑的一个目标是将用户输入限制为符合业务规则的值。如果应用程序没有正确处理非常规的输入数据，导致业务逻辑出现偏差。如数值数据类型可能接受负值。根据相关功能，业务逻辑觉得这样做可能没有意义。但是，如果应用程序未执行适当的服务器端验证并拒绝此输入，则攻击者可能能够传入负值并引发不需要的行为。

对用户行为做出有缺陷的假设

逻辑漏洞最常见的根本原因之一是对用户行为做出有缺陷的假设。

受信任的用户不会总是值得信赖，业务规则和安全措施未在整个应用程序中一致地应用，则可能导致潜在危险的漏洞，攻击者可能会利用这些漏洞。

用户不会总是提供强制性规则下的输入，一种误解是用户将始终为必填输入字段提供值。浏览器可能会阻止普通用户在没有必要输入的情况下提交表单，但正如我们所知，攻击者可以在传输过程中篡改参数。这甚至扩展到完全删除参数。在同一个服务器端脚本中实现多个函数的情况下，特定参数的存在与否可能决定执行哪个代码。删除参数值可能允许攻击者访问本应不可触及的代码路径。

探测逻辑缺陷时应该：

1、一次只删除一个参数，以确保达到所有相关代码路径。查看响应的影响。

2、尝试删除参数的名称和值。服务器通常会以不同的方式处理这两种情况，查看响应的影响。

3、遵循多阶段流程直至完成。在一个步骤中篡改参数会影响工作流中后续步骤中的另一个步骤。

用户不会总是遵循预期的顺序，Web 界面通常会指导用户完成一系列步骤组成的预定义工作流，但是，攻击者不一定会遵守此预期顺序。许多实施双重身份验证的网站要求用户在单独的页面上输入验证码之前先在一个页面上登录。如果不先验证是否登录然后输入验证码则可能会允许攻击者完全绕过双重身份验证。

特定领域的业务缺陷，是指在特定业务领域或应用场景中特有的业务逻辑漏洞。这个需要渗透测试人员熟悉业务应用场景和逻辑。需要通过大量阅读文档或者与该领域的专家进行讨论从而挖掘出逻辑漏洞。

提供加密 oracle

当用户可控制的输入被加密，然后以某种方式将生成的密文提供给用户时，可能会发生危险的情况。攻击者可以使用此输入来加密使用正确算法和非对称密钥的任意数据。当应用程序中存在其他用户可控制的输入，这些输入需要使用相同的算法加密数据时，攻击者可能会使用加密 oracle 生成有效的加密输入，然后将其传递到其他敏感函数。如果网站上有另一个用户可控制的输入提供反向功能，这将使攻击者能够解密其他数据以识别预期的结构。但这不是获取漏洞所必须的。

电子邮件地址解析器差异

一些网站会解析电子邮件地址以提取域并确定电子邮件所有者属于哪个组织。电子邮件地址解析方式的差异可能会破坏这种逻辑。当应用程序的不同部分以不同的方式处理电子邮件地址时，就会出现这些差异。攻击者可以使用编码技术来利用这些差异来伪装电子邮件地址的某些部分。这使攻击者能够创建通过初始验证检查但服务器解析逻辑对不同解释的电子邮件地址。

END