上篇没写完不小心点了发布，今天来做下篇。
*密码找回需要鉴别用户的合法身份，证明你就是你，通常有两种做法，一是网站将重置验证码发至用户绑定的邮箱或手机号，用户持重置验证码证明你就是你，二是用户输入密码保护问题对应的答案。其中，验证码、密保答案就是重置密码的重要凭证。
先上分类图
.
在日常对密码找回功能的攻击中，我的大部份精力聚焦在是否可以暴破验证码、是否可以劫持接收验证码的手机号或邮箱、是否可以混淆重置其他账号、是否可以绕过验证步骤、甚至是猜测重置 token 的生成规律等攻击方式上，反而忽略了最容易、最低技术含量的一种方式——服务端未校验重置凭证。换言之，不论你输入的重置验证码或密保答案是否正确，只要请求格式无误，均可成功重置任意账号密码。我举两个真实案例（漏洞均已修复，就不打码了），你感受下。
这几个案例就是根本没有进行验证的情况

案例1 因服务端未校验 token 导致可重置任意账号密码 6-3

密码找回页面 http://www.omegatravel.net/users/retrievePassword/ 用攻击者账号 yangyangwithgnu@yeah.net 进入密码找回全流程，输入图片验证码后提交：
随后收到带 token 的密码重置链接的邮件：
其中，key:FqvICT 和 userEmail:yangyangwithgnu@yeah.net 引起了我的注意。正常来说，提交该 URL 后，服务端会校验 key 与 userEmail 是否匹配，若匹配则进入提交新密码页面，若不匹配则报错。现在，我尝试将 key 从 FqvICT 改为 xxxxxx 后再访问，本来心理预期将看到报错页面，没想到进入了新密码提交页面，难倒所谓的重置 token 仅仅是个摆设？

赶紧找个账号试试，就拿信息收集时找到的 travel24@omegatravel.net 为例（更多后台账号见后文）。参照前面收到的重置链接格式，简单拼装为 http://www.omegatravel.net/users/retrievePasswordReset/key:xxxxxx/userEmail:travel24@omegatravel.net，是滴，key 的值我随便写的，访问看看，哇，居然真的进入了新密码提交页面：
输入新密码 PenTest1024 后提交，网站提示“修改密码成功”。尝试用 travel24@omegatravel.net/PenTest1024 登录，成功进入系统：
如何获取其他账号？从注册页面可知，该网站只能用邮箱注册，邮箱即账号。我关心普通用户和内部员工用户两类账号（即邮箱）。普通用户的邮箱字典方面，把国人常见姓名拼音 top500 结合常见邮箱后缀（@qq.com、@163.com 等等）快速生成个简单邮箱字典；内部员工的邮箱方面，我从该网站域名注册信息查询到联系人为 omegait@omegauk.net，说明该公司使用 @omegauk.net 的邮箱后缀，同上，把国人常见姓名拼音 top500、常见后台账号，结合 @omegauk.net 邮箱后缀，快速生邮箱字典；另外，从“联系我们”、“诚聘英才”、“公司简介”等页面找到大量内部员工邮箱和合作伙伴邮箱，如 info@jadetravel.co.uk、info@ukchinese.com 等等：
看过此案例总结： 这个密码重置链接的token就是个摆设，没有进行验证，只要格式正确输入进信息就可以重置任意密码，属于服务器验证分类的服务器验证逻辑为空 6-3

密码找回需要鉴别用户的合法身份，证明你就是你，通常有两种做法，一是网站将重置验证码发至用户绑定的邮箱或手机号，用户持重置验证码证明你就是你，二是用户输入密码保护问题对应的答案。其中，验证码、密保答案就是重置密码的重要凭证。有些网站生成四位数字的重置验证码，复杂度较低，[0000, 9999] 也就一万种组合，在如今的计算能力和网络带宽条件下，顺手的工具三五分钟的功夫就能枚举完。如果服务端又未设置验证码的存活有效期、未限制高频访问，那么极易暴破。

案例二：1-1 用户凭证暴力破解

密码找回页面 http://xx.xxxx.com/xxxx/findpassword 用攻击者账号 13908081024 进入密码找回全流程，输入图片验证码、选择手机找回、获取短信验证码，发现短信验证码为 4 位数字且短信内容上未告知有效期，所以，可暴破短信验证码，进行后续的重置流程。

用用户名枚举得到的普通手机号 15012804897 为例，进入密码找回流程，提交短信验证码
其中，1234 是我随便输入的错误的短信验证码，需要对 auto 参数进行暴破以找出正确的短信验证码：

很快暴出短信验证码为 6909

一个很简单的无限制的验证码爆破，由于没有对验证码提交进行限制，导致多次提交枚举爆破，会抓包爆破就可以得到验证码

案例2.5 1-1 添加了限制措施但是可以绕过进行爆破

服务端有密码试错上限的机制，错误 5 次则一小时内禁止登录：
查看登录请求：
logintime 参数名和参数值引起我注意，刚好也是试错上限 5，尝试将值其改为 4 后，服务器又正常响应，或者，删除整改 logintime 后，也可绕过试错限制。

现在，用删除 logintime 后的请求包，将 mobile 定义为枚举变量 1、以前面生成的 username.txt 为字典，将 password 定义为枚举变量 2、以常见弱口令 top1000 为字典，进行密码暴破：
logintime 参数名和参数值引起我注意，刚好也是试错上限 5，尝试将值其改为 4 后，服务器又正常响应，或者，删除整改 logintime 后，也可绕过试错限制。

现在，用删除 logintime 后的请求包，将 mobile 定义为枚举变量 1、以前面生成的 username.txt 为字典，将 password 定义为枚举变量 2、以常见弱口令 top1000 为字典，进行密码暴破：

其中，应答包长度为 380 的均为有效密码，存为 logined.txt：

案例三 9-本地验证

密码找回流程一般包括获取短信验证码、校验短信验证码是否有效、设置新密码等三个步骤。在第二步，校验短信验证码是否有效的结果应保存在服务端，某些网站未在服务端保存而是错误地将结果状态值下发客户端，后续又依靠前端 js 判断是否可以进入第三步，那么，更改应答包中的状态值，可重置其他用户的密码。

在密码找回页面 http://www.xx.cn/yy/action/forgot 用攻击者手机号 13908081024 进入密码找回全流程，获取短信验证码 033128、输入图片验证码、输入短信验证码并提交：
服务端校验通过后，系统应答如下：
简单分析发现，校验通过时服务端并未向客户端 set-cookie，猜测服务端并未记录校验状态，是否进入设置新密码页面完全是由前端 js 基于应答状态决定的，那么，即便我没有短信验证码，通过将服务端下发给客户端的校验状态从“失败”改为“成功”，也能成功重置找回账号密码。

具体而言，以信息搜集时找到的客服手机号 13980808888 为例。输入手机号、获取短信验证码、输入图片验证码、输入错误的短信验证码 123123 后提交：

由于短信验证码错误，系统校验肯定失败，系统应答如下：
拦截该应答，用前面抓取校验成功的应答包替换之：
放行至客户端，顺利进入新密码设置页面：

**通过抓取成功验证验证码的返回包，然后替换导致绕过验证码，这属于本地验证，只通过返回包的信息调用js

加固措施

服务端校验短信验证码后应通过 cookie 记录状态，不应在前端通过状态参数判断。另外，服务端应限制枚举等恶意请求。**

差不多情况的另一个案例

通过邮箱找回密码时，邮件中将出现一个含有 token 的重置 URL，该 token 即为重置凭证。从经验来看，开发人员习惯以时间戳、递增序号、关键字段（如邮箱地址）等三类信息之一作为因子，采用某种加密算法或编码生成 token，攻击者可以基于能收集到的关键字段，用常见加密算法计算一遍，以判断是否可以预测出 token。

案例一：基于时间戳生成的 token 3-1时间戳md5

http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac/ 是一道在线 CTF 题目：
对应请求与应答为：
除了提示已发送重置邮件外，并无其他信息。尝试重置其他账号 yangyangwithgnu：
获得重置 URL 信息 http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac/reset.php?sukey=8135f8b07653b2cbc3ec05c781a29591&username=yangyangwithgnu，访问后提示重置成功。那么，现在的情况是，admin 的重置 URL 无显示，其他账号的 URL 有显示，只要拿到 admin 的重置 URL，很可能就能看到 flag。

上面重置 URL 中 sukey 参数引起我的注意，显然它就是重置凭证。将其值 8135f8b07653b2cbc3ec05c781a29591 先用 base64 解码无果，后将其进行 MD5 解密得到明文 1530342360：

貌似 unix 时间戳，验证之：
果然，重置凭证是对当前 unix 时间戳进行 MD5 加密所得。

那么，可以设计这样一种攻击模型，达到重置任意账号密码的目的：第一次找回 yangyangwithgnu 的密码，获得重置 URL，其中 sukey 参数含有时间戳信息；第二次找回 admin 的密码，暂时虽无法获得重置 URL，没关系，服务端是已经生成好了；第三次又找回 yangyangwithgnu 的密码，获得重置 URL，其中 sukey 参数含有时间戳信息。以第一、三次获得的时间戳作为时间区间，由于整个过程都在短时间内完成，所以，可以轻松暴破出第二次的时间戳。

具体而言，先发起找回 yangyangwithgnu 密码的请求：

得到时间戳 1530347130；接着发起找回 admin 密码的请求：
然后再次发起找回 yangyangwithgnu 密码的请求：
得到时间戳 1530347161。现在可知 admin 的时间戳在 [1530347130, 1530347161] 中，基于之前获得的重置 URL 格式，我们可以构造出 admin 的密码重置 URL 类似 http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac/reset.php?sukey={md5(unix_timestamp)}&username=admin。接下来，我将该 URL 放入 intruder 中进行暴破，将 unix_timestamp 定义为枚举变量：
以 [1530347130, 1530347161] 为字典，并设置 MD5 加密算法作为载荷预处理：
很快暴破出 admin 的重置 URL，并成功拿到 flag：

**这种就是属于token生成是由于时间戳生成的 归类归为导图3-1时间戳md5 **

下面这种属于token生成可控

案例二 基于递增序号生成的 token 11-token生成可控

金蝶云之家密码找回，带凭证的密码找回链接如下：
从参数名猜测，u 可能为 username、t 为 token，为减少复杂性，测试发现，删掉 u 参数及值也可正常重置密码，所以，可忽略 u 参数，重点关注 t 参数。

连续 5 次获取重置链接，从邮件中提取 5 个 t 参数值如下：

可以看出，t 参数值的 5～8位、最后 4 位，按 2 的增量呈现递增变化。

分析清楚凭证的变化规律，要重置任意账号就轻松了。比如，要重置普通账号 admin 的密码，可以先触发找回攻击者账号的密码，获取 t 为 52df773f24ac5b651d288d42，然后触发找回 admin 的密码，t 未知，再次触发找回攻击者账号的密码，获取 t 为 52df774d24ac5b651d288d54，根据前面分析得知的变化规律，普通账号的 t 的 5～8 位一定是 [7740, 774c] 间的偶数，后 4 位范围一定在 [8d44, 8d52] 间的偶数。几次枚举便可得有效 t 参数值：

这种就属于token可控 确定好是哪个=些参数有影响 看看参数有没有规律 11-token可控
**

接下来2个都是这样**

某网站密码找回功能，请求含有三个参数
username 是邮箱、rvcode 图片验证码、sid 未知，登录邮箱查看重置 URL：
key 参数为重置凭证，尝试分析生成方式。直接将其放入 md5 在线破解网站无果，尝试用 username、rvcode、sid 等三个参数的排列组合进行 md5，当尝试到 md5(username + sid) 时发现生成结果与邮件中的凭证一致：

猜测出其 key 的生成算法，那么，后续将豪无压力重置任意账号的密码了。

类似的还有，带凭证的重置链接为 http://mysite.com/sms.php?k=a18f057d5aF，多次获取重置链接发现，凭证 f198a79b9cF 末尾的 F 恒定不变，前面 10 位字符疑似 md5 加密，尝试对不同参数的排列组合进行 md5 加密，当尝试到 md5(手机号+图片验证码) 时发现生成结果与邮件中的凭证一致：

加固措施
密码重置链接中 token 尽可能随机化，若用常规加密算法，一定用客户端无法查看且猜测的因子作为盐值。另外，服务端应限制枚举等恶意请求。

任意账号注册

在注册页面 https://www.xxxx.com/Wap/User/register 输入未注册过的手机号点击“获取验证码”后、输入收到的短信验证码后提交，进入密码设置页面：
输入密码后拦截请求：
简单分析发现，register_mobile 为注册的用户名，只要该参数值未注册过，通过这个请求包可绕过短信验证成功创建任意账号。

比如，系统本来只允许用手机号当用户名进行注册，利用该漏洞，可以创建账号 yangyangwithgnu/abcd1234，登录确认：
任意账号注册有可能有xss哟

先记录到这里 后续看到有意思的文章会在评论或者重新补充