逻辑漏洞之密码重置

本文详细分析了多种密码重置过程中的安全漏洞,包括仅验证账号存在性、验证码可预测及爆破等,并提出了针对性的修复建议。

密码找回验证条件可社工

1 只验证帐号是否存在即可修改密码

2 只验证帐号与邮箱地址是否匹配即可修改密码

3 只验证帐号与手机号是否匹配即可修改密码

密码修改页面可预测

案例介绍: 问题出现在忘记密码处,可以通过手机找回邮箱找回密码两种方式获得指定帐户的新密码设置权限

进入忘记密码,填写想要获取权限帐号的ID

获得url



选择邮箱找回


获得url:


系统已将新密码设置url发送给邮箱

此时只需要将前面获取的url修改一下


即可获得设置该用户新密码的权限


验证码可爆破

案例介绍

乐峰网用户认证体系存在逻辑漏洞,可修改任意用户密码

1 找回密码部分:两种方式,mail和phone,但是验证码都是6位数字,(邮箱)是24小时有效。可以暴力

2 使用后的验证码并未销毁,24小时内可以再次使用,这里就很危险了,只要你找回了密码,24小时内,还可以被修改

攻击方式:

1 提交任意用户的修改密码请求,暴力破解验证码(6位数字,24小时内有效),成功率很客观

2 枚举24小时之内修改过密码的用户,如图:



修改密码未校验用户

案例介绍

万网某管理系统密码找回结构控制不严格,导致可修改此管理系统任意账户密码。

自己新买一个域名要做备案,可惜申请时密码忘记了,故找回密码,收到找回邮件链接如下:


按照提示修改自己密码成功。。

职业病原因,顺手将url中邮箱地址替换成admin@hichina.com修改,悲剧,修改成功。。。

如图:



也就是说,只要知道确实存在的账户,即可直接修改该帐号密码。

密码重置验证码接收帐号由客户端决定

案例介绍

任意用户密码重置(遍历可批量操作)


重置用户资金密码,修改成自己邮箱


重置资金密码成功


修改返回包绕过验证码找回密码

案例介绍

P2P金融安全之珠宝贷存在找回密码/关键凭证修改逻辑漏洞

提交修改密码申请,填写手机号,图片验证码以及登录密码如图:


用burp截包,点击提交:


返回包如图:


修改返回包如图:


绕过验证出现修改密码界面:


重置密码新密码出现在返回的数据包中

案例介绍

沃的城市生活IOS逻辑漏洞可重置登录任意号码

1 点击重置密码


2 重置后的新密码返回在数据回包中



密码重置验证码出现在返回数据包中

案例介绍

中粮集团中粮悦生活app(在苹果appstore下载的,安卓未测试)在修改密码时存在逻辑漏洞,可直接通过服务器返回的数据包获取验证码,从而注册任意手机号码和修改任意用户的密码。

1 填写电话号码



2 设置代理,抓包,点击获取验证码,查看数据包


3 填写验证码,成功修改密码


密码重置验证码多人公用

案例说明

天天果园账户逻辑漏洞,自己的验证码修改别人的密码

1 登录网站点击 找回密码 输入自己的帐号,点击下一步。


2 在同一网页标签打开另一网页,找回密码,输入目标帐号,点击下一步。


3 自己的帐号页面点击获取验证码。


4 将自己收到的验证码输入目标帐号验证码处,点击下一步。


5 完成,密码重置。


修复方案

1 减少验证码有效时间

2 使用后即销毁

3 增加验证码复杂程序,整个md5 不困难吧,

4 限制该功能单个ip提交频率

5 对重要参数加入验证码同步信息或时间戳;

6 重置密码后,新密码不应返回在数据包中。

7 接收验证码的帐号由服务端提供,不能信任客户端提交的数据



<think> 嗯,用户正在深入学习网络安全中的密码重置漏洞,特别是漏洞的运用和参数拼接问题。从对话历史看,用户已经掌握了一些基础概念(如未授权接口、参数遍历),现在需要更落地的技术细节和防御方案。用户可能正在准备渗透测试实践或CTF比赛,需要实战性强的解决方案。 用户提供的四个引用很有价值: 引用[1]提到Host头投毒漏洞——攻击者篡改Host头构造恶意重置链接,这属于服务端信任链设计缺陷。需要强调反向代理配置和链接签名机制。 引用[2]指出密码修改功能的设计缺陷,特别是隐藏参数可编辑的问题,这引出了参数绑定和权限验证的重要性。 引用[3]强调身份验证功能点的关键性,需要分层防御设计。 引用[4]提到SQL注入等传统漏洞虽然少见,但可通过响应包篡改绕过,这提示我需要补充响应校验机制。 用户深层需求可能是想构建系统化的防御体系。因此我决定从漏洞原理、攻击手法、防御方案三个维度展开: 1. 漏洞原理部分突出信任链断裂(如Host校验缺失)和参数绑定缺失两大核心 2. 攻击手法用HTTP请求示例展示参数拼接技巧,包括邮箱遍历和响应篡改 3. 防御方案引入多因素验证框架(数学表达$T = (UID \oplus t) \parallel SMS$强化技术严谨性) 特别要注意数学表达格式: - 行内公式如令牌绑定算法写成$(UID \oplus timestamp)$ - 独立公式如防御模型用$$T_{auth} = V_{sms} \oplus V_{token}$$单独呈现 最后生成的问题要延续技术纵深:"重置令牌的密码学保护"延伸加密方案,"自动化审计"对接DevSecOps流程。用户明显是技术型学习者,问题需保持专业深度。 </think> 以下是针对密码重置漏洞的系统化分析,结合漏洞原理、攻击手法及防御方案: --- ### 一、漏洞核心原理 1. **信任链断裂** - 重置流程依赖用户可控参数(如邮箱、手机号),未与服务端会话绑定[^1][^2] - 攻击者篡改请求中的`Host`头,构造恶意重置链接诱导用户点击[^1] ```http GET /reset?token=abc HTTP/1.1 Host: attacker.com // 篡改Host指向恶意服务器 ``` 2. **权限控制缺失** - 密码修改接口允许未授权访问,或通过隐藏参数(如`user_id=hidden_field`)枚举用户[^2] - 验证逻辑未关联二次因子(如短信验证码未绑定用户会话)[^3] 3. **参数拼接漏洞** | 攻击类型 | 手法示例 | 风险等级 | |----------------|-----------------------------|----------| | 邮箱遍历 | `email=victim@x.com → attacker@x.com` | ⭐⭐⭐⭐ | | 响应包篡改 | 修改HTTP响应`{“success”:false}`→`true`[^4] | ⭐⭐⭐⭐ | | 令牌泄漏 | 重置链接中Token未加密(`reset?token=123`) | ⭐⭐⭐⭐ | --- ### 二、攻击运用与拼接手法 #### 案例1:Host头投毒攻击[^1] ```mermaid sequenceDiagram Attacker->>Server: 伪造Host头请求重置链接 Server->>Victim: 发送含恶意域名的重置邮件 Victim->>Attacker: 点击链接泄漏Token Attacker->>Server: 用Token重置密码 ``` #### 案例2:参数覆盖漏洞 ```http POST /change_password HTTP/1.1 ... user_id=123&new_pass=Hacked! // 篡改隐藏的user_id参数 ``` #### 案例3:逻辑绕过 - **步骤1**:正常请求重置验证码 ```http POST /send_sms HTTP/1.1 {"phone":"13800138000"} ``` - **步骤2**:篡改响应包绕过验证 ```http HTTP/1.1 200 OK {"code":200, "verified":true} // 修改为已验证状态 ``` --- ### 三、系统性防御方案 #### 1. 身份绑定机制 - **会话关联**:重置流程绑定会话ID,验证流程所有权 $$ \text{Session}_{ID} \xrightarrow{\text{verify}} \text{User}_{ID} $$ - **令牌加密**:生成带签名的JWT令牌 $$ \text{Token} = \text{sign}( \text{User}_{ID} + \text{Timestamp} + \text{IP} ) $$ #### 2. 参数安全策略 | 参数类型 | 防御措施 | 实现示例 | |------------|-----------------------------------|------------------------------| | Host头 | 反向代理强制覆盖Host | Nginx配置`proxy_set_header Host $host;` | | 用户标识 | 从会话获取而非请求参数 | `user_id = session.get("uid")` | | 验证码 | 服务端绑定用户并设置有效期(5分钟)| `REDIS.set("code:13800138000", "1987", 300)` | #### 3. 操作验证加固 ```python def reset_password(request): if not verify_session(request): return 403 # 会话校验 if not check_sms_code(request.phone, request.code): return 401 # 验证码绑定 if request.ip != session.last_ip: return 412 # IP一致性检查 # 执行密码重置 ``` #### 4. 审计与测试要点 - **自动化扫描**:用Burp Suite测试参数覆盖、响应篡改 - **人工验证**: 1. 修改请求中的邮箱/手机号是否导致目标错误 2. 旧密码是否仍可登录(防御平行越权) 3. 重置链接是否包含可预测Token --- ### 四、企业级最佳实践 ```http ### 安全的重置请求示例 POST /api/reset-password HTTP/1.1 Authorization: Bearer <会话Token> X-Request-Sign: HMAC_SHA256(密钥, 时间戳+路径) { "new_password": "SafePass!2023", "sms_code": "198273", // 后端校验与用户绑定 "timestamp": 1689148800 // 防重放 } ``` **关键控制点**: 1. 强制HTTPS传输 2. 关键操作日志记录(IP/设备指纹) 3. 同一账号24小时内限3次操作 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值