1、容易忽略的低危漏洞以及延伸利用
一、容易忽略的低危漏洞以及延伸利用
在挖洞的过程当中，比如我们碰到信息泄露漏洞，但是我们不知道这个是信息泄露；或者说我们碰到一个xss，我们不会利用，只能弹个窗，比如反射型的xss，像这种都是低危漏洞，我们有可能把低危漏洞变废为宝
短息轰炸漏洞
像有时候SRC会在节假日搞活动，这个时候，我们就可以挖一些低危漏洞，拿一些奖品，例如url跳转、反射型XSS（有些平台还不收）、轻危的信息泄露、短信轰炸、邮箱轰炸，危害不大的越权、查询报错、页面的信息泄露等
1、短信轰炸漏洞是什么?
短信轰炸漏洞一般分为两种
1.对一个手机号码轰炸n次 (纵向轰炸)
2.对单个手机号码做了接收验证次数，但是可以对不同手机号发送短信无次数限制 (横向轰炸，收不收要看厂商，大概率会忽略)
短信资源的浪费，不管你是纵向的、横向的，都是属于浪费企业的资源，发一条短息是会浪费企业资源的
做为白帽子我们挖洞是看漏洞的危害，做为甲方关注的是跟钱有关的

像有时候，我们在测试短信轰炸漏洞的时候，会发现响应包里面会直接提供给我们验证码或者说直接修改type的code值，然后在发送看一下能不能绕过；在手机号后面前面加个空格、字符、双写手机号（133333,13333），看一下能不能绕过正则；在来一个手机号参数，就比如下面这样子
param={“phoneNumber”:“13333333333”,“phoneNumber”:“13333333333”,“type”:200}
也能够造成绕过；对type进行双写；添加一个值X-Forward-For:127.0.0.1，对.1进行遍历然后进行尝试；加一些干扰的字段，在type后面加一些其它功能点的字段，也会造成干扰；改变请求的方法，把post改成get；
如果尝试这些方法都不能，那可能人家就是做了验证了
在登录口，我们可以挖万能验证码（六个一样的数字，123456）、（系统内置，程序员在系统上线的时候，没有把测试环境的接口给删掉）、SQL注入的万能密码（不同的脚本.asp、.jsp，这种都是有对应的万能密码，google搜一下都是有的）
可能造成一些注入，在用户名和密码都有可能SQL注入；验证码方面可能会有验证码回显漏洞，直接出现在验证码的字段里、在cookie里，有时候是以加密的形式出现，要对验证码的相关参数敏感，verify
如果我们对验证码的功能进行抓包，如果没抓到，说明他是前端判断，那么默认的密码一定是写在前端的js文件里，所以你去翻JS文件，你就可以找到密码
2、信息泄露漏洞–spring
直接访问以下几个路由，验证漏洞是否存在：
/api-docs
/v2/api-docs
/swagger-ui.htm
一些可能会遇到的接口路由变形：
/api.html
/sw/swagger-ui.html
/api/swagger-ui.html
/template/swagger-ui.html
/spring-security-rest/api/swagger-ui.htm
/spring-security-oauth-resource/swagger-ui.htm
正常情况下spring接口是不能对外访问的，一般情况下是研发在内部测试的时候，会把这些接口给调式出来，方便研发人员和同事做一些交接
https://xxx.com/swagger-resources
用默认的字典去扫，可以看到是没有任何敏感信息的
直接得到的是这个信息
[“name”:“default”,“location”:”/–internal–/swgr",“swaggerVersion”:“2.0”]
直接拼接location参数即可
https://xxx.com/–internal–/swgr
发现得到一串信息，重点关注paths路径
一个个点进去看，会发现得到敏感信息，又或者去扫描端口，去试一下这些端口，有可能会部署另外一套系统
2、常见逻辑漏洞案例
1、常见逻辑漏洞案例–支付

逻辑漏洞需要的是细心和比较烧脑的，挖逻辑漏洞你要有个产品经理的知识储备，你需要知道这个系统是怎么做的设计，而不是上来就改改id、参数，删一删参数，看几篇文章
在支付的五大流程里，都会出现问题
1、支付漏洞
1、支付漏洞–优惠券
修改优惠券金额，把20改成130，然后记得计算好couponMenoy参数值，140-130=10，把里面的参数都修改好，最终修改结果
（备：看到里面有很多参数不要慌，改关键的参数就可以了）
为了避免扯皮，我们最好是贴上一张支付成功的画面
在购买商品的时候，也会构成一个漏洞，在选择商品的时候直接把价格改了；购买时间，有的商品不定期就会有折扣，然后直接把日期改成有折扣的那一天，例如618、双十二，就可以用那一天的价格去购买商品
通过更改商品的id，结合订单id，开发没有去做一个强绑定的关系，就会造成我还是用这个订单，但是我购买的商品发生了改变
挖漏洞简单的话，是在于你知道这个漏洞是什么，难的话在于你就没有见过这个漏洞，所以说挖漏洞的前提在于，你得知道有这么个漏洞
提交购买信息的时候，平台会给你进一步的确认，我们可以对确认的数据包内容直接做一个更改，改一下商品的价格
2、充值的支付问题
把user_id改成别人的，可以使用BP去批量的跑一下，成功的让别人为我花钱
其他支付技巧
1.修改支付价格
在支付流程中，提交购买信息、确认支付、确认购买的流程中，如果相互之间没有做好验证机制，就有可能出现修改支付价格的漏洞。
在这三个步骤中，可以尝试抓包，修改支付价格，没有必要到最后一步修改。
2.修改支付状态
这个问题是没有对支付状态的值跟实际订单支付状态进行校验，导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功
3.修改购买数量
抓包，尝试修改购买数量，如果修改购买数量后，价格不变，亦或者修改购买数量为负数，如果价格为负数，同样会导致支付问题的产生。
4.修改优惠券、积分
如果优惠券、折扣券、积分等可以换取相应的物品，那么也有可能出现支付漏洞，这个流程与一般支付流程类似，可以尝试挖掘。
新年活动、集赞、转发这些场景都会跟优惠劵、积分有关系
4.修改优惠券金额
具体看优惠券的兑换方式，如果是满减型，那么就尝试修改优惠券的金额、修改商品价格。如果是折扣类型，那么就尝试修改折扣程度。
修改优惠券金额及业务逻辑问题
具体看优惠券的业务逻辑，比如说，如果支付价格为0时，会报错，提示购买失败，这是因为网站后台不允许提交0元的商品购买订单。
修改积分金额
修改积分金额与上面几点类似，同样是抓包判断能不能修改相关信息
5.修改支付接口
比如一些网站支持很多种支付，比如自家的支付工具，第三方的支付工具，然后每个支付接口值不一样，如果逻辑设计不当，当我随便选择一个点击支付时进行抓包，然后修改其支付接口为一个不存在的接口，如果没做好不存在接口相关处理，那么此时就会支付成功。
6.多重替换支付
支付过程中，网站没有验证商品价格和用户的支付价格。首先去产生两个订单，这两个订单商品是不一样的，其价格不一样，如果服务端没有做好这相关的验证，那么在支付的过程当中抓包，修改其订单值为另一个订单值，最后支付，这时就可以用订单一的支付价格买到订单的商品。
7.重复支付
一些交易市场有一类似于试用牌子或者其它，这个试用牌子可以依靠签到获得，而这个牌子的作用可以去试用一些商品，在你进行试用的时候会扣掉你的试用牌子，当你试用完成或者主动取消试用时，试用牌子会返回到账户当中。如果没有进行对订单多重提交的校验，那么就可导致无限制刷牌子，比如，你试用时抓包，然后你每次试用都会产生一个订单号，然后利用刚抓到的数据包进行批量提交，你就可以看到每次提交的订单号不一样，然后这时你再看订单可以看到同一个商品的无数订单，但试用牌子数只扣了你第一个试验时的牌子数，那么这时你申请批量退出试用，那么这么多订单，每退一个就会退相应的牌子数量到账户当中，这就构成了无限制刷的问题。
8.最小额支付
在修改支付价格时，如果没有支付成功或兑换成功，并不能说明该网站不存在支付漏洞。注意网站的最小支付额，网站可能会对此进行校验，小于这个最小支付额，无法购买，也有可能兑换的物品为空。
将支付金额修改为0.01，小于0，就有可能让你支付成功
9.值为最大值支付问题
以前也是看到过相关的例子，一些网站比如你购买商品，这里有2个思路修改值，1是直接修改支付金额值为最大值，比如999999999，或者修改附属值，如优惠卷，积分等为999999999，如果这里逻辑设计有问题，那么其支付全额会变为0。
10.无限制试用
一些网站的一些商品，比如云系列产品支持试用，试用时期一般为7天或者30天，一个账户只能试用一次，试用期间不能再试用，但如果这个试用接口没做好分配那么很容易导致问题的发生。

业务逻辑漏洞和常规漏洞的区别在于，我们这样子操作了会造成什么样的危害，而不是我改了一个东西造成了不一样的结果，我们要描述这个漏洞的危害，就比如我们挖注入一样，什么都不写，有可能会不被认可，当我们挖的是业务逻辑的话，那我们的描写就要更重一些
挖业务逻辑漏洞的话，思路要比较多，在其它的场景也能继续用