实战Web应用密码重置漏洞挖掘：常见逻辑缺陷与渗透测试思路

密码重置功能是 Web 应用中直接关系到用户账户安全的核心环节。正因为其普遍性和高敏感性，任何一个细微的逻辑缺陷都可能导致整个账户体系沦陷。本文将深入探讨密码重置漏洞的常见类型与实战挖掘思路。

整个攻击的核心思路可以概括为：站在攻击者角度，劫持任意用户的密码重置流程。主要分为以下几个关键步骤：

1. 初始化重置：为目标用户（受害者）发起密码重置请求。
2. 拦截/篡改凭证：获取或控制用于身份验证的重置凭证（如 Token、验证码、USERID 等）。
3. 接管流程：将本应发送给目标用户的凭证，转发或引导至攻击者控制端。
4. 完成重置：利用获取到的凭证，最终修改目标用户的密码。

下文将围绕密码重置漏洞的几种常见类型与具体挖掘思路展开详细讨论。

1、客户端状态校验不全

客户端响应篡改是逻辑漏洞的常见形式。其根源在于：应用程序将本应存储在服务器端、并由服务器端完全掌控和校验的关键业务状态（如“是否已通过身份验证”），错误地委托给了不可信的客户端（如用户的浏览器或APP）来存储和维护。当客户端将这些状态值返回给服务器时，服务端没有对其进行二次验证或溯源。

1.1 漏洞利用

进入目标网站的“忘记密码”页面，在验证步骤中，无论输入什么验证码（甚至留空），都进行抓包拦截。

然后修改返回包中标识验证状态的参数值。常见的操作是将 code 改为 0，或将 false 改为 true 等。

修改响应包使得客户端“认为”验证已通过后，页面通常会跳转到设置新密码的步骤。

接下来正常输入新密码并点击“下一步”，同时抓包。继续修改此次请求的响应值（例如将 success 字段改为 true），即可成功重置密码。

1.2 挖掘思路

1. 寻找目标场景：重点关注网站前台的“忘记密码”、“找回账号”等功能。如果前台没有明显入口，可以尝试从前端 JavaScript 代码中挖掘相关接口。
2. 测试服务端是否缺少校验：在流程中的关键步骤，通过拦截并修改客户端返回的状态值（例如将 "verified": false 改为 "verified": true），观察服务器是否仅依据此修改后的值来判断步骤是否完成，而缺少服务端自身的状态跟踪与校验。

2、步骤分离与校验不足

密码重置往往涉及多个步骤（如身份验证、Token验证、设置新密码），如果步骤间的状态关联校验不足，攻击者可能直接绕过关键验证步骤。

2.1 漏洞利用

以本地搭建的 Dedecms V5.7 为例。创建两个测试账户：test1 和 test2。

首先，登录 test1 账户。然后，在会员中心或直接构造访问重置密码问题的URL，并将其中的 id 参数修改为目标账户 test2 的会员ID（mid）。

发送请求后，系统会生成一个用于重置 test2 账户密码的 key。成功获取该 key 值后，即可利用它直接修改 test2 账户的密码。

这个漏洞的成因在于，重置流程的不同步骤（如验证安全问题、使用key修改密码）之间，没有严格校验执行这些步骤的会话是否属于同一用户，或者前置步骤是否已完成。

2.2 挖掘思路

1. 测试步骤间状态关联性校验：手动尝试直接访问重置流程后续步骤的URL（例如 /reset/step3），跳过前面的验证步骤。观察系统是否允许直接访问，并在后续请求中，检查是否缺少对前置步骤已完成的验证（例如，缺少一个能证明你已通过第一步验证的 Token 或 Session 标识）。
2. 操作参数以便越权：分析每一步请求中用于标识用户或状态的参数（如 user_id、temp_token）。尝试修改这些参数（例如递增或递减 user_id），查看是否能切换到其他用户的重置流程中。同时，检查第一步生成的 Token，是否在后续步骤的请求中被正确校验并与当前操作用户绑定。

3、鉴权不严使用简单可预测的用户标识符

许多系统在对用户身份进行认证时，会使用简单的参数作为用户的唯一标识，而这类标识容易被攻击者预测或枚举。例如，某些系统直接将数字 USERID 作为密码重置的标识，且缺少严格的权限校验。

3.1 漏洞利用

在对某大型购物网站进行流量监听时，发现一个用户信息接口的响应如下：

在响应体的JSON数据中，包含了控制UI显示的参数："showResetPassword": false 和 "showModifyEmails": false。其值 false 表示当前用户角色被禁止使用密码重置和邮箱修改功能。

第一步：前端越权。在Burp Suite中拦截该流量包，将响应包中的这两个参数值修改为 true。

刷新页面后，原本隐藏的“Modify email”和“Reset Password”选项会出现在用户管理菜单中。

这里的漏洞在于，后端接口返回的 showResetPassword 字段仅用于前端UI决策，未在后端任何鉴权逻辑中二次校验。攻击者通过篡改响应包即可“骗过”前端，渲染出本无权限使用的功能按钮。

第二步：后端越权。点击重置密码按钮，对自己控制的账户发起重置，系统返回200状态码并提供了一个有效的密码重置链接。

访问该链接，确认可以成功重置密码。

此时，拦截密码重置的接口请求包，发现其请求体非常简单：{ "userId": 9438867, "resetAccessKey": false }，仅包含目标用户的数字ID，没有任何会话Token、密码等额外的鉴权参数。

第三步：篡改标识，横向越权。重新抓取重置密码的请求包，将 userId 参数修改为另一个受害用户的ID（如9438868），放行请求。结果密码修改成功，攻击者可以借此登录受害用户的账户。

这个案例暴露了双重漏洞：一是前端权限控制可被绕过；二是后端仅依赖可预测、单调递增的数字 userId 进行鉴权，且未校验当前会话是否有权操作该 userId，导致攻击者通过遍历ID即可批量重置任意用户密码。这类问题在安全审计中需要特别关注。

3.2 挖掘思路

1. 收集令牌样本：通过正常功能（密码重置、邮箱验证）反复触发令牌生成，或从日志、错误信息中寻找泄露的令牌样本。
2. 分析模式与结构：
   • 观察组成：令牌是纯数字、字母数字混合，还是包含特殊字符？
   • 尝试解码：对令牌进行Base64、Hex等常见解码，查看内部结构。
   • 对比分析：将多个令牌样本并列，对比每一位字符的变化，寻找固定部分和规律变化的部分。
3. 破解生成算法：
   • 时间戳：纯数字令牌可能基于时间戳（10位或13位）。
   • 哈希值：32/64位十六进制字符串可能是MD5或SHA-256等哈希值，可尝试猜测其原始输入（用户ID+时间戳+盐）。
   • 序列号：若令牌样本呈连续或等差数列，可能是简单的自增序列。
   • 前端分析：在前端JavaScript代码中下断点，跟踪令牌的生成算法。

4、账号与校验参数未绑定

密码重置流程通常需要向用户发送验证凭证（如Token、验证码）。如果接收端（手机号、邮箱）由客户端提供且可篡改，或者验证凭证与最初申请者的身份未严格绑定，就可能导致凭证被发送至攻击者处，或被用于重置其他用户密码。

4.1 漏洞利用

案例一：接收端参数可控

在密码重置页面，输入目标账号并选择“邮箱找回”。在获取验证码步骤进行抓包。

拦截请求后发现，接收验证码的邮箱地址是请求包中的一个参数（如 dest），并且该参数可控。将其直接篡改为攻击者自己的邮箱。

放行后，验证码成功发送到了攻击者邮箱。随后，在提交验证码的请求中，也需要将标识邮箱的参数修改为攻击者邮箱。系统仅校验了“该邮箱收到的验证码”是否正确，而未校验“该邮箱是否属于最初申请重置的账号”。通过验证后，即可正常完成后续密码重置步骤。

案例二：参数污染导致验证码转发

在发送验证码的请求中，尝试进行参数污染。例如，原始参数为 phone=victim_number，可添加一个额外的 phone=attacker_number 参数。

某些系统在处理多个相同参数时，可能会将验证码同时发送到两个号码，或者发送到最后一个指定的号码，从而使攻击者收到验证码。

案例三：凭证与账号绑定不严

在完整流程中，用户获取并验证验证码后，系统会生成一个临时的重置凭证（ticket）。在最终提交新密码时，需要携带此凭证。

漏洞在于，服务端在最终重置密码时，只校验了凭证（ticket）本身是否有效、是否被使用，但没有严格校验这个凭证是由哪个用户账号申请生成的。攻击者可以：

1. 为可控的账号A申请重置，获取有效凭证 Ticket_A。
2. 在 Ticket_A 的有效期内，立即为受害账号B发起重置请求。
3. 在最终修改密码的步骤中，拦截请求，将请求中标识用户的参数（如 accountId）改为B的ID，但携带的凭证仍为 Ticket_A。

如果服务端通过，则成功利用账号A的凭证重置了账号B的密码。

4.2 挖掘思路

1. 还原正常流程：完整走一遍密码重置流程，记录每一步的请求与响应。
2. 识别接收端参数：在“发送验证码”的请求中，仔细查找直接或间接指定接收端的参数。
   • 直接参数：phone, mobile, email, to 等。
   • 间接参数：user_id, username, account 等（系统可能通过此ID去数据库查询绑定的联系方式）。
3. 测试参数可篡改性：
   • 直接替换：将接收端参数改为攻击者控制的地址。
   • 间接关联：修改用户标识参数，尝试让系统向另一个用户绑定的联系方式发送验证码。
   • 参数污染：添加多个接收端参数。
4. 测试步骤间关联性：尝试在第一步输入用户A，第二步篡改请求将验证码发往用户B的联系方式，看系统是否校验一致性。
5. 测试验证码绑定关系：用攻击者收到的、本应属于用户A的验证码，去尝试直接重置用户B的密码，检验系统是否只验“码”不验“人”。