web-dev-qa-db-ja.com

JWTをsessionStorageに保存しても安全ですか?

この記事 Auth0から、ローカルストレージ(またはCookie)にJWTをローカルに保存することをお勧めします。しかし この記事 OWASPは、機密データをローカルで(セッションストレージでさえも)ストーリー化しないことを推奨しています

では、JWTトークンをローカルに保存しても安全ですか?

15

なんて奇妙なことでしょう。 1か月ほど前に基本的に同じ質問をしました。

結局、HTTPレベルで次のことを行う限り、JWTトークンにlocalstorageを使用しても問題ないと判断しました。

  • サイト全体がHTTPS経由で提供されていることを確認する
  • [〜#〜] hsts [〜#〜] の使用を確認してください
  • ライブになると、実際のリダイレクトURLだけがAuth0ルールとソースコードに含まれていることを確認してください
    • Angular CLIを使用します。WebPackによって提供されるツリーの揺れにもかかわらず、未使用の変数がコンパイルされたソースコードに引き続き表示されることがわかります。例:localhost:4200
    • localhostURlが実際にはAuth0(クライアントで許可されているリダイレクトページ)にないことを確認してください。テスト用に別のAuth0アカウントを作成する
  • すべてのHTTP応答にX-Frame-Optionsヘッダーを追加し、それをDenyに設定します
  • X-XSS-Protection1に設定します
  • X-Content-Type-Optionsnosniffに設定します
  • Content-Security-Policyが自分のドメイン名に制限されていること、およびスクリプトをプルしている可能性のあるCDNがあることを確認してください
  • Referrer-Policysame-Originに設定します
  • Auth0のJWTの有効期限を1時間に制限する

上記は securityheaders.io でA/A +を提供し、最も一般的な攻撃(iframeにWebサイトを埋め込み、localstorageからデータを抽出するなど)を防ぎます。

18
JMK

まあそれは依存します。アプリケーションにXSSの脆弱性がある場合、攻撃者はローカルストレージからJWTを抽出して使用できます。

私が使用した方法で、Auth0はJWTストレージとしてCookieを使用し、フラグHTTP Only and Secureを使用することを示していると思います。XSSの脆弱性がある場合、Cookieを読み取ることができず、安全な方法でのみ輸送されます。最近のすべてのフレームワークにCSRF緩和策が含まれているため、CSRFは最近のリスクが少なくなっています。

これは、検証がサーバー側のCookieからJWTを抽出して検証することを意味します。私の個人的な見解は、CSRFは攻撃面が大きいXSS攻撃に比べて簡単に見つけて緩和できるため、Cookieをストレージとして使用することです。

5
McMatty