推文总结：
1、验证码回传（重置凭证泄露）
可能验证码就返回在response包中
2、验证码未绑定用户。
成因：输入手机号码和验证码只考虑到手机号对不对和验证码对不对，未对该验证码是否与手机号匹配做验证
3、用户混淆
成因：密码找回逻辑含有用户标识（用户名、用户ID、cookie），接收端（手机、邮件）、凭证（验证码、token），当前步骤等四个要素。若这个要素没有完全关联，则可能导致密码重置漏洞
参考链接：https://www.freebuf.com/articles/web/162152.html
4、接收端可篡改
成因：重置密码时，凭证会发送到手机上，通过替换手机号，可以使用自己的手机号接收验证码
还有还有一种情况比较特殊，也是手机接收验证码，但是整个验证流程没有让你输入手机号码，重置过程中，一般是第一步绑定用户名的地址，但是如果后面几个流程中还会发送用户名这个参数（这个时候发送的参数可能是单独用于在数据库查询手机号，这个时候我们输入的用户名就很大可能带入了数据库查询，所以可能存在SQL注入）
参考链接：https://www.freebuf.com/articles/database/161495.html
5、token可以预测，有些邮箱验证，会发来token验证，这时候多拿几个token来研究规律
6、基于时间戳生成的token
成因：部分程序使用当前时间戳MD5加密后的值作为token
测试方法：拿两个账号，第一次拿自己的账号走一遍流程，获得一个时间戳，第二次拿admin的账号走一遍流程，第三次再拿自己的账号走一遍，然后获得一个时间戳。这样我们就获得两个时间戳，而管理员的时间戳就是这两个时间戳之间，就利用爆破就可以爆破出重置管理员的时间戳，然后构造正确的链接，完成重置
7、找回密码的凭证脆弱
测试方法:找规律，拿到几个凭证来找规律，就是像上面说的弱token一般
8、测试方法：攻击者可以通过发送一组电子邮件地址而不是单个电子邮件地址向任意电子邮件发送密码重置链接。
9、重置凭证未校验
参考链接：https://www.freebuf.com/articles/web/164090.html
Tips：有些重置密码的模块可以通过回答密保问题来重置密码。
但是有部分用户并没有设置密保问题，那么就有可能我们提交任意的密保答案都可以重置这些用户的密码。
怎样确认这些用户是否存在密保呢？
一般通过密保重置密码的场景，第一步都会让我们先输入用户名，发送请求包后我们可以拦截response包，很多时候，我们可以发现用户存在且有密保、用户存在但没有密保、用户不存在这三种情况返回包都不一样，我们可以使用burp进行爆破找出存在但没有密保的用户名。
10、万能验证码
有些开发者，会设置一些密码来验证，比如888888、000000
这样的万能验证码却没有删除，就可以利用了
关注一个老洞：
http://0day5.com/archives/1043/
