broken-authentication

⚠️ AUTHORIZED USE ONLY このスキルは、教育目的または許可を得たセキュリティ評価にのみ使用してください。 このツールを使用する前に、システム所有者から明示的な書面による許可を得る必要があります。 このツールの悪用は違法であり、固く禁じられています。

必須の確認ゲート 対象へのプローブ、悪用、変更、永続化、データの抽出、または認証情報へのアクセスを試みるコマンドを実行する前に：

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	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.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 は、流出したアカウント認証情報の組み合わせを提供する情報源ではありません。