两个星期过去了，又是我，又是这个站，又是这个登录框，这次旧的操作界面问题已经解决了，不能通过操作界面直接打验证码了。

没多久，灵机一动，是否会只是这儿校验操作界面和操作界面对应的验证码是否一致，而不是校验手机号码？讲干就干，先用自己的手机号注册，填写手机号码获取验证码，发送验证码后立即将手机修改为手机号码，以便任意注册(非常重要).

此处的验证码是用156xxxx4528收到的验证码填写的，而131xxxxxx号的验证码还没有被获取。按下注册键，真的就成功直接注册了，验证了以上想法的正确性，这儿只验证了验证码操作界面和对应的验证码，没有检查手机号是否为接收到验证码的手机号。有两件事需要思考，当成功产生了一个漏洞。也就是在水平或纵向上扩大结果。

横竖，现在注册手机号和验证码都不能同时验证，如果验证码不能验证，那就批量注册？把移动电话号码的后两位作为变量，批量运行一次也能成功(把两位设为变量，只是为了证明漏洞确实存在，尽量减少对业务的影响)，还是三位数奖金，也是醉了…不甘示弱的安服仔不是好白帽，继续干下去。

纵观世界，很容易想到因为验证码并没有和实际收到的手机号码绑定在一起。那么它在整个账户系统中的对应功能点就可以注册多个哦。对了，还有密码找回来了。这一套在后面也一样。找出密码时，填写手机号码获取验证码，同时使用自己的手机号码进行接收验证码，收到验证码后，将自己的手机号码替换为您要更改密码的号码。SMS验证码与收到的手机号码不一致。Burp截获了上面显示的包，不会释放它。crt+r到repeater模块，将moble修改为您的目标手机号码，并且将目标账户的密码修改成功，在此继续尝试批量问题，问题仍然存在。也就是批量修改用户的登录密码。举个自行车换摩托车的例子，src，冲。但大意是。没有武德，没有耗子尾汁。

曾经：尽可能地走完整个业务逻辑流程，尽管你觉得99.99%的可能性都没有错。最好的办法：在测试中整理出更重要的数据包，揣测业务的修复心理，试着用payload打出原始操作界面。思考漏洞表象产生后的触发原则，进而扩大漏洞的利用面；不折不扣：业务系统中相同漏洞的对应功能触发点可能不止一个。对不一样设备(User-Agent)的浏览请求，可能导致实现相同业务功能的不一样接口。