两个星期过去了,又是我,又是这个站,又是这个登录框,这次旧的操作界面问题已经解决了,不能通过操作界面直接打验证码了。
没多久,灵机一动,是否会只是这儿校验操作界面和操作界面对应的验证码是否一致,而不是校验手机号码?讲干就干,先用自己的手机号注册,填写手机号码获取验证码,发送验证码后立即将手机修改为手机号码,以便任意注册(非常重要).
此处的验证码是用156xxxx4528收到的验证码填写的,而131xxxxxx号的验证码还没有被获取。按下注册键,真的就成功直接注册了,验证了以上想法的正确性,这儿只验证了验证码操作界面和对应的验证码,没有检查手机号是否为接收到验证码的手机号。有两件事需要思考,当成功产生了一个漏洞。也就是在水平或纵向上扩大结果。
横竖,现在注册手机号和验证码都不能同时验证,如果验证码不能验证,那就批量注册?把移动电话号码的后两位作为变量,批量运行一次也能成功(把两位设为变量,只是为了证明漏洞确实存在,尽量减少对业务的影响),还是三位数奖金,也是醉了…不甘示弱的安服仔不是好白帽,继续干下去。
纵观世界,很容易想到因为验证码并没有和实际收到的手机号码绑定在一起。那么它在整个账户系统中的对应功能点就可以注册多个哦。对了,还有密码找回来了。这一套在后面也一样。找出密码时,填写手机号码获取验证码,同时使用自己的手机号码进行接收验证码,收到验证码后,将自己的手机号码替换为您要更改密码的号码。SMS验证码与收到的手机号码不一致。Burp截获了上面显示的包,不会释放它。crt+r到repeater模块,将moble修改为您的目标手机号码,并且将目标账户的密码修改成功,在此继续尝试批量问题,问题仍然存在。也就是批量修改用户的登录密码。举个自行车换摩托车的例子,src,冲。但大意是。没有武德,没有耗子尾汁。
曾经:尽可能地走完整个业务逻辑流程,尽管你觉得99.99%的可能性都没有错。最好的办法:在测试中整理出更重要的数据包,揣测业务的修复心理,试着用payload打出原始操作界面。思考漏洞表象产生后的触发原则,进而扩大漏洞的利用面;不折不扣:业务系统中相同漏洞的对应功能触发点可能不止一个。对不一样设备(User-Agent)的浏览请求,可能导致实现相同业务功能的不一样接口。
还没有评论,来说两句吧...