web-dev-qa-db-ja.com

CSRFとX-CSRF-Tokenの違い

非表示フィールドのヘッダーまたはトークンでのX-CSRF-Tokenの使用の違いは何ですか？

隠しフィールドを使用する場合とヘッダーを使用する場合、なぜですか？

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

httpsecuritycsrf
17
monkeyUser

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

従来の方法（ "Synchronizer token"パターン ）では、通常、各リクエストに一意の有効なトークン値を設定し、その後、リクエストが送信されるときにその一意の値を確認します。通常、非表示のフォームフィールドを設定して行います。トークンの値は通常、存続期間が短く、そのセッションに関連付けられているため、ハッカーが以前にページで見た値を再利用しようとしたり、値を推測しようとしたりすると、失敗する可能性があります。したがって、アプリケーションからのリクエストのみが機能し、アプリケーション/ドメインの外部からの偽造リクエスト（別名クロスサイトリクエストフォージェリ）は失敗します。

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

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

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

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

さらに、シンクロナイザートークンパターンにより、追加の制御でフローを適用できます（たとえば、非表示フィールドCSRFトークンは、フォームを取得するために有効なリクエストを送信したとアプリケーションが判断した場合にのみ設定されます）。

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

32
Barry Pollard

これらはすべて、クロスサイトリクエストフォージェリから保護するためのもので、バックエンドにリクエストを送信するときは1つだけ使用する必要がありますです。

csrf：

  • HTMLフォームで使用（ajaxではない）
  • hTMLフォームではリクエストヘッダーを設定できないため、フォーム入力を介して非表示フィールドとして送信する必要があります。

x-csrf-token：

  • Ajaxリクエストのリクエストヘッダーに追加されます。
  • laravelをバックエンドとして使用する場合。 laravelはこのヘッダーを自動的にチェックし、データベース内の有効なcsrfと比較します。

x-xsrf-token：

  • Ajaxリクエストのリクエストヘッダーに追加されます。
  • angularおよびaxiosなどの一般的なライブラリは、xsrf-token cookieからこのヘッダーの値を自動的に取得し、すべてのリクエストで送信します。
  • 人気があるため、laravelは、応答ごとにこのCookieを作成します。
  • したがって、たとえばaxiosやlaravelを使用している場合は、何もする必要はありません。ユーザーはログに記録する必要があるだけで、「認証」ミドルウェアを使用するだけで十分です。
  • Cookieはlaravelで暗号化されるため、x-csrf-tokenに比べて文字列が大きくなります。
3
Ahmad Mobaraki