前言:
这是一篇关于月神 SRC 逻辑漏洞课程的学习笔记,因为我现在没有小钱钱所以买的是某宝的 19 期盗版课,如果后续赚钱了肯定是要支持一手正版的,但是现在嘛,先学吧,当然 b 站也有相关课程只不过需要包月充电
发票漏洞:
取消重开:
开票后查看是否可以申请取消,然后重新开票。申请开票后我们拿这个发票去使用了,这个时候如果服务器没有校验发票已经被使用,允许用户申请取消并重开发票那么这里就存在漏洞
这个漏洞如果存在,就会导致用户可以通过不断申请取消重开来频繁使用发票
参数叠加:
一般情况下发票是根据用户提交的订单号来开具体的金额,如果是直接使用用户提交的参数为发票金额,那可以尝试直接修改金额。这里讲的是使用订单号来确认要开发票的金额,那么我们是不是可以将这个参数叠加使用,比如有两个订单,一个是 100 元,一个是 50 元,正常情况下一起请求时 150 元,但是我抓包将订单号都修改成订单一的订单号,那服务器没有校验的话就会返回 200 金额的发票,这就是参数叠加
越权开票:
这个是我自己看了月神视频后想到的一个思路:
就是有一些平台开发票时给后端传的参数可能并非是订单号 (较长) 而是商品 id 或发票 id,这种 id 可能会比较简短,那么是不是就存在遍历到其他人的 id 然后越权开别人发票的可能,能不能遍历到别人的发票不好说,或者接口泄露,这些我们不一定能碰上,但是我们可以直接使用一个小号买一件商品,然后用这个小号的商品 id 或发票 id 来测试,如果能够将自己的发票和别人的发票一起开,是不是就存在越权漏洞了
前提是能够证明参数的确存在遍历的可能性或者接口存在泄露,不然 src 会忽略
发票类型:
首先要看平台支不支持多个类型的发票,然后如果能够抓包修改发票类型,比如将打车票改成住宿票,这也是会对公司有一定影响的
自定义抬头:
专票是需要认证才能开通,一但认证后是不能随意修改的,不然用户这家公司开一张,那家公司开一张。再加上专票涉及到企业抵税,更不能这样允许用户随意修改,如果用户通过这个漏洞随意修改抬头不是就可以卖自己的发票了,当然平台要支持开专票,然后我们可以那普票来证明这个漏洞的确存在
但是这个漏洞危害也没有那么大,认不认也看 src 了,就像我前面提到的那个越权,的确是一个漏洞,但是如果你无法证明这个参数存在被遍历的可能性或者接口存在泄露可能会不收这个洞,因为你越权开就开呗,反正你无法获取到其他人的 id
从黑灰的角度来讲,这就导致我可以低价去收购一些发票,然后利用这个漏洞将其他人的发票做成自己的来抵税,但是从 src 的角度来讲,就是不管你怎么自定义抬头或者越权开别人的票,反正都是那个票,对平台又没有损失,所以就不收
但是如果能够遍历出这个 id 或者一些接口存在泄露,那这个越权就是完整漏洞了,我可以通过遍历得来的 id 或者泄露的 id 来开到别人的发票,这个危害就大了,只要泄露的信息多或者 id 简短,非常容易遍历出来,那么我明明只买了一个东西却开了 100 多个人买东西的发票,那 src 才会收
强行开票:
正常情况下,用户买了东西,需要开发票,商家是一定要开的,不然就违法了。但是虚拟商品就不用了,因为是虚拟商品所以不支持开发票,但是如果我将能够正常开票的订单号或者 id 替换虚拟商品的订单号或者 id,那么就可能强行开票,商家如果不同意开票申请在一段时间过后就会划扣商品金额 10% 的商家保证金到用户余额
而这个发票是需要商家主动到 app 后台才能去开出的,而用户申请发票可能没有提示,如果商家没有去看这个信息,时间到了平台就会自动划扣保证金到用户余额
同样这个只是一个思路,存在被忽略的可能性,因为商家发现被扣保证金后会向平台反馈,那么平台就知道这个漏洞了,攻击者就可能无法造成大规模危害
并发开票:
这种也是比较常见的漏洞,就是通过并发来开发票,如果成功了,也是一种漏洞