WEB渗透测试之任意用户密码重置

    培训几天挖了好几个任意密码重置漏洞，现在总结一下以便以后在密码重置这条路走的更顺畅= =

通用流程

    任意用户密码一般都是从忘记密码功能点开始，点开后如果发现验证是分步验证的，那么就可以继续搞了，进去后大部分都是第一步进行验证或者发短信验证，成功的话就进入下一步输入新密码的步骤，到这步的话就成功了。第一步输入正确的验证信息或者通过短信验证进入下一步的目的就是为了进入输入新密码的步骤。

入口分类

    一般重置密码漏洞有两种类型，分别为通过自己的账号和已知的别人的账号进行重置别人的密码。

    自己的账号已知的密码

        直接使用自己的账号进行短信验证码或者密保问题进入下一步修改新密码的步骤，后端没身份校验的话更改账号为别人的账号即可。下面分享一个骚案例：

        此案例在将请求报文中{用户账号、新密码、各种信息}的数据进行加密，签名等操作，放到请求头中，后台再进验证，如果像常规操作一样只更改请求报文中的账号的话，后台进行验证时会失败，因为请求头中的自定义字段签名使用的是上一步的原始的账号。

        这里需要分析JS加密代码，在浏览器的console中调用对应的算法进行加密，结果放到请求头中即可重置任意合法用户密码。或者暴力枚举请求头中的签名也可以，只是笨了点。案例图如下：

        图中的contentmd5、digest、key、sign的字段都是前端算出来的，只要将其他用户账号通过JS中的算法进行计算即可。JS的源码就不放出来了。这些字段就相当于cookie了，只不过使用的是摘要，后台无法恢复进而对用户身份进行验证。正常是使用加密算法进行加密，到后台解密并进行身份验证的。

        注：加密算法使用对称加密时对称密钥需要使用非对称加密进行复合加密，同时对称加密密钥要动态变化，当然也可以使用服务器传回来的公钥进行加密。

    已存在的账号但不知道密码

        通过账号枚举或其他的渠道获取合法用户，使用合法用户进行忘记密码操作，在进行邮箱验证或者短信或密保等问题时修改返回报文的参数，一般都是前端JS都是根据收到的结果判断是否跳转到修改新密码的页面。例如下图修改json中success字段为1即可：

    下面针对已存在的账号介绍一个骚方法或者是一个特殊的案例：

        利用COOKIE进行修改：

        此案例的前置条件：a. 首先通过存在的用户名_1进入密保问题界面，猜对了“最爱的运动：羽毛球”。b. 后台没有对用户身份验证。

        步骤是通过第一步验证进入输入新密码界面后，输入新密码后repeater中，由于其他的用户_2密保问题没那么容易才猜对或者工作量太大，那么就随便输入答案后抓包，将用户_2身份的标识cookie复制到repeater中重放，后台会从cookie中获取用户_2的身份进行密码重置。

        原理就是通过猜测进入到输入新密码的步骤，然后用其他用户进入到密保步骤获取此用户cookie，此cookie就相当于用户名直接复制到前面修改密码的请求中即可。

任意用户密码重置大全

1，短信验证码可爆破；

视频案例中输入手机号码、图片验证码就可以获取短信验证码，并且新密码也是在一个页面中，但是输入短信验证码之后，后端有个请求会判断短信验证码是否正确，错误的话页面会有提醒。攻击者可以用这个请求来爆破验证码，获取到正确的短信验证码之后就可以重置任意用户密码了。

缺陷主要是两个方面，第一，未对短信验证码的失效时间进行限制；第二，功能设计存在缺陷，如果设计成整个功能只用最后一个请求，包含注册手机号码、图片验证码、短信 验证码、新密码，对这个请求中手机号码、短信验证码的匹配以及短信验证码的正确性进行验证，攻击者就没办法进行爆破。当然前提是有正确运用图片验证码。

2，短信验证码显示在获取验证码请求的回显中；

攻击者知道被攻击用户的手机号码，获取短信验证码，抓包就可以在回显中看到用户收到的重置用的短信验证码。

3，注册手机号及短信验证码未进行匹配性验证；

攻击者用自己手机号码收到的重置用短信验证码可以重置其它用户的密码。

4，用户名、手机号码、短信验证码三者没有进行匹配性验证；

只验证码了手机号码、短信验证码是否匹配，最终重置密码是根据用户名来重置的。攻击者重置用户a的密码，获取短信验证码的时候将手机号码修改成自己账号对应的，获取到对应的正确短信验证码，然后输入短信验证码，由于只验证了手机号码以及短息验证码是否匹配，从而可以成功绕过短信验证码限制来重置用户a的密码。

5，短信验证码的验证在本地客户端进行验证；

通过修改请求回显来绕过，常见重置姿势之一，也可以用于绕过一些其它的前端验证，比如存储xss，参数的合法性验证如果通过前端来完成，也是可以用这种姿势绕过的。

6，重置步骤未进行校验；

这种一般发生在多个步骤重置的过程中，未对步骤1，2进行校验，通过修改url直接绕过短信验证码的校验步骤，直接进入重置页面进行重置。

7，重置请求未验证身份；

跟方法4差不多，最终重置请求没有验证用户身份信息。攻击者用自己的手机号码短信验证码走重置流程，最后一步重置请求抓包修改身份信息为其它用户的，从而进行其它用户密码的重置。

8，登陆成功修改密码功能平行越权；

用户登陆成功之后可修改自己的密码，修改请求只需要输入新密码，请求中未验证当前用户的cookie、session、id等身份信息，可以通过修改id等来重置其它用户的密码。

9，未校验身份信息的唯一标识cookie信息；

重置请求参数中没有用户名、手机号码、id等身份标识，唯一的身份标识是在cookie中。攻击者用自己的账号进行重置，最后重置请求中替换掉请求中的cookie进行其它用户密码的重置。

10，MVC数据对象自动绑定漏洞；

邮箱重置密码或者手机号码重置密码的时候，请求中没有明显的身份标识，可以尝试增加参数值来测试是否存在MVC数据对应自动绑定漏洞。比如增加email参数及对应的自用邮箱作为参数值，看看是否能收到密码重置链接。