业务逻辑漏洞

概念

什么是逻辑漏洞

业务逻辑漏洞是指应用程序的设计和实施中存在缺陷，允许攻击者诱发非预期行为。这有可能使攻击者操纵合法功能来实现恶意目标。这些漏洞通常是由于未能预见到可能出现的异常应用程序状态，因而未能安全地处理这些状态造成的。

逻辑缺陷通常不会在正常使用应用程序的过程中暴露出来，因此没有明确查找逻辑缺陷的人通常看不到这些缺陷。但是，攻击者可能会以开发人员从未想过的方式与应用程序进行交互，从而利用行为怪癖。

业务逻辑的主要目的之一是执行设计应用程序或功能时定义的规则和约束。从广义上讲，业务规则规定了应用程序在发生特定情况时应如何做出反应。这包括防止用户做出会对业务产生负面影响或根本不合理的行为。

逻辑中的漏洞会让攻击者规避这些规则。例如，他们可能不通过预定的购买工作流程就能完成交易。在其他情况下，对用户提供数据的验证失效或不存在，可能会让用户任意更改交易关键值或提交无意义的输入。通过向服务器端逻辑传递意外值，攻击者有可能诱使应用程序做一些不应该做的事情。

基于逻辑的漏洞种类繁多，通常是应用程序及其特定功能所独有的。识别这些漏洞往往需要一定的人类知识，如了解业务领域或攻击者在特定情况下可能具有的目标。因此，使用自动漏洞扫描仪很难检测到它们。因此，逻辑缺陷是漏洞赏金猎人和人工测试人员的首选目标。

逻辑漏洞的产生

业务逻辑漏洞的产生往往是因为设计和开发团队对用户将如何与应用程序进行交互做出了错误的假设。这些错误的假设可能导致用户输入验证不充分。

例如，如果开发人员假定用户将完全通过网络浏览器传递数据，那么应用程序可能会完全依赖薄弱的客户端控件来验证输入。使用拦截代理的攻击者很容易绕过这些控制。

归根结底，这意味着当攻击者偏离预期的用户行为时，应用程序无法采取适当的措施加以防范，从而无法安全地处理这种情况。

逻辑缺陷在过于复杂的系统中尤为常见，甚至连开发团队自己都无法完全理解。要避免逻辑缺陷，开发人员需要从整体上了解应用程序。这包括了解不同功能如何以意想不到的方式组合在一起。负责大型代码库的开发人员可能无法深入了解应用程序的所有工作区域。开发一个组件的人可能会对另一个组件的工作方式做出错误的假设，结果无意中引入了严重的逻辑缺陷。如果开发人员没有明确记录所做的任何假设，这类漏洞就很容易潜入应用程序中。

逻辑漏洞的危害

业务逻辑漏洞的影响有时可能相当微不足道。这是一个广泛的类别，影响也是千变万化的。但是，如果攻击者能够以正确的方式操纵应用程序，任何意外行为都有可能导致严重的攻击。因此，即使你自己无法找出如何利用它，最好也要修复古怪的逻辑。别人总是有可能利用它。

从根本上说，任何逻辑缺陷的影响都取决于它与哪些功能相关。例如，如果缺陷出现在身份验证机制中，就会对整体安全性造成严重影响。攻击者有可能利用这一点进行权限升级，或完全绕过身份验证，从而获取敏感数据和功能。这也增加了其他漏洞的攻击面。

金融交易中的逻辑漏洞显然会导致企业因资金被盗、欺诈等而蒙受巨大损失。
即使逻辑缺陷可能不会让攻击者直接受益，但仍可能让恶意方以某种方式损害企业。

业务逻辑漏洞场景

业务逻辑漏洞因其发生的环境而相对特殊。不过，虽然逻辑漏洞的个别情况差异很大，但它们可以有许多相似的地方。我们可以根据其错误的逻辑进行大致的分类

1. 过度信任客户端控件
2. 未能处理非常规输入
3. 对用户行为做出错误的假设
4. 特定领域的缺陷
5. 提供加密甲骨文

过度信任客户端控件

一个存在漏洞的假设是，用户只会通过提供的网络接口与应用程序进行交互。这一点尤其危险，因为它会导致进一步的假设，即客户端验证将防止用户提供恶意输入。然而，攻击者只需使用 抓包 等工具，就能在数据由浏览器发送之后、传入服务器端逻辑之前对其进行篡改。这实际上会使客户端控件失去作用。

如果不执行适当的完整性检查和服务器端验证，只按表面价值接受数据，攻击者就能以相对较小的代价造成各种破坏。至于攻击者到底能达到什么目的，则取决于功能及其对可控数据的处理。在适当的情况下，这种漏洞可能会对业务相关功能和网站本身的安全性造成破坏性后果。

借下来完成靶场的第一个实验 —— Lab: Excessive trust in client-side controls
首先进行登录，账户下有100购物币，我这里是已经完成实验了

现在要求我们用这100购物币购买超出100的商品
那么有两种思路：

1. 将商品提交至购物车时，修改商品价格
2. 金额结算时，修改结算价格

首先修改商品价格
我选择第一个最贵的

点击查看详情后，将商品提交到购物车

这时对数据包进行拦截

这个url为cart的请求就是提交商品的请求，将price修改为90

发生了跳转，说明可能成功了
到购物车查看
这里的total就修改掉了

提交即可完成实验

然后接着这步验证能否修改总金额
点击place order后抓包
并没有金额相关的参数

在身份验证漏洞的2fa验证逻辑缺陷实验中，也存在类似的问题，当正常用户wiener登录后，cookie中会将verify的值设置为用户名wiener.而攻击者可以修改wiener，替换为carlos，从而绕过第一步的登录过程，再爆破出carlos的2fa验证码，从而以carlos的身份登录

未能处理非常规输入

软件逻辑的目的之一是将用户输入限制为符合业务规则的值。
例如，应用程序可能被设计为接受某种数据类型的任意值，但逻辑会决定从业务角度来看该值是否可接受。许多应用程序的逻辑中都包含数字限制。这可能包括用于管理库存、应用预算限制、触发供应链阶段等的限制。

让我们以网上商店为例。在订购产品时，用户通常会指定他们想要订购的数量。虽然理论上任何整数都是有效的输入，但业务逻辑可能会阻止用户订购超过当前库存的数量。

要实现这样的规则，开发人员需要预测所有可能出现的情况，并将处理这些情况的方法纳入应用程序逻辑中。换句话说，他们需要告诉应用程序是否应该允许给定的输入，以及如何根据各种条件做出反应。如果没有明确的逻辑来处理给定的情况，就会导致意想不到的、可能被利用的行为。

例如，数字数据类型可能接受负值。根据相关功能，业务逻辑可能不允许这样做。但是，如果应用程序不执行适当的服务器端验证并拒绝这种输入，攻击者就可能传递负值并诱发不希望发生的行为。

例如银行之间的转账功能，该功能肯定会在完成转账之前检查发送方是否有足够的资金，用代码解释如下

$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();

if ($transferAmount <= $currentBalance) {
  // Complete the transfer
} else {
  // Block the transfer: insufficient funds
}

但是，如果逻辑没有充分防止用户在金额参数中提供负值，攻击者就可能利用这一点绕过余额检查并向 "错误 "方向转移资金。如果攻击者向受害者的账户发送-1000 美元，结果可能是从受害者那里收到 1000 美元。逻辑总是会评估 -1000 小于当前余额并批准转账。
像这样简单的逻辑缺陷如果出现在正确的功能中，就会造成严重后果。它们在开发和测试过程中也很容易被忽略，特别是考虑到这类输入可能会被 Web 界面上的客户端控件阻止。

测试应用程序时，应使用 Burp Proxy 和 Repeater 等工具尝试提交非常规值。特别是，在合法用户不太可能输入的范围内尝试输入。这包括异常高或异常低的数字输入，以及基于文本字段的异常长字符串。您甚至可以尝试意想不到的数据类型。通过观察应用程序的响应，您应该尝试回答以下问题：
数据是否有任何限制？
达到这些限制时会发生什么？
是否对输入进行了转换或规范化？

这可能会暴露出输入验证的薄弱环节，使您能够以不寻常的方式操作应用程序。请记住，如果您发现目标网站上有一个表单无法安全地处理非常规输入，那么其他表单也很可能存在同样的问题。

下面完成三个实验

Lab: High-level logic vulnerability

在这个实验中，要求我们买一件夹克，但登陆后只有100美元。
实验提示了这里的用户输入是不严谨的
那么现在的思路是 1、是修改夹克的价格 2、是修改总金额 3、是查看商品的数量是否为负数，利用其他商品负数量的金额来抵消

第一种和第二种在上个实验已经验证了，现在不可行
这里首先将夹克添加到购物车，然后选择另一个商品，计算抵消金额需要的数量，然后在提交这个商品时抓包，修改数据包中的quantity为负数量，发送即可

这时就可以在购物车看到情况了

然后付款即可

Lab: Low-level logic flaw

在这个实验中,修改quantity为负数是不允许的，后台检测到商品总数量为负数时，会将购物车中的商品移除

上述操作发送后，购物车为出现productID=1也就是夹克商品的信息
现在商品价格，数量，购物车总金额都无法修改

那么就有一种新的思路，通过不断添加商品数量，来扩大金额，直至存储这个金额的数据类型溢出
例如这个实验中的金额可能以int型存储，那么可以通过增加商品数量，时购物车总金额达到负数，然后用其他商品的价格来弥补

抓取提交商品1的数据包，商品数量quantity最大为99，所以需要通过inturder不断重复发包，直到溢出
增加一个null payload


然后开始爆破，爆破期间不断刷新购物车，注意购物金额，为负数时说明溢出了，这时停止爆破
然后选择另一个商品，这里我选择了商品2

这里的payload生成数量要选择一个合适的数

然后开始爆破，爆破完后观察购物车金额，若还是为负数，可以再执行一次，知道购物车金额在余额范围内
这里的quantity数量在数据包中是可以提交负数的，但是后端不允许总数量为负数，可以根据这个在repeater中进行调整，从而调整金额
最后效果如下

Lab: Inconsistent handling of exceptional input

实验要求我们访问管理面板，并删除carlos用户
这个实验要解决两个问题

1. 要注册一个carlos用户
2. 要获得访问管理面板的权限

首先实验没有给出管理面板的url，这里就需要我们自己去找出url
点击 目标 -> 站点地图，选中网站

右键 -> 相关工具 -> 发现内容

然后点击会话

这样就可以获取网站下的目录文件，与dirsearch和dirbuster的功能相似
之后点击站点地图，就可以看到了admin目录

访问后，告诉我们只允许以DontWannaCry身份用户登录

然后来到注册页，提示了如果为DontWannaCry工作，请用@dontwannacry邮箱注册

填写一个注册信息

让我们去邮箱查看注册链接

去到邮件服务器后，这个邮箱不是dontwannacry邮箱

那这里要获得邮箱链接，就要以实验环境的邮件服务器注册，但是登录管理面板要使用@dontwannacry邮箱注册
那么是否可以通过测试出后端处理邮箱的机制，达成目的
在注册数据包中，通过加长邮箱长度，提交数据时，邮箱长度是不受限制的

这里我们可以将邮箱的长度写的足够大
提交后去邮件服务器查看

点击链接，告诉我们注册成功，然后我们以这个账号登录

发现我们的邮箱长度被截断了
通过比较，截断前长度为341个字符，截断后为255个字符，且从后面开始截断

但是提交注册请求时，邮箱没有截断，可以正常发送的邮件服务器

那么可以通过截断机制，来构造邮箱名，使其能够发送到实验中的邮件服务器，然后被截断为@dontwannacry.com结尾的邮箱
@dontwannacry.com的字符串长度为17
那么前面再构造238长度的字符串就满足截断条件
那么可以将邮箱写为

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@dontwannacry.com.exploit-0a46004e03982a3f86220cd7014400d7.exploit-server.net

提交请求

邮件服务器也收到了注册链接

完成注册后登录
就发现截断成功了，并出现了一个admin panel面板

访问后删除carlos用户即可

对用户行为做出错误的假设

逻辑漏洞最常见的原因之一是对用户行为做出错误的假设。如果开发人员没有考虑到违反这些假设的潜在危险情况，就会导致各种各样的问题。

受信任的用户并不总是可信的

应用程序看似安全，是因为它们实施了看似强大的措施来执行业务规则。不幸的是，有些应用程序会错误地认为，只要通过了这些严格的控制，用户及其数据就可以无限期地得到信任。这可能导致从那时起对相同控制措施的执行相对松懈。

如果业务规则和安全措施在整个应用程序中的应用不一致，就会导致潜在的危险漏洞，从而被攻击者利用。

Lab: Inconsistent security controls
首先进入邮件服务器获取邮件地址

然后以这个邮件地址注册账号
注册成功后，邮件服务器出现如下链接

点击跳转后即可注册成功
在首页点击my account

有一个更新邮件的功能，更新邮件为@dontwannacry.com

更新后就出现了管理员面板

进入管理员面板后删除carlos即可

用户不会总是提供必填项

一个错误的逻辑是，用户总是会为必填输入字段提供值。浏览器可能会阻止普通用户提交没有必填输入项的表单，但我们知道，攻击者可以在传输过程中篡改参数。这甚至可以扩展到完全删除参数。

在同一服务器端脚本实现多个功能的情况下，这是一个特殊问题。在这种情况下，特定参数的存在与否可能会决定执行哪段代码。删除参数值可能会允许攻击者访问本应无法访问的代码路径。

在探测逻辑缺陷时，应尝试依次删除每个参数，并观察这对响应的影响。

应该确保

• 每次只删除一个参数，以确保所有相关代码路径都能访问到。
• 尝试删除参数名和值。服务器通常会以不同的方式处理这两种情况。
• 跟踪多阶段流程直至完成。有时，在一个步骤中篡改参数会对工作流中更远的另一个步骤产生影响。

这适用于 URL 和 POST 参数，但也别忘了检查 cookies。这个简单的过程可以揭示一些可能会被利用的怪异应用程序行为。

Lab: Weak isolation on dual-use endpoint

抓取修改密码的数据包

尝试删除currentpassword参数，注意不要删除前面的&符号

密码修改成功了
这也说明了修改密码的用户依靠参数username确定
将username替换为管理员

提交后仍可成功修改密码
然后以这个身份登录，在admin panel修改carlos即可

在前面的身份验证漏洞，密码重置逻辑错误实验中，我们通过先删除token参数，然后删除token值来绕过 2fa验证token的限制
身份验证漏洞实验

用户不会总是按照预定顺序操作

许多事务都依赖于由一系列步骤组成的预定义工作流程。网络界面通常会引导用户完成这一流程，每次完成当前步骤后，都会带他们进入工作流程的下一步。然而，攻击者并不一定会遵守这一预定顺序。如果不考虑这种可能性，就可能导致危险的漏洞，而利用这些漏洞可能相对简单。

例如，许多实施双因素身份验证（2FA）的网站要求用户先在一个页面上登录，然后再在另一个页面上输入验证码。如果假定用户总是会完成这一过程，并因此不验证他们是否完成了这一过程，攻击者就可能完全绕过 2FA 步骤。
这里参考身份验证漏洞实验中的2fa简单绕过
身份验证漏洞实验

即使是在相同的工作流程或功能中，假设事件发生的顺序也会导致各种各样的问题。使用 Burp Proxy 和 Repeater 等工具，攻击者一旦看到一个请求，就可以随意重放，并使用强制浏览以任何顺序与服务器进行交互。这样，攻击者就能在应用程序处于意外状态时完成不同的操作。

要识别此类漏洞，应使用强制浏览以意外顺序提交请求。例如，您可能会跳过某些步骤，多次访问一个步骤，返回到较早的步骤，等等。注意不同步骤的访问方式。虽然您通常只需向特定 URL 提交 GET 或 POST 请求，但有时您可以通过向同一 URL 提交不同的参数集来访问步骤。与所有逻辑缺陷一样，请尝试确定开发人员做出了哪些假设，以及攻击面在哪里。然后，您可以寻找违反这些假设的方法。

请注意，这种测试通常会导致异常，因为预期变量具有空值或未初始化值。以部分定义或不一致的状态到达某个位置，也可能导致应用程序发出错误。在这种情况下，一定要密切关注遇到的任何错误信息或调试信息。这些可能是宝贵的信息披露来源，可以帮助您对攻击进行微调，并了解有关后端行为的关键细节。

Lab: Insufficient workflow validation

实验要求任意购买商品，指定了商品为夹克
首先抓包分析
将夹克添加到购物车，并付款后的数据包如下
后端检查后，进行重定向，带参数err就表示支付失败

那么成功付款的数据包是如何的？
选择一个可以正常支付的商品，付款抓包

可以看到重定向了到/cart/order-confirmation?order-confirmed=true
重定向的数据包后为

并且原始数据包中只用csrf-token校验，没有其他的验证参数
那么在商品购物车页，直接重放支付成功的数据包，就可以实现任意商品购买
购物车添加夹克

在repeater中重放数据包即可

Lab: Authentication bypass via flawed state machine

本实验是通过旁路绕过身份验证，要求删除账号carlos

首先尝试直接访问admin面板
burp目标内容发现 – > url访问

要求以管理员身份登录

接着测试登录功能
以wiener测试账号登录，进入后有一个角色选择页面，只有两种角色

尝试抓包修改

user修改为adminnistrator

这里的role可以做一个fuzz点，尝试各种管理员名称
发送后为出现管理员面板
试着访问管理员页
还是告知不是管理员用户

结合实验的主题，用户不会按照预定顺序操作
分析数据包，登录后，302重定向到role-selector


那么在重定向到role-selector后，后端可能就已经判断用户组了
那么现在的思路是不让其跳转，那就登录后丢弃该数据包，然后访问admin
放行第一个登录请求

丢弃role-selector

然后访问url – https://0ad500e9042e408083b3555f007b00c4.web-security-academy.net/admin
就出现管理员面板了
删除carlos即可

特定领域的缺陷

在许多情况下，您会遇到特定于业务领域或网站目的的逻辑缺陷。

在查找逻辑缺陷时，网上商店的折扣功能是一个典型的攻击面。对于攻击者来说，这可能是一座潜在的金矿，在折扣应用方式中会出现各种基本逻辑缺陷。

例如，一家网上商店为超过 1000 美元的订单提供 10% 的折扣。如果业务逻辑未能检查折扣应用后订单是否发生更改，就很容易被滥用。在这种情况下，攻击者可以简单地在购物车中添加商品，直到达到 1000 美元的门槛，然后在下订单前删除不想要的商品。这样，即使他们的订单不再符合预期标准，他们也能获得折扣。

您应特别注意根据用户操作确定的标准调整价格或其他敏感值的任何情况。尝试了解应用程序使用什么算法进行这些调整，以及在什么时候进行这些调整。这通常需要操纵应用程序，使其处于所应用的调整与开发人员所希望的原始标准不一致的状态。

要识别这些漏洞，你需要仔细思考攻击者可能会达到什么目的，并尝试找到使用所提供功能实现目标的不同方法。这可能需要一定程度的特定领域知识，以了解在特定情况下什么可能是有利的。举个简单的例子，你需要了解社交媒体，才能理解强迫大量用户关注你的好处。

如果没有这方面的知识，你可能会因为没有意识到潜在的连锁反应而放弃危险的行为。同样，你也可能会费尽心思去发现两个功能是如何以一种有害的方式结合在一起的。为简单起见，本主题中使用的示例针对的是所有用户都熟悉的领域，即网上商店。但是，无论您是在进行漏洞赏金猎取、五项测试，甚至只是一个试图编写更安全代码的开发人员，您都可能会在某些时候遇到来自不太熟悉的领域的应用程序。在这种情况下，你应该尽可能多地阅读文档，并在可能的情况下，与该领域的主题专家交流，以获得他们的见解。这听起来似乎很费事，但越是晦涩难懂的领域，其他测试人员就越有可能漏掉很多错误。

Lab: Flawed enforcement of business rules

这个实验有两个优惠码
一个是首页
还有一个在页面底部填写邮箱后可以获得
在购物车页可以添加优惠码获取优惠
当使用第一个优惠码后，再使用一次

然后使用第二个

这时再使用第一个，发现奏效了

这样就可以交替使用优惠券，从而重复
最终使价格在购买范围内即可

Lab: Infinite money logic flaw

无限金钱漏洞
漏洞场景为
用户输入邮箱 – > 获得优惠券码
用户购买礼品卡 giftcard + 使用优惠券码 --> 获得礼品卡兑换码
在用户信息页兑换礼品卡 --> 余额增加10$

接下来我么就是要重复这一过程，从而无限刷新账户余额

Lab: Authentication bypass via encryption oracle

本次实验的难点在于cookie加密机制的分析
登录功能中勾选stayed-log-in看到cookie是加密的
在评论功能中，存在一个漏洞机制

输入正确的邮件地址时，数据包如下

而当输入不正确的邮件格式时，返回中会修改cookie

notification=TzHx%2f1GBUdcCqj28ubcCCStXTAr12J5L%2fS7oNE2Jq6s%3d

notification是通知的意思
而在重定向到的url中，发现了与notification相关的参数，存在一个notification-header

且该响应的cookie中，notification为空了

那么就有可能后端检测到了不正确的邮件格式后，将这个不正确的邮件值加密，放在cookie中，然后从cookie中的notification解密

知道这一机制后，可以利用这一机制当做一个加解密工具
将提交评论的数据包和 随后的 GET /post?postId=x（包含通知 cookie）数据包发送到重放器，分别命名为enc，dec，充当加密/解密功能
我们在dec数据包中，将stay-logged-in的值放在notification中，让其帮我们解密

可以看到解密后是用户名+一串数字的结构
这个数字就是时间戳
那么接下来构造邮箱,放在enc数据包中

administrator:timestamp

将得到的notification值放在dec数据包中解密

这时就与前面的解密stay-logged-in不同
携带了一个前缀prefix –Invalid email address:
那么我们可以通过构造一个特殊的字符串，使其解密后不带前缀，然后将其放到stay-logged-in中，从而实现任意用户登录

首先前缀Invalid email address: 的长度为23个字符

将notification的值发送到decoder中
先进行url解码
然后进行base64解码
并选择前23个字节，然后删除

将删除后的结果按逆步骤编码，然后将结果放到dec数据包中

出现了错误信息
使用填充密码解密时，输入长度必须是 16 的倍数
那么这个加密算法就可能使用了块加密算法
那么接下来就是调整长度
既然要是16的倍数，那么我们可以删除32个字符，那么在administeror前需要填充九个字符
填充后如下

xxxxxxxxxadministrator:your-timestamp

加密此输入，并使用解密请求测试是否能成功解密。
以我的数据为例

xxxxxxxxxadministrator:1708620912
enc-->
TzHx%2f1GBUdcCqj28ubcCCdgTqSMFf%2fnw8wg3y4bkx10kVYfLfj8U6LEguxDT5yT%2b7GQkpQA3GpBRDjD0oF3k5A%3d%3d

按照前面步骤解码

删除前32个字符

然后再编码回来

发送到dec解密
这里我们就将前缀消除了

构造好管理员cookie后，再代理历史中找到登录操作后的认证请求

发送到repeater后
替换stay-logged-in，并删除url中的?id=wiener

即可成功登录，再浏览器中打开后，进入管理员面板删除账户Carlos即可