X-Requested-Withヘッダーのポイントは何ですか？

jQueryおよびその他のフレームワークは、次のヘッダーを追加します。

X-Requested-With：XMLHttpRequest

なぜこれが必要なのですか？サーバーがAJAXリクエストを通常のリクエストとは異なる方法で処理したいのはなぜですか？

更新：私はこのヘッダーを使用して実際の例を見つけました：https : //core.spreedly.com/manual/payment-methods/adding-with-js。支払いプロセッサがAJAXなしで要求された場合、処理が完了すると元のWebサイトにリダイレクトされます。AJAXで要求された場合、リダイレクトは行われません。

セキュリティ上の理由としては、これがCSRF攻撃を防ぐことができます。これは、CORSを介したサーバーの同意なしに、このヘッダーをAJAX要求のクロスドメインに追加できないためです。

ドメイン間で許可されるヘッダーは次のとおりです。

• 受け入れる
• 受け入れ言語
• コンテンツ言語
• 最終イベントID
• コンテンツタイプ

それ以外の場合は、CORSがサポートされているブラウザで「プリフライト」リクエストが発行されます。

CORSがないX-Requested-Withと、クロスドメインXHRリクエストに追加できません。

サーバーがこのヘッダーが存在することを確認している場合、リクエストは、JavaScriptを使用してユーザーに代わってリクエストを作成しようとした攻撃者のドメインから開始されたものではないことがわかります。これは、リクエストが通常のHTMLフォームからPOSTされていないことも確認します。トークンを使用しないとクロスドメインでないことを確認することは困難です。（ただし、サポートされているブラウザーではOriginヘッダーのチェックがオプションになる可能性がありますが、古いブラウザーは脆弱なままになります。）

新しいフラッシュバイパスが検出されました

リダイレクトステップがある場合、OSXのSafariで実行されているFlash がこのヘッダーを設定できるため、これをトークンと組み合わせることができます。ます。Chromeでも動作するようですが、現在は修正されています。影響を受けるさまざまなバージョンを含む詳細はこちら。

OWASPこれをOrigin and Refererチェックと組み合わせることをお勧めします：

この防御手法については、クロスサイトリクエストフォージェリに対する堅牢な防御のセクション4.3で具体的に説明されています。ただし、Flashを使用したこの防御策の迂回は、VameoのCSRFの欠陥を悪用するために、Mathias Karlssonによって、2008年から2015年にかけて文書化されています。ただし、Flash攻撃で​​はOriginヘッダーまたはRefererヘッダーを偽装することはできないため、両方をチェックすることで、このチェックの組み合わせによりFlashバイパスCSRF攻撃を防ぐことができると考えています。（注：この信念を誰かが確認または否定できる場合は、この記事を更新できるようにお知らせください）

ただし、すでに説明した理由により、Originのチェックは難しい場合があります。

更新

CORS、CSRF、およびX-Requested-With hereに関するブログ記事を詳しく説明しています。

SilverlightFoxの回答を必ずお読みください。それはより重要な理由を強調しています。

その理由のほとんどは、リクエストのソースがわかっている場合、それを少しカスタマイズしたい場合があるためです。

たとえば、たくさんのレシピがあるウェブサイトがあるとしましょう。そして、カスタムjQueryフレームワークを使用して、クリックしたリンクに基づいてレシピをコンテナーにスライドさせます。リンクはwww.example.com/recipe/apple_pie

これで通常は、ページ全体、ヘッダー、フッター、レシピコンテンツ、および広告が返されます。しかし、誰かがあなたのウェブサイトを閲覧している場合、それらのパーツのいくつかはすでにロードされています。したがって、AJAXを使用してユーザーが選択したレシピを取得できますが、時間と帯域幅を節約するためにヘッダー/フッター/広告をロードしません。

これで、次のようなデータのセカンダリエンドポイントを作成できます。 www.example.com/recipe_only/apple_pie、それを維持して他の人と共有することは困難です。

しかし、それがajaxリクエストであることを検出してリクエストを作成し、データの一部のみを返す方が簡単です。そうすることで、ユーザーが無駄にする帯域幅が減り、サイトの応答性が向上します。

フレームワークはヘッダーを追加するだけです。これは、どの要求がajaxであり、どの要求がajaxでないかを追跡するのに役立つ場合があるためです。しかし、そのようなテクニックを使用するかどうかは開発者に完全に依存しています。

実際には、Accept-Languageヘッダーに似ています。ブラウザがウェブサイトをリクエストできるので、URLに/ ru /などを挿入せずに、このウェブサイトのロシア語バージョンを見せてください。

一部のフレームワークはこのヘッダーを使用してxhr要求を検出しています。たとえば、Grails Spring Securityはこのヘッダーを使用してxhr要求を識別し、json応答またはhtml応答のいずれかを応答として返します。

ほとんどのAjaxライブラリ（v2.1以降のプロトタイプ、JQuery、およびDojo）には、リクエストが通常のハイパーリンクまたはフォーム送信ボタンをクリックすることによってトリガーされるのではなく、XMLHttpRequestによって作成されたことを示すX-Requested-Withヘッダーが含まれています。

ソース：http : //grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html