点击蓝字
关注我们
一次验证码轰炸的发现—条件竞争 看着网站挺好怼的，于是就看了看它的验证码这一块
相关实验推荐：“竞争条件”发生在多个线程同时访问同一个共享代码、变量、文件等没有进行锁操作或者同步操作的场景中。
https://www.hetianlab.com/expc.do?ec=ECID39ee-9db2-47bc-9fa1-29150748681b&pk_campaign=weixin-wemedia#stu
先看看它的正常的响应包
重复发送，做了防护。
使用常见的手法进行绕过
1.换行 –失败
2.加空格或者 + 号 失败
body=contact%3D%2013888888888%20%26type%3Dgetverifycode%26cmd%3D-1&data=&yzm=&encrypt=falsebody=contact%3D+13888888888%20%26type%3Dgetverifycode%26cmd%3D-1&data=&yzm=&encrypt=false
….3.加分号， 加逗号 --失败
body=contact%3D13888888888;13888888888%26type%3Dgetverifycode%26cmd%3D-1&data=&yzm=&encrypt=false差不多可以确定是电话后面加的是非空格字符的是不会发送，直接显示手机号错误，
4.加+86 或者86
5.在常见思路都失败的情况下，我想到可不可以用数据库的空白字符去干扰它….. 有那么多空白字符 试试呗…
然后当我把线程放到30的时候，重新再跑的时候，进一步确认了这样一个问题
问题就出来了。按照刚才的思路，不可能是有两个验证码会发送成功的，如果发送成功，一定就是它的业务出现了问题… 那么到底是哪里出了问题了呢？
1.最开始的时候，思考的方向出现了问题，我首先想到的是会不会是高并发的一个问题。
然后去百度，寻找到这样一个线索 感谢这位师傅的文章
可以看到，高并发漏洞应该是两个不同的操作，从而导致的问题
2.然后又跑去问团队的大师傅，大师傅给了一个提示
说实话，有往条件竞争这一块去想。。但是想到的是条件竞争的话，感觉是在上传这一块， 所以，但长见识了！验证码也可以条件竞争。找个时间想想，其他漏洞会不会存在这有条件竞争…
3.新的问题又出来的 怎么去验证这样一个问题是条件竞争… 肯定不能重复这个%00 相当于直接重放这个请求包即可
把线程开到50
成功验证了，主要为了验证这个问题存在即可，不一定要把线程开得很大，把别人网站搞崩完了
总结：
1.原来验证码可以进行条件竞争！
2.挖掘的每一个过程，都需要明白大致得流程，这样才能进步，我们要明白为什么，怎么操作。
之所以认为是条件竞争，是因为一个大师傅这样认为过…
原创稿件征集
征集原创技术文章中，欢迎投递
投稿邮箱：edu@antvsion.com
文章类型：黑客极客技术、信息安全热点安全研究分析等安全相关
通过审核并发布能收获200-800元不等的稿酬。
更多详情，点我查看！
体验靶场实操，戳“阅读原文”体验
