| 提示📝：

“业务逻辑"一词仅指定义应用程序操作方式的一组规则。由于这些规则并不总是与企业直接相关，因此相关的漏洞也称为"应用逻辑漏洞"或简单的"逻辑缺陷”。

什么是业务逻辑漏洞

业务逻辑漏洞是：应用程序在设计和实施的时候存在缺陷，允许攻击者诱发意外行为，像是设计的方案被人钻了空子。

通俗理解就是：在编写程序时，只考虑了常规的操作流程，即“当在A情况下，就会出现B这种意外的时候，执行C即可”，但是开发者却没有考虑当用户执行了意料之外的X时会发生什么。这种对于异常情况的欠考虑，最终导致了安全漏洞的产生。

产生原因

1：程序和用户的交互上存在缺陷设计。
譬如：用户支付10000元购买了一台电脑，在下单之前，用户修改了数据包，把商品数量修改成-1，程序没有检查商品数量与价格的合理性，难不成电商还要倒赔用户？

2：设计的系统过于复杂。
即使是开发团队本身也并不完全了解这些缺陷

脑图

有哪些应用场景？哪些危害？

越权

• 水平越权：有多个权限水平相同的用户，从这个用户切换到另一个用户。

一般来说，是通过更换某个ID之类的身份标识，从而使A账户获取（修改、删除）B账号的数据

• 垂直越权：从低权限用户切换到高权限用户

一般来说，是通过低权限身份的账号，发送高权限账号才能有的请求，获得其高权限的操作
​

• 未授权访问：

通过删除请求中的认证信息后重放该请求，依旧可以访问或者完成操作
​

防御方式

1. 前后端同时对用户输入信息进行校验，严双重验证机制
2. 调用功能前验证用户是否有权限调用相关功能
3. 执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限
4. 直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理
5. 永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

支付漏洞

详细内容，参见挖洞技巧：支付漏洞之总结，写的很详细
常见漏洞点：

• 修改支付价格
• 修改支付状态
• 修改购买数量
• 修改附属值
• 修改支付接口
• 多重替换支付
• 重复支付
• 最小额支付
• 值为最大值支付问题
• 越权支付
• 无限制试用
• 修改优惠价

靶机案例

修改支付金额

漏洞出现的原因是程序没有验证用户输入的金额，或者商品数量

以BurpSuite的在线实验室为例：Excessive trust in client-side controls
0：使用在线实验室提供的账号登录页面：wiener:peter
1：打开页面发现自己有100美元，随意选择一个

2：开启抓包，点击“Add to cart”，并把包发送到重放模块，停止抓包

3：此时的购物车

4：接下来就是设定价格，可以设为低于原价，甚至负数，亦或者修改商品数量，看哪种方法可行。
方案1：修改价格为负值，跟踪跳转之后，刷新购物车，购物车空了，钱包金额没变化，说明失败。

方案2：降低商品价格（设为0的话，失败同上），我这里设为20.

发现购物车金额有戏，提交订单

OK，闯关成功

密码找回绕过

内容描述：修改某网站自己的密码，进而控制该网站其他用户的账号思路：注册网站的账号，然后修改密码，在提交密码的页面修改对应的用户名。靶机：win2k8+phpstudy+metinfo攻击机：Burpsuite
参见我之前的文章：业务逻辑漏洞——密码找回绕过

越权

水平越权
计划以lucy的身份水平越权lili
1：lucy登陆系统

2：把lucy修改为lili
3：查看成功

垂直越权
根据提示，猜测应该是pikacu越权admin。

1：pikachu登陆，发现自己只有查看权限

2：管理员登陆，有添加用户权限

3：admin添加新用户，BurpSuite抓包，发送到重放模块，然后停止截包

admin添加了一个新用户haha

4：admin退出登陆，pikachu登陆系统，目的是为了获取pikachu的cookie，保持截断数据包

5：来到重放模块
（1）把cookie换成pikachu的
（2）修改一下新建用户的信息

6：代理模块停止截包
7：pikachu登陆成功，会看到自己添加的用户alice

防御方式

• 对数据进行加密
• 确保开发人员和测试人员足够了解产品
• 提高开发人员的安全意识
• 限制访问IP的访问频率
• 限制验证码的有效时间

参考

Business logic vulnerabilities
[红日安全]Web安全Day6 - 业务逻辑漏洞实战攻防
攻防演练中的业务逻辑漏洞及检测思路
惊险刺激的业务逻辑漏洞
挖洞技巧：支付漏洞之总结
2FA broken logic (Video solution)
第33天：WEB漏洞-逻辑越权之水平垂直越权全解