不可思议但又无处不在的漏洞，WEB安全基础入门—业务逻辑漏洞

欢迎关注订阅专栏！
WEB安全系列包括如下三个专栏：

• 《WEB安全基础-服务器端漏洞》
• 《WEB安全基础-客户端漏洞》
• 《WEB安全高级-综合利用》

知识点全面细致，逻辑清晰、结合实战，并配有大量练习靶场，让你读一篇、练一篇，掌握一篇，在学习路上事半功倍，少走弯路！
欢迎关注订阅专栏！

• 专栏文章追求对知识点的全面总结，逻辑严密，方便学习掌握。力求做到看完一篇文章，掌握一类漏洞知识。让读者简洁高效的掌握WEB安全知识框架，推开入门深造的大门。
• 绝不为了追求文章数量，彰显内容丰富而故意拆散相关知识点。避免读者沉迷在无尽的技巧中而迷失进阶的道路！本系列的目标是授之以渔，而不仅仅是技巧的堆砌。
• 每篇文章均配有大量靶场，点击文章中靶场名即可跳转练习（靶场在网站注册即可免费使用）。
• 欢迎订阅专栏！建议学完两个基础专栏，再学习高级哦~

1. 什么是业务逻辑漏洞

是业务逻辑在设计或具体实现上的缺陷导致攻击者可以利用的漏洞。攻击者通常使程序处于不寻常的“状态”，导致业务逻辑不能正确处理，在这种情况下利用现成的逻辑或函数达成恶意的目标。
该类漏洞使用自动漏洞扫描器检测很难发现。因此，逻辑缺陷通常是测试人员的一个很好的目标。

业务逻辑漏洞，往往对技术要求不高，但是需要测试人员有异想天开的脑洞，本文可重点看4.漏洞实例，拓宽下脑洞，见识下一个个不可思议，不可理喻的业务逻辑漏洞。

2. 漏洞产生的原因

• 设计和开发人员错误的预估用户的行为，导致用户实际操作与程序设计逻辑偏离。

简单举例：开发人员认为用户都是通过浏览器进行交互访问，很多验证可能仅依靠客户端的验证。而没有考虑很多“用户”使用拦截代理进行各种操作。这就造成了大量验证被绕过，数据报文内容可能被任意篡改的情况。

• 程序功能过于复杂，没有一个团队能完整了解所有功能具体实现，导致了错误的预估其他功能，从而产生偏差，易被攻击者利用。

一个开发小组错误的认为另一功能产生的输入数据是可靠的而未进行全面验证。而那个功能开发团队却以为后续处理会进行验证和过滤…

3. 漏洞实际利用

1. 错误的信任客户端验证

一个根本性的错误假设是，用户只会通过提供的Web界面与应用程序交互。这就像一眼看到未来的“美女老婆”，作为优质青年怎么可能旁观呢，早就各种套路深入交流了。现实如此，网络世界更是这般。

例题1、2

2. 非常规输入数据不能被正确处理

应用程序往往在管理库存、应用预算限制、触发供应链阶段对用户数据的内容进行验证，判断是否符合各项规则条件限制，最终决定能否接受。开发人员要针对各种可能的输入类型和场景进行验证功能的实现。
比如，对数量类型的输入，有没有考虑负数的情况呢。比如下面的验证逻辑代码

$transferAmount = $_POST['amount'];$currentBalance = $user->getBalance();if ($transferAmount <= $currentBalance) {// Complete the transfer} else {// Block the transfer: insufficient funds}

负数造成的影响将是灾难性的。特别是前端有了过滤，而后端恰巧缺失了这一类过滤，会造成问题难以在测试阶段被尽早发现出来。
测试输入数据三问，这有助于尽早发现漏洞：

• 数据限制条件是什么
• 到达极限条件后，会发生什么
• 输入的数据有被替换或者标准化吗

例题3、4、5

3. 设计时错误预测用户操作

1. 受信任用户永远受信任，不再进行后续验证。

例题6

2. 用户可以绕过前端强制必填字段，而后端对此没有验证

删除参数查看系统有无任何异常响应，力争跳转至不同的判断路径中

• 一次只删除一个参数，确保每个代码路径都能触发到
• 分别删除参数名和值，服务器通常会产生不同的处理方式
• 遵循多流程的处理直至完成，有时一个环节的参数（或cookie）改变，会极大影响到后续步骤。

例题 7、8

3. 用户操作未按流程顺序执行

正常用户会按照程序指引一步一步顺序完成，但是攻击者往往会跳过某些步骤，程序若未验证，则造成漏洞。

例题 9、10、11

4. 特定领域的业务漏洞

网站某一项特定领域的业务逻辑漏洞，

• 营销促销领域，打折劵的使用或凑单价格满足条件金额会突然变化的情况，都是漏洞高发区
• 社交媒体粉丝和点赞数，社交媒体业务逻辑衍生的漏洞等

例题12、13

5. 功能实现明文-加密输出途径

当用户可控制的输入被加密，然后以某种方式向用户提供所产生的密文时，可能会发生危险的情况。攻击者可以使用此输入来使用正确的算法和非对称密钥加密任意数据。
攻击者可定制攻击荷载内容，利用此处功能点，生成符合网站要求的加密cookie

例题 14

4. 漏洞实例

1. 对客户端控件的过度信任（Excessive trust in client-side controls）

• 目标

  购买价格昂贵的Lightweight l33t leather jacket

测试账户：wiener:peter

• 解题思路

添加产品到购物车环节，数据包中发现，可任意更改价格

POST /cart HTTP/1.1Host: ac081f251eda4b10c0583dbc00470032.web-security-academy.netproductId=1&redir=PRODUCT&quantity=1&price=1

2. 双因素认证逻辑缺陷（2FA broken logic）

• 目标

  登陆目标账户carlos

测试账户：wiener:peter

• 解题思路

此题正常登陆逻辑为（攻击思路见注释框）

1. 输入账号密码，通过后生成验证码发到登录人邮箱`POST /login``GET /login2`

修改数据包verity值，确保系统已为carlos账户生成有效的验证码。

GET /login2 HTTP/1.1Host: ac9f1fea1f713b13c0ca44ec0086002c.web-security-academy.netCookie: session=afxODj6T2amYajgf2qNNCB6gKQLSaI0G; verify=carlos

2. 输入验证码`POST /login2`

使用Burp爆破模块 对验证码进行爆破（规则很简单，0000~9999遍历爆破）

3. 完成登陆

3. 高级逻辑漏洞（High-level logic vulnerability）

• 目标

  购买价格昂贵的Lightweight l33t leather jacket

测试账户：wiener:peter

• 解题思路

此题开发人员忘记设计验证数量为负的情况，只是验证了总金额不能为负数。本人账户有100.所以最终结账金额控制在（0~100）即可。其他一样修改数据包即可

4. 低级逻辑缺陷（Low-level logic flaw）

• 目标

  购买价格昂贵的Lightweight l33t leather jacket

测试账户：wiener:peter

• 解题思路

改题思路很简单，购买总金额在超过极限大之后，突然反转，从负数开始，需要利用爆破模式，回到0。再搭配其他产品控制100以内。

5. 对异常输入的处理不一致（Inconsistent handling of exceptional input）

• 目标

获取administrator的权限，并删除carlos

• 解题思路

这道题思路比较巧妙，可记录下来备用。

1. 注册时邮箱长度不设限，但是注册成功后数据库记录的有限长度仅为255位。
2. 同时发现admin状态只有单位邮箱注册的人员才能访问@dontwannacry.com
3. 所以构造一个长度远超255位的邮箱，此邮箱为攻击者能收到邮件的邮箱。

many_string@dontwannacry.com.攻击者邮箱后缀保证在m处正好是255字节。
这样注册时攻击者能正常收到邮件获取验证连接。应用数据库却已单位邮箱形式存到数据库。从而使攻击者获取了单位admin权限

6. 不一致的安全控制（Inconsistent security controls）

• 目标

获取administrator的权限，并删除carlos

• 解题思路

此题问题出现在账户页更换邮箱未做验证，正常用户可更换为特定单位邮箱，导致获取admin权限

7. 两用终端上的弱隔离（Weak isolation on dual-use endpoint）

• 目标

获取administrator的权限，并删除carlos
测试账户wiener:peter

• 解题思路
  1. 熟悉流程，发现账户页有修改密码的功能，抓取数据包如下

POST /my-account/change-password HTTP/1.1Host: ac8d1ff71e005690c0010f4300f00032.web-security-academy.netcsrf=6WiavlTndiXBzv8zpE13UM4R6lGUzCy6&username=wiener&current-password=peter&new-password-1=123&new-password-2=123

2. 修改username=administrator 删除&current-password=peter，新设密码为123
3. 再次发送数据包，登陆administrator，密码已成功修改

8. 密码重置逻辑缺陷（Password reset broken logic）

• 目标

重置账户carlos的密码，并登录其账户
测试账户wiener:peter

• 解题思路

此题用测试账号走一遍流程，经测试发现数据包

POST /forgot-password" />-forgot-password-token=AmG0hPiLCdYdTKba5le0Ywfdt9M7o3MW HTTP/1.1temp-forgot-password-token=AmG0hPiLCdYdTKba5le0Ywfdt9M7o3MW&username=wiener&new-password-1=123&new-password-2=123

经测试去掉token的值，处理依然成功

POST /forgot-password?temp-forgot-password-token= HTTP/1.1temp-forgot-password-token=&username=wiener&new-password-1=123&new-password-2=123

再次正常启动流程,用户名发起carlos密码重置。使用上述数据包完成重置

9. 双因素验证绕过（2FA simple bypass）

• 目标

已经获得目标账户密码：carlos:montoya，但是需绕过双因素验证，访问carlos首页
测试账户wiener:peter

• 解题思路

账号密码验证后，可在输入验证码环节，直接更改url到主页，跳过此环节。

10. 工作流验证不足（Insufficient workflow validation）

• 目标

购买商品”Lightweight l33t leather jacket”
测试账户wiener:peter

• 解题思路

经测试流程发现，流程各环节中，最后一步购买确认可以单独发起。

11. 通过特殊状态绕过身份验证（Authentication bypass via flawed state machine）

• 目标

购买商品”Lightweight l33t leather jacket”
测试账户wiener:peter

• 解题思路

该题在尝试跳过一个步骤时采用，直接拦截数据包,初始/GET就拦截，然后丢弃。浏览器URL栏直接改为首页。

12. 业务规则的执行存在缺陷（Flawed enforcement of business rules）

• 目标

购买商品”Lightweight l33t leather jacket”
测试账户wiener:peter

• 解题思路

  此题最下方还可以填写任意邮箱得到验证码，所以是两个验证码。发现可以交替提交无报错。

13. 无限货币的逻辑缺陷（Infinite money logic flaw）

• 目标

购买商品”Lightweight l33t leather jacket”
测试账户wiener:peter

• 解题思路

网站有兑换币（相当于10元充值卡）购买时花费十元，但是若使用优惠劵后，可多赚3元。重复这个流程指导金额可以购买目标商品即可。（另，自动化可使用Burp的插件）

14. 通过加密-明文绕过身份验证（Authentication bypass via encryption oracle）

• 目标

获取admin权限，删除账户carlos
测试账户wiener:peter

• 解题思路

暂略