浅谈SRC中关于密码重置漏洞的相关思路

在挖掘漏洞过程中，遇到重置密码时，需要考虑一下几种可能：

1、修改响应包中的状态码。判断后端是否与参数的结果作为最终依据。

2、依据token修改密码，则token不变，替换邮箱。判断对token是否具有严格校验。

3、邮箱链接修改密码，则在向邮箱发送重置密码链接时，修改数据包中的host（指向攻击者服务器，受害者点击邮箱链接时将值回传到攻击者服务器）。判断后端写入链接时是否根据host头。

4、短信/邮箱验证码不变，抓包替换数据包邮箱/手机号。判断对验证码是否有严格把控。

5、验证码四位数可爆破。判断是否有token、频率等安全机制。

5、万能验证码，如：123456，111111，666666，88888等。

在src挖掘过程中，需要根据业务的功能判断、分析可能哪些逻辑缺陷并进行选型。

就比如在忘记密码处，首先滑块验证存在缺陷，并且并没有进行请求频率控制，导致可以对未知账号进行枚举。

经过一系列尝试之后，发现auth_code参数是存在万能验证码的，大概是为了给开发调试及测试人员特地做的一个代码块，后期交付后，开发并没有在后端代码中注释掉该代码块，导致系统继续使用这个存在风险的功能。

1、在挖掘功能点时，需要不断尝试并分析业务，无论是针对特定功能点还是整体业务。逻辑漏洞通常隐藏在这些关键点上，一旦忽略可能导致错失重要发现。

2、在实现短信验证功能时，如手机/邮箱登录、忘记密码、某些需要短信验证等地方；通常会使用万能验证码进行调试和测试，因为开发者和测试人员需要验证接口正常运作，而且频繁调用短信接口繁琐的同时也会耗费费用。因此，常会开辟一个万能验证码代码块的可能性较高。注意到这一点可能会有意向不到的收获。

原文始发于微信公众号（极星信安）：浅谈SRC中关于密码重置漏洞的相关思路