这是对某SRC制造商某业务的登录页面的测试，文章的相关漏洞现在正在修复。提取其中思想的精髓，与大家分享。

开始登录框，一般情况下，我会马上打admin/123456。假如提示信息帐户不存在或密码错误。立即取出祖传用户的经验和弱密码字典。方向性爆破。但是，此时提示信息帐户和密码错误，诚实注册，采取正常流程。burp代理记录了所有的数据包，并记录了可疑。

输入手机号码获得认证代码时，已经收到了真正的认证代码，但为了获得更多的隐藏参数和尽可能的业务逻辑，在这里擅自输给123456，故意报告错误。还是回到验证码是错误的，但同时数据包也回到了正确的验证码。到目前为止，任何用户都注册了一张，并提交给src很快。他们给了三位数的奖金，但我对此并不满意。俗话说，不想挖高风险的衣服并不是一顶好白帽子。当然，考虑到注册的地方有问题。恢复密码的地方也有同样的认证代码吗？试着把自行车变成摩托车的心理，试着发现回包直接回到false，试着把回包变成true，但是不能绕过前后端的检查。

两周过去后，我发现已经修复了，但是回包的数据修复很奇怪除了很多东西，只剩下一个flag参数{“flag”:“error”}

当然，试着把“error”修改为“success”等，但是再试一次也没问题。看来真的修复了，但总觉得哪里有问题。取出以前保存的数据包，回到以前的数据包，对照分析，这次还是有了新的发现。好男人，界面直接变了。难怪你觉得应答包哪里不对劲。啪嗒啪嗒，很快，我就把原来的payload放在原来的接口上打了。很快，验证码又回到了应答包。

及时向某SRC提交，这个波浪又给了三位数的奖金。在这里推测如下。因为业务方面害怕直接修改源代码错误会影响正常逻辑，因此备份修改新接口更换旧接口，忘记修改备份旧接口并立即删除，这里bypass也就是结构请求包请求旧接口

因为tips有点小，所以在测试过程中必须有意识地保留和整理重要的数据包。复查时，要看原来的脆弱性触发处是否有新的页面，是否调用了新的接口，是否有旧的接口。是的，用原来的url、接口或exp直接打电话，看看能不能捡到漏洞(当然，这种情况大多是逻辑漏洞吧。