记一次神奇的渗透测试之逻辑缺陷
字数 1510 2025-08-04 22:51:28

逻辑缺陷渗透测试实战教学文档

1. 漏洞概述

本案例展示了一个通过逻辑缺陷绕过验证码验证机制,最终实现密码重置的渗透测试过程。该漏洞存在于一个网站的密码找回功能中,攻击者通过SQL注入原理绕过验证码验证,成功重置任意用户密码。

2. 漏洞发现过程

2.1 前期信息收集

  1. 账户枚举:通过不同错误提示判断账户存在性

    • 尝试admin123/admin123 → "账号密码错误"提示
    • 尝试admin/admin → 不同错误提示,确认admin账户存在但受网络限制
  2. 密码找回功能分析

    • 访问路径:https://x.x.x.x/portal/register/forgetPassword
    • 功能特点:输入存在的账户名后,系统自动填充关联手机号

2.2 验证码机制分析

  1. 正常流程

    • 点击"获取验证码"发送短信
    • 输入5位数验证码进行验证
    • 验证码即时验证(无需点击确认按钮)
  2. 异常发现

    • 使用AWVS扫描发现的测试payload中包含验证码94102
    • 直接输入该验证码显示"验证码已过期"

3. 漏洞利用过程

3.1 验证码绕过技术

  1. SQL注入原理应用

    • 在验证码输入框尝试SQL注入payload:1' or 1='1
    • 观察到系统卡顿,验证码未被清除
  2. 分步利用

    • 步骤1:输入万能密码1' or 1='1,触发系统卡顿
    • 步骤2:刷新页面,验证码状态保留
    • 步骤3:将验证码替换为94102,此时验证通过
    • 步骤4:设置新密码并提交

3.2 权限限制绕过

  1. 发现限制

    • 成功重置admin密码但登录仍受网络限制
    • 确认admin账户需要内网环境才能登录
  2. 扩大攻击面

    • 通过网站公告收集公司补充供方单位信息
    • 查询这些单位的统一社会信用代码(18位)作为账户名
    • 确认多个账户存在并成功重置密码

4. 漏洞原理分析

4.1 技术根本原因

  1. 验证码验证逻辑缺陷

    • 验证码验证与密码修改操作未原子化执行
    • 验证通过后未正确校验后续操作的有效性
  2. SQL注入漏洞

    • 验证码验证环节存在SQL注入漏洞
    • 通过布尔型注入绕过验证机制
  3. 会话状态管理不当

    • 验证状态在页面刷新后仍保持有效
    • 缺乏足够的CSRF防护措施

4.2 系统架构问题

  1. 验证码存储问题

    • 验证码可能存储在数据库中而非Redis等缓存系统
    • 缺乏合理的失效时间设置
  2. 事务处理缺失

    • 验证码验证与密码修改操作未在同一事务中
    • 导致验证通过但密码未成功修改的矛盾状态

5. 修复建议

5.1 代码层面修复

  1. 验证码机制改进

    • 使用Redis存储验证码并设置短有效期(如5分钟)
    • 实现验证码一次性使用,验证后立即失效
  2. 输入验证强化

    // 示例:验证码输入验证
    if(!verificationCode.matches("^\\d{5}$")) {
        throw new InvalidVerificationCodeException();
    }
    
  3. 事务完整性

    • 将验证码验证和密码修改纳入同一事务
    • 任一环节失败则整体回滚

5.2 系统架构改进

  1. 权限分离

    • 区分内网管理账户和普通用户账户
    • 实现不同级别的认证机制
  2. 操作审计

    • 记录所有密码修改操作的完整日志
    • 包括IP地址、时间戳、操作步骤等
  3. 频率限制

    • 实现基于IP和账户的尝试次数限制
    • 例如:1小时内最多5次密码找回尝试

6. 渗透测试方法论总结

  1. 信息收集阶段

    • 全面收集目标系统的各类信息
    • 包括用户账户、功能接口、错误提示差异等
  2. 漏洞探测技巧

    • 关注系统不同响应间的细微差异
    • 善于将传统漏洞(如SQL注入)应用于非传统场景
  3. 权限提升思路

    • 当直接目标受阻时,寻找间接路径
    • 通过关联信息扩大攻击面
  4. 报告撰写要点

    • 清晰记录每个步骤的操作和系统响应
    • 提供可复现的漏洞利用路径
    • 给出具体可行的修复建议

附录:关键Payload示例

  1. 验证码绕过Payload

    1' or 1='1
    
  2. AWVS测试Payload

    /portal/register/forgetPassword?account=4111111111111111&btn=%e8%8e%b7%e5%8f%96%e9%aa%8c%e8%af%81%e7%a0%81&code=94102&Cto=d47867b3be2f4f67aa693ddde6d7904d&msgCode=94102&password=g00dPa%24%24w0rD&phone=555-666-0606&repassword=g00dPa%24%24w0rD
    
  3. 成功利用流程

    1. 访问/forgetPassword,输入已知账户
    2. 获取验证码(触发短信发送)
    3. 输入1' or 1='1,等待系统卡顿
    4. 刷新页面,替换验证码为94102
    5. 设置新密码并提交
    6. 使用新密码登录目标账户
    
逻辑缺陷渗透测试实战教学文档 1. 漏洞概述 本案例展示了一个通过逻辑缺陷绕过验证码验证机制,最终实现密码重置的渗透测试过程。该漏洞存在于一个网站的密码找回功能中,攻击者通过SQL注入原理绕过验证码验证,成功重置任意用户密码。 2. 漏洞发现过程 2.1 前期信息收集 账户枚举 :通过不同错误提示判断账户存在性 尝试 admin123/admin123 → "账号密码错误"提示 尝试 admin/admin → 不同错误提示,确认admin账户存在但受网络限制 密码找回功能分析 : 访问路径: https://x.x.x.x/portal/register/forgetPassword 功能特点:输入存在的账户名后,系统自动填充关联手机号 2.2 验证码机制分析 正常流程 : 点击"获取验证码"发送短信 输入5位数验证码进行验证 验证码即时验证(无需点击确认按钮) 异常发现 : 使用AWVS扫描发现的测试payload中包含验证码 94102 直接输入该验证码显示"验证码已过期" 3. 漏洞利用过程 3.1 验证码绕过技术 SQL注入原理应用 : 在验证码输入框尝试SQL注入payload: 1' or 1='1 观察到系统卡顿,验证码未被清除 分步利用 : 步骤1:输入万能密码 1' or 1='1 ,触发系统卡顿 步骤2:刷新页面,验证码状态保留 步骤3:将验证码替换为 94102 ,此时验证通过 步骤4:设置新密码并提交 3.2 权限限制绕过 发现限制 : 成功重置admin密码但登录仍受网络限制 确认admin账户需要内网环境才能登录 扩大攻击面 : 通过网站公告收集公司补充供方单位信息 查询这些单位的统一社会信用代码(18位)作为账户名 确认多个账户存在并成功重置密码 4. 漏洞原理分析 4.1 技术根本原因 验证码验证逻辑缺陷 : 验证码验证与密码修改操作未原子化执行 验证通过后未正确校验后续操作的有效性 SQL注入漏洞 : 验证码验证环节存在SQL注入漏洞 通过布尔型注入绕过验证机制 会话状态管理不当 : 验证状态在页面刷新后仍保持有效 缺乏足够的CSRF防护措施 4.2 系统架构问题 验证码存储问题 : 验证码可能存储在数据库中而非Redis等缓存系统 缺乏合理的失效时间设置 事务处理缺失 : 验证码验证与密码修改操作未在同一事务中 导致验证通过但密码未成功修改的矛盾状态 5. 修复建议 5.1 代码层面修复 验证码机制改进 : 使用Redis存储验证码并设置短有效期(如5分钟) 实现验证码一次性使用,验证后立即失效 输入验证强化 : 事务完整性 : 将验证码验证和密码修改纳入同一事务 任一环节失败则整体回滚 5.2 系统架构改进 权限分离 : 区分内网管理账户和普通用户账户 实现不同级别的认证机制 操作审计 : 记录所有密码修改操作的完整日志 包括IP地址、时间戳、操作步骤等 频率限制 : 实现基于IP和账户的尝试次数限制 例如:1小时内最多5次密码找回尝试 6. 渗透测试方法论总结 信息收集阶段 : 全面收集目标系统的各类信息 包括用户账户、功能接口、错误提示差异等 漏洞探测技巧 : 关注系统不同响应间的细微差异 善于将传统漏洞(如SQL注入)应用于非传统场景 权限提升思路 : 当直接目标受阻时,寻找间接路径 通过关联信息扩大攻击面 报告撰写要点 : 清晰记录每个步骤的操作和系统响应 提供可复现的漏洞利用路径 给出具体可行的修复建议 附录:关键Payload示例 验证码绕过Payload : AWVS测试Payload : 成功利用流程 :