密码重置逻辑漏洞分析与利用教学

漏洞背景

本文分析了一个典型的密码重置功能逻辑缺陷，该漏洞存在于Web和App端的密码修改流程中。通过巧妙绕过多重验证机制，攻击者可以在不获取用户原始密码的情况下重置任意用户密码。

漏洞发现环境

• 目标系统：某客户Web端和App端
• 测试功能：密码重置和修改功能
• 前期发现：App端存在手机号验证绕过导致任意用户密码重置

漏洞详细分析

1. 密码修改流程分析

系统密码修改功能分为两步验证：

1. 第一步验证：手机验证码验证

   • 请求参数包含：手机号、验证码
   • 服务器返回状态码(code)标识验证结果

2. 第二步验证：提交新密码

   • 请求参数包含：验证码、旧密码、新密码等
   • 服务器使用ut参数(用户令牌)验证用户身份

2. 初始绕过尝试

测试人员首先尝试修改code=0绕过第一次手机号验证，发现系统虽然要求验证码参数，但实际上并未进行二次校验，直接允许密码修改。

关键发现：

• 系统仅依赖ut参数进行用户身份验证
• 修改他人密码需要获取目标用户的ut值

3. 深入利用技巧

通过对比忘记密码功能(未登录状态)和已登录状态的密码修改流程，发现：

1. 已登录状态：

   • 系统验证ut值和手机号
   • 需要知道目标用户的ut值才能修改其密码

2. 未登录状态：

   • 系统无法获取用户信息
   • 不验证手机验证码和旧密码
   • 直接允许密码修改

利用方法：

• 删除cookie中的ut值，使系统认为处于未登录状态
• 此时可以绕过所有验证直接修改密码

漏洞原理总结

1. 验证逻辑缺陷：

   • 系统仅在前端进行分步验证，后端未严格校验每一步
   • 身份验证仅依赖单一token(ut值)

2. 状态处理不当：

   • 未登录状态下的安全控制缺失
   • 未对关键操作(密码修改)实施足够强度的验证

3. 会话管理问题：

   • 用户状态判断仅基于ut值存在与否
   • 缺乏对关键操作的上下文关联验证

漏洞复现步骤

1. 访问密码修改页面
2. 拦截修改请求(使用Burp Suite等工具)
3. 删除请求中的ut相关参数或cookie
4. 修改目标用户手机号参数
5. 提交请求完成密码修改

防御建议

1. 强化验证流程：

   • 实施真正多因素认证
   • 后端严格校验每一步验证结果
   • 对关键操作要求重新认证

2. 完善会话管理：

   • 使用更安全的会话标识方式
   • 关键操作绑定完整会话上下文

3. 输入验证：

   • 对所有输入参数进行严格验证
   • 实施服务端校验，不信任客户端提交的任何状态

4. 日志监控：

   • 记录所有密码修改操作
   • 监控异常修改行为

教学总结

本案例展示了典型的业务逻辑漏洞，其特点包括：

• 验证流程可被分步绕过
• 状态判断过于简单
• 过度依赖前端控制
• 缺乏操作上下文关联

这类漏洞往往无法通过自动化工具发现，需要测试人员深入理解业务逻辑，通过手动测试和思维突破才能发现。