web-dev-qa-db-ja.com

このWebアプリケーションのハイブリッド（cookie、jwt）認証方法は既知で実用的ですか？

私はしばらくWebアプリケーションを使用してきましたが、数か月前、Cookieを使用してリクエストを認証し、JSON-Web-Tokens（JWT）のステートレスな利点を利用しながら、ブラウザーからセキュリティ上の利点を得る可能なアプローチを見つけました。

これが既知の、おそらく壊れたアプローチであるかどうかを知りたいと思っています。

詳細：

Cookieベースの認証はXSSに対して安全であることがよく知られていますが、CSRFの複雑さをもたらします。また、トークンを無効にする必要がない限り、JWTは便利です（XSSも問題です）。

アプローチ：

  • ログインすると、ユーザーは有効期間が非常に短い（3分など）JWTを受け取ります。
  • ログイン後、ユーザーはJWTを更新するためのCookieも受け取ります。
  • ユーザーはJWTをアタッチするサーバーを呼び出し続け（Cookieはブラウザーによってアタッチされます）、サーバーはこのトークンを使用してリクエストを認証します。
  • サーバーは、期限切れのトークンを取得すると、Cookieからセッションを読み込み、新しいJWTを返します（または、要求が拒否され、ユーザーが別の要求でトークンを更新します）。その後、元の要求が有効なトークンで再試行されます。

いくつかの利点：

  • トークンの無効化。JWTが侵害された場合、非常に短期間存続します。
  • CSRF保護。CSRF攻撃が成功すると、ブラウザはサーバー上で機密性の高い操作を実行せずに、有効期間の短い新しいトークンを取得します。 -多くの効率的なステートレス認証リクエストが存在する可能性があります。
web-applicationxsscookiescsrfjwt
3
AlexITC

トークンを更新する

これは、更新トークンのパターンとよく似ています。その中に、2つのJWTがあります。1つは通常のリクエスト用に短命で、もう1つは短命なものを更新するために長命です。短命は取り消すことはできませんが、長命は取り消すことができます。これは一般的に使用されるパターンであり、取り消し可能性とパフォーマンスの間の適切なトレードオフを提供します。

長期間有効なトークンがCookieに切り替えられているという点で、アプローチは異なります。その利点と欠点について考えてみましょう。

CSRF

Cookieに基づいて新しいトークンを発行する前に、期限切れのトークンが有効であることを確認すると、技術的にCSRFから保護されます。 CSRF攻撃者はトークンを作成できなかったため、攻撃を成功させることができませんでした。

それでも、少し不安を感じています。まず、期限切れのトークンを受け入れる特別なJWTチェックを行う必要があります。これは少し面倒で、実装ミスの余地があります。次に、期限切れのトークンが突然機密データになります。それはあまり気分が良くない。

XSS

CookieをHTTPのみとしてマークすることができるため、XSS攻撃の力が多少制限されます。これがあなたの計画の動機になっているようです？

しかし、これはあまり価値がありません。攻撃者はトークンだけで数分間多くのことを行うことができます。さらに時間が必要な場合は、クライアントでJSを実行して、トークンを常に更新し、新しいトークンを攻撃者に送信します。または、クライアントから実行する要求を実行します。

基本的に、XSSの脆弱性がある場合、それはゲームオーバーです。このようなスキームでは、その影響を実際に制限することはできません。あなたは台本の子供を止めるかもしれませんが、それ以上ではありません。

結論

私はあなたのスキームに悪用可能な欠陥を見つけることができないので、「安全でない」とはラベル付けしません。しかし、私は大きな利益を実際に見ることもできません。しかし、おそらく何かが足りない。

ただし、作成するのはより複雑です。新しいパターン、実装する新しいものを作成し、さまざまな種類のソリューション（Cookie、トークン）を混合します。より良い言葉がないため、それはあまりきれいではありません。

そのため、代わりに、リフレッシュトークンなど、より標準的なものを使用します。

3
Anders

JWTトークンには、accessトークンとrefreshトークンがあります。

従来、両方トークンをCookieに保存するか、または両方をローカルストレージに保存します。どちらを選択するかは、防御する攻撃ベクトル（CSRFとXSS）によって異なります。

あなたが提案しているのは、refreshトークンをcookieとして保存することですが、accessトークンをローカルストレージに保存します-ある意味では、これにより攻撃が緩和されますが、両方のCSRFの影響を受けやすいと思いますXSS。どちらの攻撃もトークンを取得するため。

これに関する私の個人的な意見は、両方のトークンをCookieに保存することです。 HttpOnlyディレクティブとSame-Siteディレクティブを使用すると、特に厳密なSame-Siteディレクティブを使用して非常に特定のパスに制限できるリフレッシュトークンの場合、Cookieのクラックがかなり難しくなります。あなたのAPIに。

アクセストークンに関しては、同じサイトディレクティブが必要とされるリスク/機能によって異なります。

繰り返しますが、私の個人的な見解ですが、Cookieのみのアプローチを使用すると、XSSを忘れて（少なくともトークンのみ）、CSRFに集中できます。 Cookieとトークンを混在させると、両方に対して保護する必要があります。

0
keithRozario