ローカルストレージまたはCookie？JWTをクライアントに安全に保存する

JWT（JSON Webトークン）は、クライアント/サーバーアプリケーションでの認証に一般的に使用されるアクセストークンを作成するための素晴らしいJSONベースの標準です。これらのトークンを使用する場合、アプリケーションのフロントエンドにトークンを安全に保存する方法について疑問が生じます。この問題は、トークンがサーバーで生成され、アプリケーションのクライアント側に転送された直後に解決する必要があります。 本日公開するこの資料は、ブラウザのローカルストレージ（）とJWTを保存するためのCookieを使用することの長所と短所の分析に専念しています。







localStorage

トークンの種類

• アクセストークンは通常、サーバーによって署名された短命のJWTです。これらは、クライアントがサーバーに対して行うすべてのHTTP要求に含まれています。トークンは、リクエストを承認するために使用されます。
• 更新トークンは通常、データベースに保存され、前のトークンの有効期限が切れたときに新しいアクセストークンを取得するために使用される長期間有効なトークンです。

トークンはクライアントのどこに正確に保存する必要がありますか？

クライアントにトークンを保存する一般的な方法は、ローカルブラウザストレージとCookieの2つです。どちらの方法が優れているかについては多くの議論があります。ほとんどの人は、セキュリティが優れているため、Cookieに傾倒しています。



ローカルストレージとCookieを比較してみましょう。私たちの比較は、主にこの資料とそれに対するコメントに基づいています。

ローカルストレージ

▍利点

ローカルストレージの主な利点は、使いやすいことです。

• ローカルストレージでの作業は非常に便利です。ここでは純粋なJavaScriptが使用されています。アプリケーションにバックエンドがなく、サードパーティのAPIに依存している場合、サイトに特定のCookieを設定するようにこれらのAPIを常に要求できるとは限りません。
• ローカルストレージを使用すると、リクエストヘッダーにアクセストークンを配置する必要があるAPIを操作すると便利です。例-次のように：Authorization Bearer ${access_token}。

▍デメリット

ローカルストレージの主な欠点は、XSS攻撃に対する脆弱性です。

• XSS攻撃を実行すると、攻撃者はサイトでJavaScriptコードを実行できます。これは、攻撃者がに保存されているアクセストークンにアクセスできることを意味しますlocalStorage。
• XSS攻撃のソースは、サイトに含まれているサードパーティのJavaScriptコードである可能性があります。React、Vue、jQuery、GoogleAnalyticsスクリプトなどのようなものである可能性があります。現代の状況では、サードパーティのライブラリを含まないサイトを開発することはほとんど不可能です。

クッキー

▍利点

Cookieの主な利点は、JavaScriptからアクセスできないことです。その結果、ローカルストレージほどXSS攻撃に対して脆弱ではありません。

• フラグHttpOnlyとセキュアCookieを使用する場合、JavaScriptがこれらのファイルにアクセスできないことを意味します。つまり、攻撃者がページで自分のコードを実行できたとしても、Cookieからアクセストークンを読み取ることはできません。
• Cookieは、すべてのHTTPリクエストでサーバーに自動的に送信されます。

▍デメリット

特定の状況によっては、Cookie内のトークンを保存できない場合があります。

• Cookieのサイズは4KBに制限されています。したがって、大きなJWTを使用する場合、それらをCookieに保存することはできません。
• APIサーバーにCookieを渡せないシナリオがあります。一部のAPIでは、ヘッダーにトークンを配置する必要がある可能性もありますAuthorization。この場合、トークンをCookieに保存することはできません。

XSS攻撃

ローカルストレージは、JavaScriptを使用して操作するのが非常に簡単であるため、XSS攻撃に対して脆弱です。したがって、攻撃者はトークンにアクセスして、それを有利に使用することができます。ただし、JavaScriptからHttpOnly Cookieに到達することはできませんが、これは、Cookieを使用してアクセストークンを盗むことにより、XSS攻撃から保護されていることを意味するものではありません。



攻撃者がアプリケーションでJSコードを実行できる場合、これは攻撃者がサーバーにリクエストを送信するだけで、トークンがこのリクエストに自動的に含まれることを意味します。攻撃者はトークンの内容を読み取ることができないため、このような作業スキームは攻撃者にとってそれほど便利ではありません。しかし、攻撃者がこれを必要とすることはめったにありません。さらに、この作業スキームでは、攻撃者が自分のコンピューターではなく、被害者のコンピューターを使用してサーバーを攻撃する方が有利な場合があります。

クッキーとCSRF攻撃

CSRF攻撃は、ユーザーが何らかの方法で特別な要求を行うように強制される攻撃です。たとえば、サイトは電子メールアドレスを変更する要求を受け入れます。

POST /email/change HTTP/1.1
Host: site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
Cookie: session=abcdefghijklmnopqrstu

email=myemail.example.com

このような状況では、攻撃者は非表示のフィールドを持つフォームを作成して、POSTリクエストをに送信する電子メールアドレスを入力できますhttps://site.com/email/change。この場合、セッションCookieはそのようなリクエストに自動的に含まれます。



ただし、この脅威はSameSite、応答ヘッダーの属性とアンチCSRFトークンを使用して簡単に保護できます。

小計

Cookieは攻撃の影響を完全に受けないわけではありませんが、トークンを保存する最善の方法は、可能な限り、トークンを選択することlocalStorageです。どうして？

• ローカルストレージとCookieはどちらもXSS攻撃に対して脆弱ですが、HttpOnly Cookieを使用すると、攻撃者が攻撃するのがより困難になります。
• CookieはCSRF攻撃に対して脆弱ですが、属性SameSiteとアンチCSRFトークンを使用することで、このような攻撃のリスクを軽減できます。

ヘッダーを使用する必要がある場合、Authorization: BearerまたはJWTが4KBより大きい場合でも、Cookieを使用できます。これは、OWASPガイドラインとも一致しています。「対応するデータは常にJavaScriptから利用できるため、セッションIDをローカルストレージに保存しないでください。クッキーはあなたのリスクを軽減するのに役立ちますHttpOnly。」

Cookieを使用してOAuth2.0トークンを保存する

トークンを保存する方法を簡単にリストしましょう。

• 方法1：トークンをローカルストレージに保存します。この方法はXSS攻撃の影響を受けやすくなっています。
• 方法2：トークンをHttpOnlyCookieに保存します。この方法はCSRF攻撃の影響を受けやすくなりますが、そのような攻撃のリスクを軽減できます。このトークンストレージオプションは、最初のオプションよりもXSS攻撃からわずかに保護されています。
• 方法3：リフレッシュトークンをHttpOnly Cookieに保存し、トークンにアクセスしてメモリに保存します。トークンを保存するこの方法は、CSRF攻撃の観点からはより安全であり、XSS攻撃からの保護がわずかに向上します。

以下では、トークンを格納する3番目の方法を詳しく見ていきます。これは、リストされている3つの方法の中で最も興味深いものに見えるためです。

CSRF攻撃の観点から、リフレッシュトークンをHttpOnly Cookieに保存する方が安全なのはなぜですか？

攻撃者は、にアクセスするフォームを作成する可能性があります/refresh_token。この要求に応答して、新しいアクセストークンが返されます。ただし、攻撃者がHTMLフォームを使用している場合、攻撃者は応答を読み取ることができません。攻撃者がフェッチまたはAJAX要求を正常に実行して応答を読み取るのを防ぐには、承認サーバーのCORSポリシーを正しく構成する必要があります。つまり、サーバーが許可されていないWebサイトからの要求に応答しないようにする必要があります。



どのように設定しますか？

ステップ1：ユーザーを認証するときにアクセストークンを返し、トークンを更新する

ユーザーが認証した後、認証サーバーはaccess_token（アクセストークン）とrefresh_token（更新トークン）を返します。アクセストークンは応答本文に含まれ、更新トークンはCookieに含まれます。



更新トークンを保存するためのCookieを設定するために使用する必要があるものは次のとおりです。

• フラグHttpOnly-JavaScriptがトークンを読み取らないようにします。
• secure=trueデータがHTTPS経由でのみ送信されるようにするフラグ。
• SameSite=strictCSRF攻撃から保護するために、可能な限りフラグを使用する必要があります。このアプローチは、認証サーバーがシステムフロントエンドと同じサイトに属している場合にのみ使用できます。そうでない場合、承認サーバーはバックエンドにCORSヘッダーを設定するか、他の方法を使用して、更新トークンを使用した要求が承認されたWebサイトによってのみ行われるようにする必要があります。

ステップ2：アクセストークンをメモリに保存する

アクセストークンをメモリに保存するということは、フロントエンドコードのトークンが変数に書き込まれることを意味します。もちろん、これは、ユーザーがサイトが開いているタブを閉じるか、ページを更新すると、トークンが失われることを意味します。これが、更新トークンがある理由です。

ステップ3：更新トークンを使用して新しいアクセストークンを取得する

アクセストークンが紛失または無効であることが判明した場合は、エンドポイントに連絡する必要があります/refresh_token。この場合、ステップ1でCookieに保存された更新トークンがリクエストに含まれます。その後、APIリクエストを行うために使用できる新しいアクセストークンを受け取ります。



これはすべて、JWTが4KBより大きくなる可能性があり、ヘッダーに配置できることを意味しAuthorizationます。

結果

ここで説明する内容は、クライアントにJWTを保存する方法と、プロジェクトをより安全にする方法に関する基本的な情報を提供するはずです。



JWTをクライアントにどのように保存しますか？