​ 逻辑漏洞挖掘|常见小结

1337163122

​ 逻辑漏洞挖掘|常见小结Azjj98 [url=]小白渗透成长之路[/url] 3天前
收录于话题
#逻辑漏洞1
#SRC漏洞挖掘2
逻辑漏洞
因为最近接触的逻辑漏洞挺多的，所以想把自己的个人在实战中的经验总结一下，可能总结的不全，但是都是我自己实战中遇到的。因为逻辑漏洞是那些扫描器扫不出来的，所以挖起来会比较轻松，像那些注入基本都被挖空了。
一丶漏洞介绍业务逻辑漏洞是指由于程序逻辑不严谨或逻辑太复杂，导致一些逻辑分支不能正常处理或处理错误。
二丶常见场景​三丶漏洞情景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）支付类逻辑
1.商品价格修改：在购买商品的时候，通过抓包通过修改商品的价格，即可造成0.01元购买商品。这里修改商品价格的地方很多，加入购物车的时候可以修改，提交订单的时候也可以修改，这个看情况进行修改。
2.商品数量修改：有些开发会对商品的价格进行封装，我们通过修改数据包没法进行修改，但是这里的商品数量可以改为-1，然后我们再选择别的商品，即可造成价格抵扣。这里修改的地方也是加入购物车的时候可以修改，提交订单的时候也可以修改。
3.运费修改：这个跟以上同理，但是有些开发只对商品做了限制，忽略了运费这一点，通过修改运费为负数，即可抵扣商品。
4.支付金额修改：这个就是最后一步支付的时候，可以修改订单的价格，造成低价购买。
四丶总结逻辑漏洞的挖掘其实也是思路拓展的过程
1.测试业务的时候，先了解清楚业务整体流程，可以利用思维导图快速理清各个业务之间的关系也可以通过查看 JS 了解（JS 中可能会存在信息泄漏）
2.重点关注的业务：个人（他人）信息、密码修改（找回）、支付流程、注册流程、需要手机（邮箱）验证的业务

       
•         对每个业务模块进行抓包，分析其中各种请求，注意 特殊参数，很有可能就是这些 特殊参数 决定了业务步骤
  
         
•         抓包重放的过程，需要多次实验，判断是否可以跳过（绕过），如何跳过（绕过），纯数字可以用 数字 + 字母 尝试绕过
  
         
•         返回包中数据的分析，关注特殊字符串和特殊参数
          6.综上所述，业务流程需同时结合 HTTP/HTTPS 请求分析，关注重点在各种可以用于区别的参数，绕过必要验证，跳过业务步骤。
  
  

​