任意用户密码重置（四）：重置凭证未校验
在逻辑漏洞中，任意用户密码重置最为常见，可能出现在新用户注册页面，也可能是用户登录后重置密码的页面，或者用户忘记密码时的密码找回页面，其中，密码找回功能是重灾区。我把日常渗透过程中遇到的案例作了漏洞成因分析，这次，关注因重置凭证未校验导致的任意用户密码重置问题。
密码找回需要鉴别用户的合法身份，证明你就是你，通常有两种做法，一是网站将重置验证码发至用户绑定的邮箱或手机号，用户持重置验证码证明你就是你，二是用户输入密码保护问题对应的答案。其中，验证码、密保答案就是重置密码的重要凭证。
在日常对密码找回功能的攻击中，我的大部份精力聚焦在是否可以暴破验证码、是否可以劫持接收验证码的手机号或邮箱、是否可以混淆重置其他账号、是否可以绕过验证步骤、甚至是猜测重置 token 的生成规律等攻击方式上，反而忽略了最容易、最低技术含量的一种方式——服务端未校验重置凭证。换言之，不论你输入的重置验证码或密保答案是否正确，只要请求格式无误，均可成功重置任意账号密码。我举两个真实案例（漏洞均已修复，就不打码了），你感受下。
案例一：因服务端未校验 token 导致可重置任意账号密码
密码找回页面 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 等等：
将以上几类邮箱字典存为 mail.txt 也就是用户名。
这样，我不仅可以重置普通账号的密码，还能劫持大量内部员工、合作伙伴的账号，为避免影响业务，不再实际操作。
案例二：可枚举无密保的用户名，导致任意密保答案均可重置密码
在密码找回页面 http://www.hzpzs.net/u_findPassword.asp 输入有效用户名 yangyangwithgnu 后拦截请求包：
猜测该数据包用于用户名有效性校验，放至 repeater 中分析。
由于没用图片验证码，导致可枚举有效用户名，发现三类情况。一是，用户名存在且设置过密保问题，应答类似：
二是，用户名存在但未设置密保问题，应答类似：
三是，无效用户名，则应答类似：
用常见用户名和中国人姓名拼音作为字典进行枚举，在所有结果中过滤显示含有关键字 的应答，得到的所有 UserName 参数值即为未设置密保问题的用户名。如：aaron、admin、adolph、alisa、chenchen、esther、jones 等等。
按正常流程，对 chenxin 进行密码重置，输入任意密保答案均可重置密码：
加固措施
密码重置凭证一定要严格校验，空密保问题时禁止通过密保找回密码；服务端应限制枚举等恶意请求。另外，鞭打开发人员，皮鞭加盐。
在逻辑漏洞中，任意用户密码重置最为常见，可能出现在新用户注册页面，也可能是用户登录后重置密码的页面，或者用户忘记密码时的密码找回页面，其中，密码找回功能是重灾区。我把日常渗透过程中遇到的案例作了漏洞成因分析，这次，关注因重置凭证未校验导致的任意用户密码重置问题。 无奈人生安全网
密码找回需要鉴别用户的合法身份，证明你就是你，通常有两种做法，一是网站将重置验证码发至用户绑定的邮箱或手机号，用户持重置验证码证明你就是你，二是用户输入密码保护问题对应的答案。其中，验证码、密保答案就是重置密码的重要凭证。
在日常对密码找回功能的攻击中，我的大部份精力聚焦在是否可以暴破验证码、是否可以劫持接收验证码的手机号或邮箱、是否可以混淆重置其他账号、是否可以绕过验证步骤、甚至是猜测重置 token 的生成规律等攻击方式上，反而忽略了最容易、最低技术含量的一种方式——服务端未校验重置凭证。换言之，不论你输入的重置验证码或密保答案是否正确，只要请求格式无误，均可成功重置任意账号密码。我举两个真实案例（漏洞均已修复，就不打码了），你感受下。
案例一：因服务端未校验 token 导致可重置任意账号密码
密码找回页面 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 等等：
本文来自无奈人生安全网 将以上几类邮箱字典存为 mail.txt 也就是用户名。
这样，我不仅可以重置普通账号的密码，还能劫持大量内部员工、合作伙伴的账号，为避免影响业务，不再实际操作。
案例二：可枚举无密保的用户名，导致任意密保答案均可重置密码
在密码找回页面 http://www.hzpzs.net/u_findPassword.asp 输入有效用户名 yangyangwithgnu 后拦截请求包：
猜测该数据包用于用户名有效性校验，放至 repeater 中分析。
由于没用图片验证码，导致可枚举有效用户名，发现三类情况。一是，用户名存在且设置过密保问题，应答类似：
二是，用户名存在但未设置密保问题，应答类似：
www.wnhack.com 三是，无效用户名，则应答类似：
用常见用户名和中国人姓名拼音作为字典进行枚举，在所有结果中过滤显示含有关键字 的应答，得到的所有 UserName 参数值即为未设置密保问题的用户名。如：aaron、admin、adolph、alisa、chenchen、esther、jones 等等。
按正常流程，对 chenxin 进行密码重置，输入任意密保答案均可重置密码：
加固措施
密码重置凭证一定要严格校验，空密保问题时禁止通过密保找回密码；服务端应限制枚举等恶意请求。另外，鞭打开发人员，皮鞭加盐。
内容来自无奈安全网