リファラーHTTPヘッダーを送信すると、CSRF攻撃からどのように保護されますか？

Question

Firefoxの network.http.sendRefererHeader を0に設定して（つまり、トラッキング対策として完全に無効にして）、HTTPSサイトにログインしてみたところ、次のように述べられました。

禁じられた（403）

CSRF検証が失敗しました。リクエストは中止されました。

このHTTPSサイトでは、Webブラウザーから「Refererヘッダー」を送信する必要があるが、何も送信されなかったため、このメッセージが表示されています。このヘッダーは、セキュリティ上の理由から、ブラウザがサードパーティによってハイジャックされないようにするために必要です。

「Referer」ヘッダーを無効にするようにブラウザーを構成している場合は、少なくともこのサイト、HTTPS接続、または「same-Origin」要求に対して、ヘッダーを再度有効にしてください。

これはどのようにしてCRSF攻撃を防ぎますか？攻撃者はリファラーヘッダーを偽装して、私が送信したように見せることはできないのですか？

Philipp · Accepted Answer

これを理解するには、まずクロスサイトリクエストフォージェリとは何かを理解する必要があります。

クロスサイトリクエストフォージェリとは、攻撃者が制御するWebサイトにスクリプトまたは埋め込みメディアがあり、そのWebサイトへの訪問者が別のサイトのリソースを要求することです。その要求は、ユーザーのコンテキストで他のサイトに表示されます。たとえば、https://othersite.example.com/delete_my_account.php?really=trueというURLの画像をウェブサイトに追加できます。私のサイトにアクセスし、現在othersite.example.comでアカウントにログインしている場合、ブラウザーがそのURLを要求するため、othersite.example.comがアカウントを削除します。

しかし、落とし穴があります。othersite.example.comがリファラーを読み取ることができる場合、このリクエストが別のサイトとやり取りしている誰かによって引き起こされていることがわかります。アクションを実行するURLへのディープリンクがWebサイトにあるのに十分な理由はありません。他のサイトがリファラーなしでリクエストを拒否すると、その攻撃は不可能になります。

リファラーのなりすましについて：リクエストを行うクライアントは攻撃者ではないことに注意してください。攻撃者はWebサイト運営者です。オペレーターが実行できる最悪の事態は、WebブラウザーにWebサイトのコンテキストでJavaScriptを実行させることです。 JavaScriptを使用して他のWebサイトにリクエストを送信する方法はいくつかありますが、これらのAPIのいずれもリファラーを偽ることはできません。

tim · Answer

攻撃者はリファラーヘッダーを偽装することはできませんでした

いいえ、できません。

フォーム（またはCSSのイメージタグやURLなどのさまざまなGETメソッド）を送信する場合は明らかに不可能であり、 documentation のように、XMLHttpRequestを介することもできません。

つまり、オープンリダイレクトの脆弱性が存在し、アプリケーションがRESTfulに従わない場合、またはGETへのダウングレードが可能で、オープンリダイレクトの脆弱性、HTMLインジェクションの脆弱性が含まれている場合、リファラーのチェックがバイパスされる可能性があるため、代わりにトークンを使用することをお勧めします。、またはCSSインジェクションの脆弱性。また、（あなたの場合のように）ユーザビリティの問題を引き起こす可能性もあります。