【实战】某博彩资讯站的任意密码重置漏洞

一、故事背景

这次对某博彩资讯站进行业务安全测试。目标系统提供博彩资讯、赛事数据与投注入口的综合站点，前后端分离架构。客户重点关注账号安全，因为近期有用户投诉账号被盗。我在拿到授权后，重点测试了密码找回/重置流程。密码重置是账号安全的关键环节，一旦存在逻辑缺陷，攻击者就能接管任意账户，危害极大。

二、信息收集

信息收集阶段，我走了一遍密码找回流程。流程是：输入账号 → 系统发送短信验证码 → 输入验证码 → 设置新密码。我抓包分析了整个流程的请求。发现在"设置新密码"这一步，请求中携带了一个 token 参数，但这个 token 似乎与账号绑定关系不紧密。

三、漏洞发现

我进行了逻辑测试。发现两个关键问题：第一，短信验证码的校验在前端完成，后端没有校验验证码是否正确，只校验了 token 是否存在；第二，token 参数可以任意指定，服务端没有校验 token 与当前重置账号的绑定关系。这意味着我可以绕过验证码，直接重置任意账号的密码。

四、漏洞利用

我构造了一个重置管理员密码的请求：指定管理员账号，任意指定一个 token，设置新密码。请求提交后，服务端返回成功，管理员的密码被成功修改。我用新密码登录了管理员账号，验证了任意密码重置漏洞的完整危害。整个过程不需要任何验证码，只需要知道管理员账号即可。

五、权限获取

我整理了漏洞报告，详细记录了密码重置流程的逻辑缺陷、验证码校验前移的问题、token 绑定缺失的问题。客户高度重视，立即修复了密码重置流程，增加了服务端验证码校验和 token 绑定机制。

六、复盘总结

这次测试的核心教训是：密码重置流程的每一步校验都必须放在服务端。修复建议：第一，验证码必须在服务端校验，且验证后立即失效；第二，token 必须与具体账号和会话绑定，且设置过期时间；第三，重置成功后强制账号下线，并要求重新登录；第四，对密码重置操作做审计日志和异常告警。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。