逻辑漏洞知识点

一、简单介绍

业务逻辑漏洞是指由于程序逻辑不严谨或逻辑太复杂，导致一些逻辑分支不能正常处理或处理错误。在我理解中，逻辑漏洞是指由于程序逻辑输入管控不严，导致程序不能够正常处理或处理错误，一般出现在登录注册、密码找回、信息查看、交易支付金额等。我将所有逻辑漏洞的问题分为前端和后端两个部分，总体思路都是先测试前端再测试后端。在我理解中其实就是能突破规则限制的就是漏洞，像不可修改的通过抓包可以修改了。

二、常见逻辑漏洞区域

登录页面

• 返回凭证暴力破解用户密码
• 验证码登录爆破
• 验证码登录绕过
• Session覆盖
• 任意用户注册

短信轰炸

• 注册覆盖

密码找回

• 任意用户密码重置
• 用户越权访问
• 订单越权查看修改
• 收货地址越权查看修改

支付系统

• 资料越权查看修改
• 换绑手机修改
• 换绑短信轰炸
• 水平垂直越权
• 运费修改
• 商品价格修改
• 商品数量修改
• 支付金额修改
• 优惠券金额修改
• 优惠券数量修改
• 积分修改
• 收货地址选择越权遍历

1.逻辑漏洞高发区域：

个人信息区域、密码修改区域、密码忘记区域、支付区域、手机号区域等

2.逻辑漏洞分类：

验证机制缺陷
会话管理缺陷
权限管理缺陷
业务逻辑缺陷
登录缺陷
支付逻辑缺陷
API乱用
越权访问

越权：

越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。

该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。越权访问漏洞主要分为水平越权访问和垂直越权访问。

水平越权访问漏洞

水平越权访问是一种“基于数据的访问控制”设计缺陷引起的漏洞。由于服务器端在接收到请求数据进行操作时没有判断数据的所属人/所属部门而导致的越权数据访问漏洞。

假设用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问。

垂直越权访问漏洞

垂直越权是一种“基于URL的访问控制”设计缺陷引起的漏洞，又叫做权限提升攻击。

由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

防范措施

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

三、应用场景

（1）登录验证码爆破

有些系统，手机获取验证码的时候，没有对验证码的验证次数进行限制，或者是没有对验证码的有限时间进行限制，就会造成验证码爆破，但是实战中4位的数字验证码还是很容易爆破的，有些6 7 位的就不是很好爆破了，一般src也不会收这些。

（2）凭证返回

这个就很有意思，在一次某人才网漏洞挖掘的时候，发现在获取验证码的地方，抓包，返回的响应包set-Cookie里面直接返回了验证码，直接就可以输入验证码，可以完成任意用户登录，注册，密码找回。有一些还有在登陆或者密码找回的时候会返回密码。

（3）验证码绕过

其实这里不只是验证码，在某些密码找回，或者验证用户凭证的时候，会根据返回的状态码进行校验，假设验证码是正确的，返回的状态码位1，错为2，这里我们就可以通过抓取响应包，修改状态码为1，即可达到验证绕过。知道怎么抓，很简单，就是在Burp里面的Do intercept -> Response to this request。

（4）短信轰炸

造成短信轰炸的原因主要是没有对单个用户获取验证码的次数进行限制，通过Burp抓包，数据包重放就可以造成短信轰炸。

（5）session覆盖

同一浏览器，首先输入自己的账户进行邮箱密码找回，进入邮箱查看链接，接着输入他人账户，进行密码找回，返回刚刚自己的邮箱点击链接，由于 session 覆盖导致了，这个链接成为了修改他人密码的链接，成功修改他人密码

（6）逻辑越权

相同级别（权限）的用户或者同一角色不同的用户之间，可以越权访问、修改或者删除的非法操作，如果出现此漏洞，可能会造成大批量的数据泄漏，严重的甚至会造成用户信息被恶意篡改。

1.订单越权：通过修改URL的订单id值越权查看订单（有些是在POST包中修改）

2.收获地址越权：收货地址这里碰到的还是蛮多的，在收货地址的地方，查看收货地址，有些通过修改address的id值即可查看别人的收货地址，还有越权修改别人的收货地址，这里有一个小套路，假设此站点的收货地址存在xss漏洞，就可以通过修改别人的收货地址打到cookie，这里也算是个组合拳吧。还有就是思路需要灵活，有些开发对会员中心的收货地址进行限制了，但是在提交订单的地方，也是可以越权查看他人的收货地址的。

3.资料修改：这里跟收货地址其实没什么区别，也可以通过xss进行组合拳。

4.其实还有很多越权的方式，

（7）换绑手机，密码重置

这里的思路其实就是后台没有对账号和绑定手机进行校验，我们可以通过抓包修改绑定的手机号码为我们的手机号，即可造成密码重置，或者一些别的操作

（8）支付类逻辑

int的类型的最大值

1.商品价格修改：在购买商品的时候，通过抓包通过修改商品的价格，即可造成0.01元购买商品。这里修改商品价格的地方很多，加入购物车的时候可以修改，提交订单的时候也可以修改，这个看情况进行修改。

2.商品数量修改：有些开发会对商品的价格进行封装，我们通过修改数据包没法进行修改，但是这里的商品数量可以改为-1，然后我们再选择别的商品，即可造成价格抵扣。这里修改的地方也是加入购物车的时候可以修改，提交订单的时候也可以修改。

3.运费修改：这个跟以上同理，但是有些开发只对商品做了限制，忽略了运费这一点，通过修改运费为负数，即可抵扣商品。

4.支付金额修改：这个就是最后一步支付的时候，可以修改订单的价格，造成低价购买。

防御

• 彻底的需求分析：深入理解业务需求和可能的安全隐患。
• 全面的测试：对所有业务逻辑进行综合测试，包括边界情况。
• 用户行为监控：监控异常行为，识别潜在的逻辑漏洞。

修复

• 逻辑重构：重新设计和实施有缺陷的业务逻辑。
• 增强验证：增加额外的输入验证和控制措施。
• 持续监测和改进：定期评估和调整业务逻辑，以应对新的威胁