authbypass-authentication-flaws

SKILL: Authentication Bypass — Expert Attack Playbook

AI LOAD INSTRUCTION: 高级身份验证绕过技术指南。涵盖基于 SQL 注入的登录绕过、密码重置缺陷、Token 可预测性、账号枚举、暴力破解绕过以及多因素身份验证（MFA）绕过。与 JWT/OAuth（详见 ../jwt-oauth-token-attacks/SKILL.md）相互独立，本 Skill 聚焦于登录机制本身的安全性。

0. AUTHORIZED CREDENTIAL TEST PLANNING

在完成路由条目筛选后，默认凭据、用户名变体、焦点端口和字典规模的拟定统一在本节集中处理。

服务优先极简凭据集 (Service-first tiny sets)

服务类型	常用用户名	常用密码
phpMyAdmin	root、admin	留空、root、phpmyadmin、admin
FTP	ftp、admin、test	留空、ftp、admin、123456
SSH	root、admin、服务账号名	root、admin、季节性变体
MySQL	root、mysql	留空、root、mysql
Tomcat / Java 管理端	tomcat、admin、manager	tomcat、admin、s3cret
WebLogic	weblogic、admin	weblogic、welcome1、admin

用户名分类 (Username classes)

分类	示例
通用管理员	admin、administrator、root、test、guest
运维 / 运维支持	dev、ops、sysadmin、service、backup
基于姓名	firstname、lastname、f.lastname、first.last
派生自邮箱	企业邮箱格式的前缀部分
基于产品名	tomcat、weblogic、jenkins、gitlab

字典规模与焦点端口 (Wordlist sizing and port focus)

场景	推荐字典规模	选型原因
默认后台管理面板	5 到 50 个密码	在此类场景中，默认凭据比超大字典更高效
已知产品的内部服务	厂商特定极简集	比通用字典具有更好的信号/噪声比
防护较弱的 C 端登录	Top 20 或 Top 100	快速验证效率高
存在速率限制的登录	极简列表 + Header / 轮询策略	尽量节省尝试次数
离线 Hash 破解	超大字典	线上暴破规则在此场景下不适用

优先关注常见端口及服务暴露面：80/443/8080/8443 管理面板，22 SSH，21 FTP，以及 3306/5432/6379/27017 数据或管理服务。

---

1. SQL INJECTION LOGIN BYPASS

虽属经典漏洞，但在旧版系统、自定义 ORM 和原生 SQL 查询代码中依然屡见不鲜：

-- 基本绕过（假设 admin 用户在数据库第一行）：
Username: admin'--
Password: anything
→ Query: SELECT * FROM users WHERE user='admin'--' AND pass='anything'

-- 通用绕过（以数据库中第一个用户身份登录）：
Username: ' OR '1'='1'--
Password: anything
→ Query: SELECT * FROM users WHERE user='' OR '1'='1'--' AND pass='anything'

-- 盲注测试：确认是否奏效？
Username: ' OR 1=1--
Username: admin' OR 'a'='a
Username: 1' OR '1'='1'/*
Username: 1 or 1=1

须对每个输入字段分别测试 —— 可能仅有一个字段存在漏洞。

---

2. PASSWORD RESET VULNERABILITIES

可猜测 / 可预测的重置 Token (Guessable / Predictable Reset Tokens)

检查重置 Token 是否基于以下规则生成：

- 时间戳：token=1691234567890 (Unix 时间戳)
- 递增序号：token=1001, 1002, 1003
- MD5(邮箱)：echo -n "user@example.com" | md5sum
- MD5(用户名+时间戳)：可逆
- 短 Token (4-6 位数字)：可被暴力破解

测试方法：连续请求 3 次重置邮件，对比分析 Token 的生成规律。

重置 Token 未设置过期时间 (Reset Token Not Expiring)

1. 发起密码重置请求 → 通过邮箱获取 Token
2. 等待 48 小时以上（Token 按理应当已失效）
3. 使用旧 Token 进行重置 → 确认是否依然有效？

重置 Token 重复使用 (Reset Token Reuse)

1. 请求重置 → 获取 Token T1
2. 使用 T1 完成密码重置
3. 再次使用 T1 → 确认是否仍能再次生效？

重置邮件中的 Host 头注入 (Host Header Injection in Reset Email)

当应用程序利用 Host 请求头生成重置链接时：

POST /forgot-password HTTP/1.1
Host: attacker.com           ← 注入攻击者的域名
Content-Type: application/x-www-form-urlencoded

email=victim@target.com

→ 重置邮件发送给受害者，但其中的链接指向 attacker.com/reset?token=VICTIM_TOKEN
→ 受害者点击链接 → 攻击者捕获到受害者的 Token

测试方法：发送密码重置请求时修改 Host: 头，检查收到的邮件中重置链接的指向。

HTTP Referer 泄露重置 Token (Password Reset Token in Referer)

1. 请求重置 → 访问带有 Token 的重置页面 URL
2. 重置页面加载了第三方资源（如统计代码、字体库）
→ Referer 请求头泄露 URL：https://target.com/reset?token=TOKEN
→ 第三方服务器在日志中记录并获取该 Token

无需当前密码即可修改密码 (Password Change Without Current Password)

PUT /api/user/password
{"new_password": "hacked"}
→ 接口未校验 current_password 字段？
→ 配合 CSRF 漏洞可实现账号劫持

---

3. ACCOUNT ENUMERATION

识别有效的用户名/邮箱可为针对性攻击提供便利：

错误提示信息差异 (Error Message Difference)

用户名不存在 → "未找到该用户"
用户名正确但密码错误 → "密码不正确"
→ 即可枚举有效账号

响应时间差异 (Response Time Difference)

用户名不存在 → 响应极快（无需检索数据库或计算 Hash）
用户名存在 → 响应略慢（包含数据库查询及密码 Hash 比对）
→ 时间侧道/时序盲注 (Timing oracle)

密码重置流程差异 (Password Reset Flow)

POST /forgot-password {"email": "nonexistent@example.com"}
→ "若该邮箱存在，我们已发送重置链接"（规范做法）
对比：
→ "该邮箱未注册"（存在枚举风险）

注册接口响应 (Registration Endpoint)

POST /register {"email": "victim@example.com"}
→ "邮箱已被注册" → 证实账号存在
对比：
→ 无论是否存在均提示 "验证邮件已发送" → 不存在枚举风险

---

4. BRUTE FORCE BYPASS

失败 N 次锁定后自动重置机制 (Lockout After N Attempts Then Resets)

连续失败 10 次触发锁定 → 尝试 9 次错误密码 → 停顿
等待重置周期结束（通常为 30 分钟或 1 小时）
→ 再尝试 9 次 → 循环往复 → 绕过永久锁定

基于 IP 的锁定绕过 (IP-Based Lockout Bypass)

X-Forwarded-For: 1.1.1.1       ← 每次请求更换 IP
X-Real-IP: 2.2.2.2
通过在 Header 中轮询 IP 地址实现绕过

用户名遍历 vs 密码遍历 (Username Cycling vs Password Cycling)

常规暴破：对单一用户尝试多个密码 → 容易触发锁定
反向暴破（撞库）：使用同一弱密码对大量用户进行尝试
→ 针对所有用户尝试 "password123" → 筛出使用弱密码的账号
→ 不会触发单账号锁定机制

凭据撞库 (Credential Stuffing)

利用 HaveIBeenPwned 等已泄露数据对目标进行测试：

# 工具：Hydra、Burp Intruder 或自定义脚本
hydra -C credentials.txt https-post-form://target.com/login:"username=^USER^&password=^PASS^":"error message"

---

5. MULTI-FACTOR AUTHENTICATION BYPASS

2FA 完成前已签发 Session Cookie (Session Cookie Before 2FA Completion)

流程：登录（密码正确） → 重定向至 2FA 页面 → 输入验证码
漏洞点：完成密码校验后即已设置 Session Cookie，尚未强制校验 2FA。
→ 直接使用该 Session Cookie 访问 /dashboard 路径
→ 完全跳过 2FA 校验页面

2FA 验证码暴力破解 (2FA Code Brute Force)

4-6 位数字 TOTP 验证码最多仅 1,000,000 种组合
若 2FA 校验环节未设置速率限制：
→ 暴破所有验证码组合（工具：Burp Intruder，按顺序遍历）
→ TOTP 时间窗口：标准 30 秒窗口，部分服务端允许前后相邻的时间窗口

仅在敏感操作校验 2FA 而登录未校验 (2FA on Critical Actions Not On Login)

登录环节无需 2FA，但：
DELETE /account 或 POST /transfer 等操作要求 2FA
测试点：相关操作是否单独校验 2FA，还是仅依赖登录态？
→ 若仅在登录时校验：只需登录一次 → 后续操作可能无需二次验证 2FA

2FA 备用码滥用 (2FA Backup Code Abuse)

系统生成的备用码（通常为 8-10 个一次性代码）
测试点：
→ 备用码是否有频率限制？
→ 备用码是否可以重复使用？
→ 备用码长度较短（如 6-8 位）？若无频控可被暴破

2FA 验证码重复使用 (2FA Code Reuse)

TOTP 验证码理论上仅一次有效
→ 重复提交同一 TOTP 验证码 → 观察第二次是否依然有效
→ 若服务端未记录已使用的 Code，则存在重放攻击风险

---

6. OAUTH / SSO ACCOUNT TAKEOVER PATTERNS

Email 声明信任风险 (Email Claim Trust)

1. 在攻击者可控的 OAuth Provider 处注册账号
2. 设置 email 声明为 victim@target.com
3. 通过该 Provider 在目标系统登录/绑定账号
→ 若目标服务端未经验证直接信任 email 声明 → 导致账号合并/被劫持

SSO 绑定后密码策略未更新 (Password Doesn't Apply After SSO Link)

1. 用户绑定 Google SSO 登录
2. 用户使用 "忘记密码" 功能（纯 SSO 账号初始无密码）
3. "忘记密码" 流程 → 是否允许为纯 SSO 账号重置并设置本地密码？
→ 若成功设置本地密码 → 可绕过 SSO 机制实现直接登录

---

7. USERNAME / PASSWORD FIELD MANIPULATION

长密码 DoS 导致的绕过 (Long Password DoS → Bypass)

部分应用在将密码存入数据库前会先进行 Hash 计算。
bcrypt 存在 72 字节的输入限制 —— 超出 72 字节的部分将被截断丢弃。
测试攻击：
→ 使用 100 个 "A" 字符注册密码
→ 使用 72 个 "A" 字符登录 → 生成相同 Hash → 登录成功
→ 使用 71 个 "A" + "任意不同字符" 尝试登录 → 若存在截断，只要前 72 字符一致即可匹配成功

用户名空字节注入 (Null Byte in Username)

username=admin%00 对比 username=admin
→ 在某些字符串比较逻辑中发生空字节截断
→ 在 C 语言风格的字符串比较中，"admin\0attacker" 会被视作 "admin"

Unicode 字符标准化 (Unicode Normalization)

用户名："ⓢcott" → 标准化为 "scott" → 冒充 "scott" 账号
用户名："admin"（使用各种与 a,d,m,i,n 外观一致的 Unicode 同形字符）

---

8. SESSION MANAGEMENT FLAWS

登出后 Session 未失效 (Session Not Invalidated on Logout)

1. 登录账号 → 捕获 Session Cookie
2. 执行登出操作
3. 重放之前捕获的 Session Cookie → 是否仍然有效？
→ 说明服务端未销毁 Session

权限变更时 Session 未重新生成 (Session Not Regenerated on Privilege Change)

1. 以低权限身份登录 → 获取 Session Cookie
2. 管理员提升了你的账号权限
3. 旧的 Session Cookie 是否直接具备了管理员权限？
→ Session 未重新生成 → 旧 Token 直接继承了新权限

可预测的 Session Token (Predictable Session Tokens)

Token: base64(userid+timestamp) → 可逆解密
Token: 递增整数 → Session ID = 你的 Session ID +/- 较小数值
Token: 短随机数 (32-bit 熵) → 可被暴力破解

---

9. AUTHENTICATION TESTING CHECKLIST

□ 在登录字段尝试 SQL 注入 (' OR 1=1--)
□ 测试密码重置：Predict Token、Host 头注入、Referer 泄露
□ 通过错误提示 / 响应时间测试账号枚举
□ 检查 2FA：跳过步骤（直接访问 URL）、暴破验证码、重复使用验证码
□ 测试防暴破机制：X-Forwarded-For 绕过、反向撞库
□ 检查登出后 Session 是否失效
□ 检查权限变更后 Session 是否重新生成
□ 测试修改密码接口是否校验当前密码
□ 测试超长密码（bcrypt 72 字节截断测试）
□ OAuth/SSO：测试 Email 声明信任、SSO 绑定后本地密码设置
□ 检查 remember_me Token：有效期多长、是否可撤销、是否可预测？

---

10. PASSWORD RESET ATTACK MATRIX (22 Patterns)

#	攻击模式	描述
1	可预测的重置 Token	Token 基于时间戳、用户 ID 或递增序号生成
2	Token 未绑定用户	使用给用户 A 生成的 Token 重置用户 B 的密码
3	Token 在响应体中返回	重置 Token 在 HTTP 响应中直接返回（非仅邮件发送）
4	Token 在 URL 参数中	重置链接中的 Token 借由 Referer 头泄露给第三方资源
5	Token 永不失效	Token 长期或永久保持有效
6	Token 重复使用	同一 Token 可多次成功重置密码
7	短/可暴破的 Token	4-6 位纯数字验证码且缺乏频控措施
8	通过 Host 头注入重置链接	Host: attacker.com → 重置邮件发送包含攻击者域名的链接
9	重新注册覆盖已有账号	使用相同邮箱注册 → 覆盖原有密码
10	步骤跳过（纯前端限制）	通过直接修改 URL 跳过验证，直达 "设置新密码" 步骤
11	响应包篡改	在代理工具中将 {"status":"fail"} 修改为 {"status":"success"}
12	验证码在响应体中返回	SMS/邮箱验证码在 API 响应包中直接泄露
13	并行会话重置	为用户 A 发起重置，但在用户 B 的 Session 中完成操作
14	邮箱/手机参数污染	email=victim@x.com&email=attacker@x.com
15	Unicode 标准化缺陷	admin@target.com vs ADMIN@target.com vs Unicode 混淆字符
16	重置逻辑中的 SQL 注入	密码重置查询中的邮箱字段存在注入漏洞
17	重置接口存在 IDOR	在重置确认请求中修改目标用户 ID
18	跨协议重置突破	移动端 API 未校验与 Web 端相同的 Token
19	默认密保问题漏洞	密保答案易被猜解，且缺少频控限制
20	Token 生成竞争条件	多个并发请求生成完全相同的 Token
21	登出未销毁重置 Token	执行登出操作后，先前生成的重置 Token 依然有效