web-dev-qa-db-ja.com

適切なCORS設定はXSRFを防ぎますか？

CORSがサーバーで適切にセットアップされ、特定のオリジンのみがサーバーにアクセスできるようにする場合、これでXSRF攻撃を防ぐことができますか？

corscsrf
33
programmerdave

具体的には、CORSが原因でevil.comがgood.comにリクエストできない場合、CSRFが阻止されると誤解しがちです。ただし、見落とされている2つの問題があります。

  1. CORSは、ブラウザによってのみ尊重されます。つまり、Google ChromeはCORSに従い、evil.comがgood.comにリクエストを送信することはありません。ただし、誰かがネイティブアプリなど、サイトに投稿するフォームを持つものを作成するとします。 .XSRFトークンはそれを防ぐ唯一の方法です。

  2. CORSはJSリクエスト専用であるという事実を見逃しがちです。 good.comにPOSTバックするevil.comの通常のフォームは、CORSにもかかわらず引き続き機能します。

これらの理由から、CORSはXSRFトークンの適切な代替品ではありません。両方を使用することをお勧めします。

31
aleemb

番号！

CORSは、XSRFがCORSに依存しない方法を攻撃している2つのドメイン間での共有を可能にします。

「CORSが適切に設定されている」とはどういう意味かわかりませんが、XSRFで攻撃する場合、ブラウザはサーバーのCORSヘッダーを要求しません。

CORSはセキュリティではありません :)

14
confiq

番号。

同一生成元ポリシー（CORSでは選択的な穴を開けることができます）は、サードパーティのサイトがデータを読み取り（プライベート）するためにユーザーになりすますことを防ぎます別のサイトから。

クロスサイトリクエストフォージェリ攻撃とは、サードパーティサイトがユーザーとして偽装してデータを（そのユーザーとして）別のサイトに送信することです。応答を読み返す必要はありません。

10
Quentin

多分

これは難しいものであり、他の人が提供しているよりもはるかに複雑です。かもね"

第1に、CORSは、特定のタイプのCSRF攻撃を防ぐデフォルトである同じオリジンポリシーを「緩和」することを目的としています。ただし、同一生成元はすべての種類のリクエストに適用されるわけではありません。

したがって、セッションがタイムアウトするまでの時間が長くなり、ユーザーが信頼できないサイトをサーフィンする回数が増えるほど、CSRF攻撃のあるサイトに飛び込むリスクが高くなります。外部リソースにリクエストを送信するタグを使用して、非表示のCSRF攻撃を実行できます–画像、リンクタグ、一部のメタタグ、埋め込みタグ、オブジェクトタグなど。背景画像などをロードする属性についても同様です。アプリケーションマークアップのヘッダーにあるDTDファイルをサーバー上のリソースに置き換えると、サイトが誰かによって検証されているかどうかを確認することもできます。これもCSRFです。 ソース

その例については、これを確認してください。

<img src=victim.bank/check.png?account=...>; Originヘッダーやプリフライトリクエストを生成せずに、脆弱な銀行サイトから小切手写真を取得します。 [...]写真が表示され、攻撃者はJavascriptを使用して写真データを取得し、それらを送り返すことができます。 ソース

ただし、少なくとも1つのソースは、おそらく将来的にはWebサーバーがAccess-Control-Allow-Origin（CORS）ブラウザが画像をレンダリングするのを停止する画像のヘッダー。これにより、この種のCSRF-GET攻撃を防ぐことができます。

ブラウザが応答のAccess-Control-Allow-Originヘッダーを確認し、それを表示することを拒否した場合、それは効果的な防御になります。 ソース

4
Evan Carroll