在freebuf上看到了一个关于任意用户重置密码的系列文章，感觉挺不错了，算得是上比较全得了，年初就看过，今天突然发现他出了新的文章，这里记录一下。
原网址：http://www.freebuf.com/articles/web/160883.html。
之所以写这篇文章主要是想总结一下这块的问题，之前不够体系，测试得时候有时候会忘记一两点不测试，这次站在巨人身上总结下别人知识的同时加一些自己的想法和里面没有的对象。这里没有将实际的例子写在这里，因为如果直接copy别人的例子来太那啥了，自己找例子工作量又很大，且对自己意义不大。所以如果各位有地方不大懂得可以去原地址看下实例，也可以直接留言问我。
一：重置凭证泄露
- 重置密码时，凭证为发送到手机上的验证码，但是通过拦截发送发送验证码请求对应的response包时，发现验证码在response包中
- 重置密码时，利用邮件找回密码时，带有凭证的重置链接泄露至客户端（这是返回包中）
二：接受端可以修改
3.重置密码时，凭证会发送到手机上，通过替换手机号，可以使用自己的手机号接受验证码
4.还有一种情况比较特殊，也是手机接受验证码，但是重置密码的整个流程中并没有输入过手机号之类的，说明后台程序很可能是通过用户名来查询的电话号码。整个重置流程中，一般第一步是绑定用户名的地方，但是如果后面几个流程中还会发送用户名这个参数（这个时候发送的参数可能是单独用于在数据库中查询手机号的，同时说明这个地方可能存在sql注入），可以修改尝试一下。
三：
5.sessionid固定（也可以说是Cookie混淆），意思就是说不管使用那个用户进行重置密码操作，sessionid都是固定了，只是绑定的用户不同（有时候只是用户的登陆状态不同，所以sessionid固定也会导致会话固定漏洞）。利用方法：使用攻击者的账号走重置密码的流程，到最后一步也就是提交新密码时不要点击提交或者使用burp拦截请求包，再在同一浏览器中打开重置密码的页面，使用受攻击者的账号走流程，到走不动的时候如需要输入手机验证码的时候，这时sessionid就已经和收攻击者的账号绑定在一起了。再将之前我们拦截的提交新密码的请求放行，这时后台程序修改的将是受攻击者账号的密码。
这里关于sessionid的知识 大家可以在网上查或者看我之前关于JWT的文章中有讲，对于理解sessionid有很大的帮助。
5.还有一种情况比较简单，就是使用攻击者自己的账号重置密码走流程到最后一步提交新密码时，使用burp抓包，如果请求包中包含有用户名或id能信息，可以将其修改为受攻击者的用户名或密码。（这个也属于不安全对象直接引用的一种，原因是前面一大堆步骤都没有实际意义，还是使用的最后一个请求中的用户名或id进行的重置密码操作）
7.有些重置密码的时候，使用邮件接受的重置密码的链接。有些程序使用RSET风格的请求，并将用于绑定用户的信息（用户名、id）直接或加密后放在链接中，那么我们只需将链接中这段信息对应地改成受攻击者的信息即可。
四：重置凭证未校验
8.服务器端未校验token导致可以重置任意账号密码。这个我觉得还是很少见的应该，但是既然人家遇到了说明还是存在的。使用邮件接受到的重置密码的链接如下：
http://www.xxx.net/users/retrievePasswordReset/key:xxxxxx/userEmail:[email protected]
按道理，这里的key和useremail应该是一一对应的关系，但是如果应用程序有缺陷，key不起效果，我们可以使用找回admin的密码，直接访问构造的链接即可，key可以随意填：
http://www.xxx.net/users/retrievePasswordReset/key:666666/userEmail:[email protected]
（我都不好意思继续说下去，这样的开发祭天吧）
9.有些重置密码的模块可以通过回答密保问题来重置密码。但是有部分用户并没有设置密保问题，那么就有可能我们提交任意的密保答案都可以重置这些用户的密码。怎样确认这些用户是否存在密保呢？一般通过密保重置密码的场景，第一步都会让我们先输入用户名，发送请求包后我们可以拦截response包，很多时候，我们可以发现用户存在且有密保、用户存在但没有密保、用户不存在这三种情况返回包都不一样，我们可以使用burp进行爆破找出存在但没有密保用户名。
五：凭证可以爆破
10.手机验证码为四位数，可以爆破
六：客户端校验返回包中的状态码
11.很多时候，比如说重置密码最关键一步需要输入手机接受的验证码，但是我们没有正确的验证码，随便输入个1111，发送后拦截返回包，发现返回包中带有参数，这个参数用于传递给前台以决定我们是否可以进入下一步。至于怎样判断这个参数是否是这个用处呢？其实很简单，一般这种返回包中带有的参数都很少，我们可以先使用攻击者自己的账号走一遍流程，输入正确的手机验证码后，观察参数值是什么，再走一次流程，故意输入错误的验证码，观察参数值是什么，然后两种对比一下。比如说code=true/false或者是code=0/1或者是code=111/000这种，总之大家一看就清楚了。
七：token可预测
使用邮件接受重置密码的链接时，一般都会带有一个token用于判断链接是否被修改过。如果token可以预测，那么攻击者可以通过构造链接来重置任意的用户密码。
12基于时间戳生成的Token
部分程序使用当前时间戳MD5加密后的值作为token，那我们怎么知道具体的时间戳呢？可以使用我们自己的账号先走一遍流程，再用admin的账号走一次流程，再用自己的账号再走一次流程。由于第一次和第三次是我们自己的账号，可以收到邮件，我们取出两邮件中重置密码链接中的时间戳，那么admin的重置密码链接中的时间戳应该时介于之前两个时间戳之间的，使用burp爆破，找出正确的时间戳，构造链接即可。
13.基于递增序号生成的token
多获取几次重置密码的链接，发现参数具有一定的规律。比如说递增。
14.基于关键字段生成的token
和上面的第一种情况类似，token可能并不是对时间戳进行的md5，也有可能时MD5(username+id)，例如这种。
八：逻辑漏洞
15.比如说重置密码时，一般有四步，第三部是填手机验证码，第四步是填新密码。我们进行到第三部时，直接绕过第三步，访问第四步的url即可。至于怎样知道第四步的url呢？使用自己的账号走一遍流程不就可以了吗。