security - CSRF と X-CSRF-Token の違い

Question

• 非表示フィールドでX-CSRF-Tokenの HTTP ヘッダーまたはトークンでの使用の違いは何ですか?
• いつ隠しフィールドを使用し、いつヘッダーを使用するのか、またその理由は?

JavaScript / AJAXを使用しているときだと思いX-CSRF-Tokenますが、よくわかりません。

Answer 1

CSRF 保護にはいくつかの方法があります。

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

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

別のアプローチ ( 「Cookie-to-header トークン」パターンと呼ばれます) は、セッションごとに 1 回 Cookie を設定し、JavaScript にその Cookie を読み取らせ、その値でカスタム HTTP ヘッダー (多くの場合、X-CSRF-TOKENorX-XSRF-TOKENまたはと呼ばれXSRF-TOKENます) を設定することです。すべてのリクエストは、ヘッダー (Javascript によって設定される) と Cookie (ブラウザーによって標準の HTTP ヘッダーとして設定される) の両方を送信し、サーバーはその値をX-CSRF-TOKENheader は、Cookie ヘッダーの値と一致します。同じドメインで実行されている JavaScript のみが Cookie にアクセスできるという考えであるため、別のドメインの JavaScript はこのヘッダーを正しい値に設定できませんでした (この Cookie にアクセスできる XSS に対してページが脆弱ではないことを前提としています)。 . 偽のリンク (フィッシング メールなど) も機能しません。正しいドメインから送信されたように見えても、Cookie のみが設定され、X-CSRF-TOKENヘッダーは設定されないためです。

これは、各フォームへの呼び出しごとにトークンを設定する必要がないため、Synchronizer トークン パターンよりも実装がはるかに簡単です。また、CSRF トークンを追跡するのではなく、チェックも比較的簡単です (Cookie がヘッダーと一致することを確認するだけです)。有効。必要なのは、セッションごとに Cookie をランダムな値に設定することだけです。一部のフロント エンド フレームワークは、Cookie を認識した場合にヘッダーを自動的に生成します (たとえば、AngularJS はこれを行います)。

欠点は、JavaScript が機能する必要があることです (ただし、アプリが基本的に JavaScript なしでは機能しない場合は問題にならない可能性があります)。また、JavaScript が行う要求 (XHR 要求など) に対してのみ機能します - 通常の HTML フォーム要求ヘッダーを設定しません。これのバリエーション ( 「Double Submit Cookie」パターン) ではX-CSRF-TOKEN、HTTP ヘッダーではなく非表示のフォーム フィールドに値を配置してこれを回避しますが、サーバー側のロジックは従来の Synchronizer トークン パターンよりも単純に保ちます。ただし、攻撃者が Cookie を設定できる場合 (多くの場合、Cookie を読み取るよりも簡単です)、OWASP は Double Submit メソッドのいくつかの弱点を述べているため、この場合は CSRF トークンを検証することをお勧めします。

さらに、Synchronizer トークン パターンを使用すると、追加の制御でフローを強制できます (たとえば、非表示フィールドの CSRF トークンは、そのフォームを取得するために有効な要求を送信したとアプリケーションが判断した場合にのみ設定されます)。

ああ、一部のセキュリティ スキャンでは、Cookie にHTTP-Onlyフラグが設定されていないため、JavaScript で読み取ることができるという事実が検出されます。誤報。X-CSRF-TOKENこれにフラグを付けないことを知っているように、一般的な名前を使用している限り、フラグが立てられるのを頻繁に見たことがあると思います。