影響
攻撃者は、脆弱なアプリケーション [S2] のユーザーから機密の認証済みデータを盗む可能性があります。ユーザーが脆弱なアプリにログインしているときに悪意のある Web サイトにアクセスすると、悪意のあるサイトはアプリの API に対してクロスオリジン リクエストを送信し、応答 [S1][S2] を読み取ることができます。これにより、ユーザー プロファイル、CSRF トークン、プライベート メッセージ [S2] などの個人情報が盗難される可能性があります。
根本原因
CORS は、サーバーがリソース [S1] のロードを許可されるオリジン (ドメイン、スキーム、またはポート) を指定できるようにする HTTP ヘッダー ベースのメカニズムです。脆弱性は通常、サーバーの CORS ポリシーが柔軟すぎるか、実装が不十分な場合に発生します。
- 反映されたオリジン ヘッダー: 一部のサーバーは、クライアント リクエストから
Originヘッダーを読み取り、それをAccess-Control-Allow-Origin(ACAO) 応答ヘッダー [S2] にエコー バックします。これにより、あらゆる Web サイトがリソース [S2] に事実上アクセスできるようになります。 - 設定が間違っているワイルドカード:
*ワイルドカードを使用すると、任意のオリジンがリソースにアクセスできますが、資格情報 (Cookie や Authorization ヘッダーなど) [S3] を必要とするリクエストには使用できません。開発者は多くの場合、リクエスト [S2] に基づいて ACAO ヘッダーを動的に生成することで、これを回避しようとします。 - ホワイトリスト「null」: 一部のアプリケーションは
nullオリジンをホワイトリストに登録します。これはリダイレクトされたリクエストまたはローカル ファイルによってトリガーされる可能性があり、悪意のあるサイトがnullオリジンを装って [S2][S3] にアクセスできるようになります。 - 解析エラー:
Originヘッダーの検証時に正規表現または文字列の一致に誤りがあると、攻撃者がtrusted-domain.com.attacker.com[S2] などのドメインを使用できる可能性があります。
CORS は、クロスサイト リクエスト フォージェリ (CSRF) [S2] に対する保護ではないことに注意することが重要です。
具体的な修正
- 静的ホワイトリストを使用する: リクエストの
Originヘッダー [S2] からAccess-Control-Allow-Originヘッダーを動的に生成することは避けてください。代わりに、リクエストの送信元を信頼できるドメインのハードコードされたリスト [S3] と比較します。 - 「null」オリジンを避ける: 許可されるオリジンのホワイトリスト [S2] に
nullを含めないでください。 - 資格情報の制限: 特定のクロスオリジン インタラクション [S3] に絶対に必要な場合にのみ、
Access-Control-Allow-Credentials: trueを設定します。 - 適切な検証を使用する: 複数のオリジンをサポートする必要がある場合は、
Originヘッダーの検証ロジックが堅牢であり、サブドメインまたは類似したドメイン [S2] によってバイパスできないことを確認してください。
FixVibe がそれをテストする方法
FixVibe には、これがゲートされたアクティブ チェックとして含まれるようになりました。ドメイン検証後、active.cors は、合成攻撃者のオリジンを持つ同じオリジンの API リクエストを送信し、CORS レスポンス ヘッダーをレビューします。これは、公開資産のノイズを回避しながら、任意の起源、ワイルドカード認証付きの CORS、および非公開の API エンドポイント上の広範囲にオープンな CORS を反映していることを報告します。