这是对某SRC制造商某业务的登录页面的测试,文章的相关漏洞现在正在修复。提取其中思想的精髓,与大家分享。
开始登录框,一般情况下,我会马上打admin/123456。假如提示信息帐户不存在或密码错误。立即取出祖传用户的经验和弱密码字典。方向性爆破。但是,此时提示信息帐户和密码错误,诚实注册,采取正常流程。burp代理记录了所有的数据包,并记录了可疑。
输入手机号码获得认证代码时,已经收到了真正的认证代码,但为了获得更多的隐藏参数和尽可能的业务逻辑,在这里擅自输给123456,故意报告错误。还是回到验证码是错误的,但同时数据包也回到了正确的验证码。到目前为止,任何用户都注册了一张,并提交给src很快。他们给了三位数的奖金,但我对此并不满意。俗话说,不想挖高风险的衣服并不是一顶好白帽子。当然,考虑到注册的地方有问题。恢复密码的地方也有同样的认证代码吗?试着把自行车变成摩托车的心理,试着发现回包直接回到false,试着把回包变成true,但是不能绕过前后端的检查。
两周过去后,我发现已经修复了,但是回包的数据修复很奇怪除了很多东西,只剩下一个flag参数{“flag”:“error”}
当然,试着把“error”修改为“success”等,但是再试一次也没问题。看来真的修复了,但总觉得哪里有问题。取出以前保存的数据包,回到以前的数据包,对照分析,这次还是有了新的发现。好男人,界面直接变了。难怪你觉得应答包哪里不对劲。啪嗒啪嗒,很快,我就把原来的payload放在原来的接口上打了。很快,验证码又回到了应答包。
及时向某SRC提交,这个波浪又给了三位数的奖金。在这里推测如下。因为业务方面害怕直接修改源代码错误会影响正常逻辑,因此备份修改新接口更换旧接口,忘记修改备份旧接口并立即删除,这里bypass也就是结构请求包请求旧接口
因为tips有点小,所以在测试过程中必须有意识地保留和整理重要的数据包。复查时,要看原来的脆弱性触发处是否有新的页面,是否调用了新的接口,是否有旧的接口。是的,用原来的url、接口或exp直接打电话,看看能不能捡到漏洞(当然,这种情况大多是逻辑漏洞吧。
还没有评论,来说两句吧...