JQuery およびその他のフレームワークでは、次のヘッダーが追加されます。
X-リクエスト: XMLHttpRequest
なぜこれが必要なのでしょうか? サーバーが AJAX リクエストを通常のリクエストとは異なる方法で処理する必要があるのはなぜでしょうか?
更新: このヘッダーを使用した実際の例を見つけました:https://core.spreedly.com/manual/payment-methods/adding-with-js支払いプロセッサが AJAX なしで要求された場合、完了すると元の Web サイトにリダイレクトされます。AJAX で要求された場合は、リダイレクトは行われません。
ベストアンサー1
良い理由はセキュリティのためであり、これによりCSRFこのヘッダーは、サーバーの同意なしにAJAXリクエストのクロスドメインに追加できないため、攻撃の危険があります。CORS。
オリジン間で許可されるのは、次のヘッダーのみです。
- 受け入れる
- 受け入れ言語
- コンテンツ言語
- 最終イベントID
- コンテンツタイプ
その他の場合は、CORS 対応ブラウザで「事前フライト」リクエストが発行されます。
X-Requested-WithCORS がないと、クロスドメイン XHR リクエストに追加することはできません。
サーバーがこのヘッダーの存在を確認している場合、リクエストが攻撃者のドメインから開始されたものではなく、JavaScriptを使用してユーザーに代わってリクエストを送信しようとしていることがわかります。これにより、リクエストが通常のHTMLフォームからPOSTされていないことも確認されます。トークンを使用せずにクロスドメインではないことを確認するのは困難です。（ただし、Originヘッダーを確認するサポートされているブラウザではオプションになる可能性がある。古いブラウザは脆弱なままになりますが。
新たなフラッシュバイパスが発見される
あなたは望むかもしれませんこれをトークンと組み合わせるOSXのSafariでFlashが動作しているためリダイレクトステップがある場合、このヘッダーを設定できます。 現れるChromeでも動作しました、現在は修正されています。詳細はこちら影響を受けるさまざまなバージョンを含みます。
OWASPはこれをオリジンとリファラーのチェックと組み合わせることを推奨しています:
この防御手法については、クロスサイト リクエスト フォージェリに対する堅牢な防御のセクション 4.3 で具体的に説明されています。ただし、Flash を使用したこの防御のバイパスは、2008 年にはすでに文書化されており、最近では 2015 年に Mathias Karlsson によって Vimeo の CSRF の欠陥を悪用するものとして文書化されています。ただし、Flash 攻撃は Origin ヘッダーまたは Referer ヘッダーを偽装できないため、両方のチェックを行うことで、このチェックの組み合わせによって Flash バイパス CSRF 攻撃を防止できると考えています。(注: この考えを確認または反論できる方がいらっしゃいましたら、この記事を更新できるようにお知らせください)
ただし、すでに説明した理由により、Origin を確認するのは難しい場合があります。
アップデート
より詳しいブログ記事を書いたCORS、CSRF、X-Requested-Withはこちら。