いい質問です！
完璧な世界では、CSRF攻撃を実行する方法は考えられません。
- HTMLフォームを使用してPUTまたはDELETE要求を行うことはできません。
- 画像、スクリプトタグ、CSSリンクなどはすべて、GETリクエストをサーバーに送信します。
- XmlHttpRequestおよびFlash/Silverlight/Appletsなどのブラウザプラグインは、クロスドメインリクエストをブロックします。
したがって、一般に、PUT/DELETE動詞をサポートするリソースに対してCSRF攻撃を行うことはできません。
とはいえ、世界は完璧ではありません。このような攻撃を可能にする方法はいくつかあります。
RailsなどのWebフレームワークは、「疑似メソッド」をサポートしています。
_method、その値をPUTまたはDELETEに設定してから、GETまたはPOSTリクエストを送信し、HTTP動詞をオーバーライドします。これは、ブラウザーフォームからのPUTまたはDELETEをサポートする方法です。このようなフレームワークを使用している場合、標準的な手法を使用してCSRFから保護する必要がありますサーバーで誤ってCORSの緩い応答ヘッダーを設定する場合があります。これにより、任意のWebサイトがPUTおよびDELETE要求を行うことができます。
ある時点で、HTML5はHTMLフォームにPUTおよびDELETEのサポートを含めることを計画していました。しかし、その後、彼らはそのサポートを削除しました。後で追加されないという保証はありません。一部のブラウザmayは、実際にこれらの動詞をサポートしており、それはあなたに反する可能性があります。
一部のブラウザプラグインにバグがあり、攻撃者がPUT/DELETEリクエストを行う可能性があります。
つまり、リソースがPUTおよびDELETEメソッドのみをサポートしている場合でも、リソースを保護することをお勧めします。
いいえ。HTTP動詞に依存することは、CSRF攻撃を防ぐ方法ではありません。サイトの作成方法がすべてです。 PUTをPOSTとして使用し、DELETEをGETとして使用することができます-実際には問題ではありません。
CSRFを防ぐには、 here で説明されているいくつかの手順を実行します。
Webサイトには、さまざまなCSRF対策が用意されています。
- すべてのフォーム送信および副作用URLで秘密のユーザー固有のトークンを要求すると、CSRFが防止されます。攻撃者のサイトは
提出物の正しいトークン 1- セキュリティに影響する操作（送金など）を実行するために使用されるのと同じHTTPリクエストで認証データを提供することをクライアントに要求
- セッションCookieの有効期間を制限するHTTP Refererヘッダーを確認する（または）
- HTTP Originヘッダーの確認[16]
- Silverlightコントロールへの意図しないアクセスを許可するclientaccesspolicy.xmlファイルがないことを確認する[17]
- Flashムービーへの意図しないアクセスを許可するcrossdomain.xmlファイルがないことを確認する[18]
- リクエストのヘッダーにX-Requested-Withが含まれていることを確認します。 Ruby on Rails（v2.0より前）およびDjango（v1.2.5より前）。この保護は、ブラウザープラグインとリダイレクトの組み合わせにより、攻撃者が任意のWebサイトへのリクエストでカスタムHTTPヘッダーを提供できるため、安全でないことが証明されたため、偽造されたリクエストを許可します。
理論的には、クロスドメインPUTまたはDELETEリクエストを開始する方法がないため不可能です（CORSを除き、プリフライトリクエストが必要であり、したがってターゲットサイトの協力が必要です）。実際には、私はそれに依存しません-多くのシステムは、例えばCSRFファイルアップロード攻撃は不可能であると想定しました（そうすべきではありませんが、特定のブラウザーのバグにより可能になりました）。
はい、CSRF isはPUTおよびDELETEメソッドで可能ですが、制限のないポリシーで有効なCORSでのみ可能です。
Sripathi Krishnan's answer ：に同意しません
XmlHttpRequestおよびFlash/Silverlight/Appletsなどのブラウザプラグインは、クロスドメインリクエストをブロックします
ブラウザがクロスドメインリクエストを行うことを止めるものは何もありません。 同じ オリジン ポリシー は not を防ぎます リクエスト は行われません-リクエストが行われないようにするだけですブラウザで読む。
サーバーが [〜＃〜] cors [〜＃〜] を選択していない場合、これによりプリフライトリクエストが行われます。これは、単純な要求ではないため、PUTまたはDELETEが使用されないようにするメカニズムです（メソッドはHEAD、GET、またはPOSTである必要があります）。もちろん、適切にロックされたCORSポリシー（または、デフォルトで安全なものはまったくない）を想定しています。
CSRFは、サーバーの構成に応じて、PUTおよびDELETEで実際に可能です。
CSRFについて考える最も簡単な方法は、ブラウザで2つのタブを開き、1つはユーザーが認証されたアプリケーションで開き、もう1つは悪意のあるWebサイトで開くことです。
悪意のあるWebサイトがアプリケーションにjavascriptリクエストを行うと、ブラウザは標準のCookieをリクエストとともに送信し、悪意のあるWebサイトが既に認証されたセッションを使用してリクエストを「偽造」できるようにします。そのWebサイトは、GET、PUT、POST、DELETEなど、必要なあらゆるタイプの要求を実行できます。
CSFRを防御する標準的な方法は、悪意のあるWebサイトが知ることができない要求とともに何かを送信することです。これは、Cookieの1つのコンテンツと同じくらい簡単です。悪意のあるサイトからのリクエストにはCookieが送信されますが、別のドメインによって処理され、ブラウザーのセキュリティにより別のドメインのCookieにアクセスできないため、実際にCookieにアクセスできません。
Cookieコンテンツを「トークン」と呼びます。リクエストとともにトークンを送信できます。サーバーでは、リクエストを続行する前に「トークン」が正しく提供されていることを確認してください。
次の質問は、すべての異なるリクエストでその値をどのように送信するかということです。DELETEは、どんな種類のペイロードも持つように設計されていないため、特に困難です。私の意見では、最もクリーンな方法は、トークンでリクエストヘッダーを指定することです。このx-security-token =トークンのようなもの。このようにして、着信リクエストのヘッダーを確認し、トークンが欠落しているヘッダーを拒否できます。
過去には、標準のajaxセキュリティが悪意のあるサーバーでajaxを介して実行できることを制限していましたが、最近では、脆弱性はaccees-control構成に関してサーバーをどのようにセットアップするかに依存します。一部の人々はサーバーを開いて、クロスドメインコールを簡単にしたり、ユーザーが独自のRESTfulクライアントなどを作成しやすくしたりしますが、上記のようなCSRF防止方法がなければ、悪意のあるサイトが利用しやすくなります配置します。