对一次验证码逻辑问题造成任意密码重置漏洞的总结

lollipop

随笔系列是对在平时工作或者挖洞过程中发现的新思路的总结记录,涉及到工作的内容,信息全部脱敏模糊没得截图。反正我就是菜QWQ。


最近在做安全测试的时候,例行对登陆处功能进行相关测试,在使用Burp的repeater验证短信轰炸时候发现系统限制了发送频率,一分钟只能发三条,但是,三条短信验证码一模一样,我心里一激灵,这种情况,手机验证码的值莫不是获取验证码的请求包中的一个字段决定的?
接下来分析一下repeater里面的请求包,一眼就看出个参数有点不对劲,里面存在一个参数A,后面跟着一串加密后的密文,而且参数名中的某一个单词让我觉得它是用来做效验的,难道是这个参数会决定服务器会返回哪一个手机验证码吗,那就验证下,重新抓取一个获取验证码的请求包,此时我的手机得到了新的验证码,接下来把新的数据包中的参数A全部复制到旧的那个请求包里替换,再次发送,随着手机一声悦耳的提示,手机收到了验证码,果然此时旧数据包中替换了新的A参数以后,获取的就是新的验证码了,那此时基本确定我之前的猜想,参数A的确是决定验证码的值的。
接下来,想想这个有什么用,也就是说只要用同一个参数A,获取到的验证码是一样的,于是我们来到找回密码处,输入一个存在的账号(手机或者身份证),下一步就会向绑定手机号(测试手机号,不是我的)发送验证码并进行确认,此时抓包,拿到获取验证码的请求包中的A参数,使用之前的请求包替换掉A参数后向我自己手机发送验证码,此时我的手机收到的验证码就和账号绑定手机收到的验证码是一样的了,输入验证码验证,bingo,直接进入填写新密码的步骤。完工,下班。
最后,验证码该发送多少是后台的事,前端老哥你就编写个简单的请求就是了,别把后端的事做了,还要挨批。

One thought on “对一次验证码逻辑问题造成任意密码重置漏洞的总结

发表评论

电子邮件地址不会被公开。 必填项已用*标注