【转载】任意用户密码重置的10种常见姿式

【原文连接】https://www.lovesec.com/penetration-test/233.html

1 验证码不失效

• 形成缘由：找回密码的时候获取的验

证码缺乏时间限制仅值判断了验证码是
够正确未判断验证码是否过时

• 测试方法：经过枚举找到真正的验证

码输入验证码完成验证
-案例
输入目标手机号，获取验证码随意输入验证码1234点击下一步，拦截数据包

POST /Account/CheckYQCode HTTP/1.1 Host: www.xxxx.cn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Accept: */* Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest http://www.xxxx.cn/userCenter/toForgetPsdPage.html?mobile= Content-Length: 11 Cookie: ASP.NET_SessionId=30jfruwn22h2xng3ahhzo2jx Connection: close YQCode=1234

获得正确的验证码是1059而后到网站上输入验证码跳转到输入新密码的页面完成重置密码

2验证码直接返回

• 1.输入目标手机号，

点击获取验证码

• 2.验证码直接返回

1269，输入验证
码跳转到重置页面

3.验证码未绑定用户

• 形成缘由：输入手机号和验证码进行重置密码的时候，仅对验证码是够正确进行了判断，未对该验证码是否与手机号匹配作验证。
• 测试方法：在提交手机号和验证码的时候，替换手机号为他人手机号进行测试，成功经过验证并重置他人密码。

首先使用本身的手机号接收验证码而后输入本身手机号接收到的验证码，点击下一步并拦截数据包最后替换数据包里的目标手机号，而后发包

这个案例也是验证码未绑定用户延伸一下，有时候测试会碰到这种，咱们发现用户名被加密了，咱们又没法得知加密算法，怎么办？大部分这种都不须要知道加密算法，好比这个例子，获得的liuyy的加密后的值是80e688602c4b11e66320c421e3b71ef2，那么咱们就能够直接用这个keycode了

步骤是同样的，输入咱们的用户名和收到的验证码，而后把咱们的keycode替换为liuyy的那个keycode，这样就能够重置liuyy的密码了。（漏洞缘由仍是是判断了验证码是否正确，而没有判断该验证码是否跟该用户匹配。）

4.修改接收的手机或邮箱

• 形成缘由：用户名、手机号、验证码三者没有统一进行验证，仅判断了三者中的手机号和验证是否匹配和正确，若是正确则判断成功并进入下一流程。
• 测试方法：输入用户名获取验证码，修改接收验证码的手机号为本身的号码，本身手机成功接收验证码，提交到网站进行验证，验证成功并进入下一流程。

点击找回密码，首先咱们输入zhangwei，而后点击获取验证码，这个时候把手机号改成咱们本身的号码，输入咱们本身的号码和验证码，成功跳到重置密码的页面，密码重置成功

5本地验证的绕过

• 形成缘由：客户端在本地进行验证码是否正确的判断，而该判断结果也能够在本地修改，最终致使欺骗客户端，误觉得咱们已经输入了正确的验证码。
• 测试方法：重置目标用户，输入错误验证码，修改返回包，把错误改成正确，便可绕过验证步骤，最终重置用户密码。

输入手机号13888888888，输入验证码123456，验证码错误的时候，返回包返回的是0

这里咱们所作的就是把0修改成1，能够借工具修改返回包，咱们把0改成1，而后查看页面，成功跳转到修改密码的页面，输入新密码便可修改用户13888888888的密码

6跳过验证步骤

• 形成缘由：对修改密码的步骤，没有作校验，致使能够直接输入最终修改密码的网址，直接跳转到该页面，而后输入新密码达到重置密码的目的。
• 测试方法：首先使用本身的帐号走一次流程，获取每一个步骤的页面连接，而后记录页面3对应的输入新密码的连接，重置他人用户时，获取验证码后，直接输入页面3连接到新密码的界面，输入密码重置成功。

使用帐户wangshuai，点击获取验证码，而后补齐下面的连接https://xxx/page/login/veifyAccess.html?username=wangshuai&email=wangshuai@xxx.com.cn，访问后便可直接重置该用户的密码

7未校验用户字段的值

• 形成缘由：在整个重置密码的流程中，只对验证码和手机号作了校验，未对后面设置新密码的用户身份作判断，致使在最后一步经过修改用户身份来重置他人的密码。
• 测试方法：使用本身的手机号走流程，在走到最后一个设置密码的流程时，修改数据包里的用户信息。

8修改密码处id可替换

• 形成缘由：修改密码的时候，没有对原密码进行判断，且根据id的值来修改用户的密码，相似的SQL语句：update user set password="qwer1234" where id = ‘1’修改数据包里的id的值，便可修改他人密码。
• 测试方法：修改本身用户密码，抓取数据包，替换数据包中用户对应的id值，便可修改他人的密码。

点击当即提交，获得右边的数据包，测试发现修改id为5，就能够把对应的用户密码修改成123456，没有对用户的原始密码判断，也没有判断id是否属于该用户。8.修改密码处id可替换

成功修改id为5的用户密码为123456，并且能够经过遍历id修改全部用户的密码

9.cookie值的替换

• 形成缘由：重置密码走到最后一步的时候仅判断惟一的用户标识cookie是否存在，并无判断该cookie有没有经过以前重置密码过程的验证，致使可替换cookie重置他人用户密码。（cookie可指定用户获取）
• 测试方法：重置本身用户密码到达最后阶段，抓到数据包，并在第一阶段从新获取目标用户cookie，替换cookie到咱们抓取的数据包中，发包测试。

到第一步去获取验证码的时候，点击下一页，能够获取到该用户wangshuai对应的内容Cookie: JSESSIONID=E1AC27A7302C03C9432DE2254B99311A

10.修改信息时替换字段值

• 形成缘由：在执行修改信息的sql语句的时候，用户的密码也看成字段执行了，并且是根据隐藏参数loginid来执行的，这样就致使修改隐藏参数loginid的值，就能够修改他人的用户密码。
• 测试方法：修改我的资料的时候，抓取数据包，而后来修改数据包的参数和对应的值，参数名通常能够在其余地方找到，替换隐藏参数便可修改他人的密码等信息。

view-source:https://www.xxx.com/ua/employee/forUpdate.do查看下这个页面的源代码，找到了一个参数loginId，这个参数是对应用户身份的而咱们发现 上面的数据包里没有这个参数，那么咱们是否能够本身添加上去呢？

添加字段loginId，而且把值修改成他人的用户，发包返回修改为功这样咱们就成功的把用户871XXXXXX的密码改成了跟咱们密码相同的值