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

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

梅开一度

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

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

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

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

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

梅开二度

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

{"flag":"error"}

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

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