这是一次针对某SRC厂商某业务的一个登陆页面的测试

文中相关漏洞现均已修复 提取其中思想精髓 分享给诸位师傅

梅开一度

开局一个登陆框,正常情况下,我随手一个admin/123456打过去。
如果提示“账号不存在”,或者“密码错误”。再立马掏出我祖传的用户遍历及弱口令字典。定向爆破。
但此时提示“账号或密码错误”,就老老实实去注册,走正常流程了。

burp代理开启 记录下所有数据包 并对其中可疑参数记录标记

输入手机号 获取验证码 这时已然收到了真实的验证码
但是为了获取更多的隐藏参数以及尽可能的走全业务逻辑,这里随便输了一个123456 故意让其报错

果然返回验证码错误,但是同时数据包中也返回了正确的验证码

至此,任意用户注册一枚到手,提交到src很快啊,给了三位数的赏金
但我并不满足于此,正所谓,不想挖高危的安服仔不是一个好的白帽子
很自然的想到注册的地方都出问题了,那找回密码的地方呢,是否也同样也存在验证码就回显在响应包中呢?
抱着试一试单车变摩托的心理,尝试却发现返回包直接返回false,尝试将返回包修改为true,仍无法绕过前后端的校验

梅开二度

两周过去后,发现已经修复了,但是返回包的数据修复的很奇怪,删了好多东西,就只剩下一个flag参数了

{"flag":"error"}

同样想当然的去尝试了一下将"error"修改为"success"等,无果
又测试了一遍,还是没问题。看来真的是修复了,但总感觉哪儿还是有问题。

掏出之前保存的数据包,翻回到之前的数据包,对照分析了一下,这次果然有了新的发现

点击收藏 | 18 关注 | 5
登录 后跟帖