[解決済み] CSRFとX-CSRF-Tokenの違いについて

質問

• を使用することの違いは何ですか？ X-CSRF-Token をHTTPヘッダーに使用するか トークン をhiddenフィールドに入れるか？
• どのような場合にhiddenフィールドを使用し、どのような場合にヘッダーを使用するのか、またその理由は？

と思うのですが X-CSRF-Token は、JavaScript / AJAXを使っているときですが、よくわかりません。

どのように解決するのですか？

CSRF対策には、いくつかの方法があります。

従来の方法( シンクロナイザートークンのパターン ) 通常は、各リクエストに一意の有効なトークン値を設定し、その後リクエストが送信されたときにその一意の値を検証することになります。これは通常、隠されたフォームフィールドを設定することで行われます。そのため、ハッカーが以前そのページで見た値を再利用しようとしたり、値を推測しようとしたりすると、おそらく失敗します。したがって、アプリケーションからのリクエストのみが機能し、アプリケーション/ドメイン外からの偽造リクエスト（別名、クロスサイトリクエストフォージェリ）は失敗します。

その欠点は、アプリケーションがすべてのHTMLフォームにこの隠されたトークンを設定する必要があることです。以前は静的なHTMLだったこれらのページが、アプリケーションによって動的に生成されなければならなくなります。また、戻るボタンが壊れる可能性もあります（別の一意のCSRF値を再生成するためにフォームをリフレッシュする必要があるため）。また、サーバー側で有効なトークンを追跡し、すべてのリクエストで有効なトークンが使用されていることを確認する必要があります。これは、実装と今後のメンテナンスにかなりの労力を要するでしょう。

別のアプローチ（と呼ばれる クッキーからヘッダートークン）パターン ) は、セッションごとに一度だけCookieを設定し、JavaScriptにそのCookieを読ませて、カスタムHTTPヘッダ（しばしば X-CSRF-TOKEN または X-XSRF-TOKEN または XSRF-TOKEN ) をその値で指定します。どのようなリクエストでも、ヘッダー（Javascriptによって設定される）とクッキー（ブラウザによって標準のHTTPヘッダーとして設定される）の両方を送信し、サーバーはその値を X-CSRF-TOKEN ヘッダはクッキーヘッダの値と一致します。同じドメインで実行されるJavaScriptだけがクッキーにアクセスできるので、他のドメインからのJavaScriptはこのヘッダーに正しい値を設定できないという考え方です（ページがこのクッキーにアクセスするようなXSSに対して脆弱でないと仮定して）。たとえ偽のリンク（例えばフィッシングメール）であっても、正しいドメインから来たように見えても、クッキーだけは設定されるので、うまくいきません。 X-CSRF-TOKEN ヘッダを作成します。

これはSynchronizerトークンパターンよりはるかに簡単に実装できます。なぜなら、各フォームの呼び出しごとにトークンを設定する必要がなく、チェックもCSRFトークンの有効性を追跡するのではなく、比較的簡単だからです（クッキーがヘッダに一致するかチェックするだけです）。必要なのは、セッションごとにクッキーをランダムな値に設定することだけです。フロントエンドフレームワークの中には、クッキーを見れば自動的にヘッダーを生成してくれるものもあります（例． AngularJSはこれを行います。 など）。

欠点は、動作させるには JavaScript が必要なことです (ただし、アプリが基本的に JavaScript なしでは動作しない場合は問題にはなりません)。また、JavaScript が行うリクエスト (XHR リクエストなど) に対してのみ動作し、通常の HTML フォームリクエストではヘッダーが設定されません。これのバリエーション ( ダブルサミットクッキー"パターン ) は X-CSRF-TOKEN の値を HTTP ヘッダーではなく隠しフォーム・フィールドに格納することで、これを回避しつつ、サーバー側のロジックを従来の Synchronizer トークン・パターンよりもシンプルに保っています。ただし、以下の点には注意が必要です。 OWASPは、Double Submitメソッドにいくつかの弱点があると述べています。 攻撃者がクッキーを設定できる場合（クッキーを読むより簡単なことが多い）、この場合CSRFトークンを検証することを推奨します。

さらに、Synchronizer トークン パターンは、フローを強制するための特別なコントロールを可能にします (例えば、hidden フィールド CSRF トークンは、そのフォームを取得するために有効なリクエストを送信したとアプリケーションが考えるときにのみ設定されます)。

また、一部のセキュリティスキャンでは、Cookieが HTTP-Only しかし、これは意図的なもので、JavaScriptで読み取ることができる必要があるからです! 偽の警告。のような一般的な名前を使用している限り、そのようなことはないと思うでしょう。 X-CSRF-TOKEN 彼らはこのフラグを立てないことを知っているはずですが、よくフラグが立っているのを見かけます。