MetInfo4.0 任意用户密码修改漏洞

0x04 密码找回安全

验证码客户端回显测试

    找回密码测试中要注意验证码是否会回显在响应中，有些⽹站程序会选择将验证码回显在响应中，来判       断⽤户输⼊的验证码是否和响应中的验证码⼀致，如果⼀致就会通过校验。

验证码暴⼒破解

    找回密码功能模块中通常会将⽤户凭证（⼀般为验证码）发送到⽤户⾃⼰才可以看到的⼿机号或者邮箱       中，只要⽤户不泄露⾃⼰的验证码就不会被攻击者利⽤，但是有些应⽤程序在验证码发送功能模块中验       证码位数及复杂性较弱，也没有对验证码做次数限制⽽导致验证码可被暴⼒枚举并修改任意⽤户密码。

    在测试验证码是否可以被暴⼒枚举时，可以先将验证码多次发送给⾃⼰的账号，观察验证码是否有规       律，如每次接收到的验证码为纯数字并且是4位数。

Response 状态值修改测试

    Response状态值修改测试，即修改请求的响应结果来达到密码重置的⽬的，存在这种漏洞的⽹站或者⼿机App往往因为校验不严格⽽导致了⾮常危险的重置密码操作。

    这种漏洞的利⽤⽅式通常是在服务端发送某个密码重置的凭证请求后，出现特定的响应值，⽐如true、1、ok、success等，⽹站看到回显内容为特定值后即修改密码，通常这种漏洞的回显值校验是在客户端进⾏的，所以只需要修改回显即可。

Session 覆盖

    找回密码逻辑漏洞测试中也会遇到参数不可控的情况，⽐如要修改的⽤户名或者绑定的⼿机号⽆法在提交参数时修改，服务端通过读取当前session会话来判断要修改密码的账号，这种情况下能否对Session   中的内容做修改以达到任意密码重置的⽬的呢？

    在某⽹站中的找回密码功能中，业务逻辑是：由⽤户使⽤⼿机进⾏注册，然后服务端向⼿机发送验证码短信，⽤户输⼊验证码提交后，进⼊密码重置⻚⾯。

对⽹站中Session覆盖的测试如下：

• 需要准备⾃⼰的账号接收凭证（短信验证码）；
• 获得凭证校验成功后进⼊密码重置⻚⾯；
• 在浏览器新标签重新打开找回密码⻚⾯，输⼊⽬标⼿机号；
• 此时当前 Session 账户已经被覆盖，重新回到第⼆步中打开的重置密码⻚⾯即可重置⽬标⼿机号

弱Token设计缺陷测试

    在找回密码功能中，很多⽹站会向⽤户邮箱发送找回密码⻚⾯链接，⽤户只需要进⼊邮箱，打开找回密码邮件中的链接，就可以进⼊密码重置⻚⾯了。找回密码的链接通常会加⼊校验参数来确认链接的有效性，通过校验参数的值与数据库⽣成的值是否⼀致来判断当前找回密码的链接是否有效

http://www.xxx.com/findpwd?uid=xx-uu-xx-sxx&token=1497515314

密码找回流程绕过测试

很多⽹站的密码找回功能⼀般有以下⼏个步骤

1.⽤户输⼊找回密码的账号；

2.校验凭证：向⽤户发送短信验证码或者找回密码链接，⽤户回填验证码或单击链接进⼊密码重置⻚⾯，以此⽅式证明当前操作⽤户是账号主⼈

3.校验成功进⼊重置密码⻚⾯。

    在找回密码逻辑中，第⼆步校验凭证最为重要。不是账号主⼈是⽆法收到校验凭的，试想有没有办法可以绕过第⼆步凭证校验，直接进⼊第三步重置密码呢？

    ⽤户修改密码需要向服务器发送修改密码请求，服务器通过后再修改数据库中相应的密码，所以在测试中我们⾸先要收集三个步骤的请求接⼝，重点是收集到最后⼀步重置密码的接⼝，这样我们可以直接跳过凭证校验的接⼝去尝试直接重置密码

接⼝参数账号修改

    找回密码功能逻辑中常常会在⽤户修改密码接⼝提交参数中存在传递⽤户账号的参数，⽽⽤户账号参数       作为⼀个可控变量是可以被篡改的，从⽽导致修改账号密码的凭证或修改的⽬标账号出现偏差，最终造       成任意账号密码修改的漏洞

    通常在找回密码逻辑中，服务端会要求⽤户提供要修改的账号，然后给这个账号发送只有账号主⼈才能       看到的凭证。⽐如给这个账号主⼈绑定的邮箱或者⼿机号发送验证码，或者找回密码链接，这样可以保证只有账号主⼈才可以看到这些凭证。但是如果服务器对账号的控制逻辑不当，就会导致原有账号被篡改为其他账号，服务器端把凭证发送给篡改后的账号的邮箱或⼿机，最终造成可利⽤凭证重置任意账号密码的漏洞

    接⼝参数账号修改流程测试为拦截前端请求，通过修改请求内的账号ID    、名称或者邮箱、⼿机号等参数，将修改后的数据发送给服务器进⾏欺骗达到密码重置的⽬的

以metinfov4.0 来例⼦，来说明这个问题