看着网站挺好怼的,于是就看了看它的验证码这一块
body=contact%3D%2013888888888%20&type%3Dgetverifycode&cmd%3D-1&data=&yzm=&encrypt=false
body=contact%3D+13888888888%20&type%3Dgetverifycode&cmd%3D-1&data=&yzm=&encrypt=false
….
body=contact%3D13888888888;13888888888&type%3Dgetverifycode&cmd%3D-1&data=&yzm=&encrypt=false
差不多可以确定是电话后面加的是非空格字符的是不会发送,直接显示手机号错误,
5.在常见思路都失败的情况下,我想到可不可以用数据库的空白字符去干扰它…..
有那么多空白字符 试试呗…
然后当我把线程放到30的时候,重新再跑的时候,进一步确认了这样一个问题
问题就出来了。。。按照刚才的思路,不可能是有两个验证码会发送成功的,如果发送成功,一定就是它的业务出现了问题… 那么到底是哪里出了问题了呢???
1.最开始的时候,思考的方向出现了问题,我首先想到的是会不会是高并发的一个问题。。然后去百度,寻找到这样一个线索 感谢这位师傅的文章
可以看到,高并发漏洞应该是两个不同的操作,从而导致的问题
2.然后又跑去问团队的大师傅。大师傅给了一个提示
说实话,有往条件竞争这一块去想。。但是想到的是条件竞争的话,感觉是在上传这一块,
所以,但长见识了!!!验证码也可以条件竞争… 找个时间想想,其他漏洞会不会存在这有条件竞争…
怎么去验证这样一个问题是条件竞争…
坑定不能重复这个%00
相当于直接重放这个请求包即可
把线程开到50
成功验证了。。。。
主要为了验证这个问题存在即可,不一定要把线程开得很大,把别人网站搞崩完犊子了……
总结:
1. 原来验证码可以进行条件竞争!!!
2. 挖掘得每一个过程,都需要明白大致得流程,这样才能进步,我们要明白为什么,怎么操作。加油加油
3. 愿师傅们技术更上一层楼
之所以认为是条件竞争,是因为一个大师傅这样认为过…
最后,谢谢兔哥,十二神等等….和我团队里的各位大师傅… 真正谢谢了….