web-dev-qa-db-ja.com

Bearer JWTを使用している場合、CSRFトークンは必要ですか？

Context：Angular APIとして使用されるExpressサーバーとは別に、CloudFrontの背後にあるS3でホストされ、ほとんどすべてリクエストはXMLHttpRequestsです。すべてのリクエストはCookieなしで送信され（デフォルトではwithCredentials = false）、angularのCookieから取得してAuthorizationヘッダー（この手法は CSRF Wikiページ で説明されているようなものです）。

Expressサイトでは、Access-Control-Allow-HeadersでCookieヘッダーを使用できません。

Cookieにはsecure: trueフラグがあり、手動でAngularでアクセスする必要があるため、httpOnlyではありません。

また、私は この中の記事 そのJSON-Web-Tokens（JWT）/ Bearerトークンを読みました

間違いなくCSRFを防ぐ最良の方法の1つです

質問1：各リクエストにX-XSRF-Tokenヘッダーを追加し、たとえば、チェックしてメカニズムをステートレスにする場合、セキュリティを追加しますか？ JWTペイロードで同じ値ですか？ （私はそれについて このスレッド で読みます）

質問2：私が実際に説明したすべてを実行するために、CSRFに対して追加のセキュリティ対策が必要ですか？

cookiescsrfnode.jsangularjs
55
Igor Pomogai

これは関係ありますが、必ずしもあなたの質問の100％に答えるとは限りません：

https://security.stackexchange.com/a/166798/149676

それが不足しているのは、認証が自動でない限り（通常はブラウザーによって提供される）、CSRF保護について心配する必要がないということです。アプリケーションがAuthorizationヘッダーを介して認証情報を添付している場合、ブラウザーはリクエストを自動的に認証できず、CSRFは不可能です。したがって、私はあなたの記事からの引用を少し言い換えます：それはベアラートークンがCSRF攻撃に対する最善の防御であるということではなく、単にCSRFがブラウザが自動的に認証を提供するリクエスト（通常はクッキー）を特に攻撃する攻撃ベクトルであるということですと基本認証）、そしてブラウザがあなたを認証できない場合、CSRFは関係ありません。

サーバー側で、Bearerトークンがない場合にアプリケーションが暗黙的にCookie検証にフォールバックしないことを確認して確認する必要があります。私はそのような何かが偶然にアプリケーションにきしむのを見ることができました、そしてあなたが望むかどうかに関係なくクッキーは一緒に送られるので、それが影響を受けないことが「想定されている」ページの意図しないCSRF脆弱性をもたらすかもしれませんCSRF。

結果として、あなたの質問1と2はどちらも同じように答えられると思います。ベアラートークンを介した認証のみを使用し、Cookieを介さない場合、CSRFの脆弱性の心配はなく、セキュリティのために追加の手順は必要ありません。

47
Conor Mancone

一般に、CSRFは、ブラウザが自動的にヘッダー（Cookie内のセッションID）を追加し、セッションを認証したときに発生します。ベアラートークン、または手動で追加する必要がある他のHTTPヘッダーベースのトークンは、CSRFを妨げます。

もちろん、トピック外ですが、XSSの脆弱性があれば、攻撃者はこれらのトークンにアクセスできますが、それでもCSRFのバグにはなりません。

23
ndrix

以前の答えは堅実です。ここにジャンプして、より多くのコンテキストと少しの警告を提供します。 JWTを使用する方法はたくさんあります。セッション管理はその1つです。ただし、タイムアウト（および再認証などの高度な要件）を処理する場合は いくつかの欠点があります 。

また、JWTがCookiesに配置されるのを見ました。他の人が述べたように、CSRF保護はJWT自体を使用することからは生まれません。 Bearer [JWT]スキームを使用して、Authorizationヘッダーとして送信することから来ています。

質問1：各リクエストにX-XSRF-Tokenヘッダーを追加し、たとえばJWTペイロードで同じ値をチェックしてメカニズムをステートレスにする場合、セキュリティを追加しますか？ （私はこのスレッドでそれについて読んだ）

XHRを介してAuthorizationヘッダーとして送信する場合、追加のX-XSRF-Tokenヘッダーは「追加の」セキュリティを追加しません。

質問2：私が説明したすべてを採用するCSRFに対する追加のセキュリティ対策が必要ですか？

いいえ、現在の設定は大丈夫です。

しばらく前に、私は Web認証技術ガイド とそのセキュリティプロパティをコンパイルしました（これには JWTパーツ も含まれています）。以下は、すべてのメソッドをコンパクトな形式で説明する 最終的なチートシート です。

9
Daniel Szpisjak

CSRF保護が役に立たなくなる可能性のある単一ページアプリケーション（または一般にフロントエンドからのリクエスト）について強調することが重要だと思います。最初は少し外れているかもしれないと思ったのですが、考え直します（下部のメモを参照）。

私のポイント：多分あなたはURLからアプリをロードするときに自動的にAPIにリクエストをするいくつかのフロントエンドアプリケーションコードを持っています（最も一般的な例の1つは電子メールアドレスの検証です）。この場合、CSRFの有無はまったく関係ありません。特定のユーザーアクションを必要とせずにフロントエンドアプリで何かが発生するとすぐに、攻撃者がフロントエンドアプリを開くだけでアクションを実行する「正当な」方法があるため、CRSF保護は関係ありません。

フロントエンド側で自動的に実行される可能性のあるアクションを思い浮かべるいくつかの例

  • 認証（アクセストークンの生成など）
  • メールの検証
  • メールリンクをたどって一部のコンテンツを自動的に評価する
  • メール/ニュースレターからの（非）購読
  • ファイルをダウンロードする（フロントエンドアプリがダウンロード要求をサーバーに転送する前に何かを前処理する場合）
  • プロジェクト、グループに参加する
  • リファラーコードの検証

これらのユースケース（メールの検証など）の一部は認証を必要とせず、比較的無害ですが、他の一部（グループへの参加など）は、認証された場合にのみ意味があります。つまり、認証されたリクエストを自動的に実行する方法があります。 API。ユーザーが何が起こったのかについて直接的なフィードバックを持っている場合（フロントエンドがユーザーにフィードバックを提供している場合）、およびそれらの操作を元に戻すことができれば、危険性は低くなりますが、攻撃ベクトルのままです。

「CSRF」は、サーバーアプリまたはAPIに直接送信されるリクエストから保護する方法としてよく考えられます。私が間違っている場合は修正してください。ただし、 definition は、悪意のある人物がフロントエンドアプリのコードの使用など、発生した結果を確認できない攻撃をすべて含むようです

0
Cyril Duchon-Doris