メインコンテンツにスキップ
ブログコンピュート期限切れのないJWTの危険性:隠れたセキュリティ脆弱性

期限切れのないJWTの危険性:隠れたセキュリティ脆弱性

JWTの危険性

JSONウェブトークン(JWT)は、多くの組織で好まれる認証方法となっている。JWTは実装が簡単なため、APIやWebアプリケーションを保護するための一般的な選択肢となっている。しかし、適切に管理されなければ、JWTはセキュリティの脆弱性をもたらし、システムを危険にさらす可能性があります。あなたもおそらく使ったことがあるだろう。

しかし、あなたはそれらを導入し、安全に扱ったことがあるだろうか?

アカマイのブログ投稿は、JWT に関連する一般的なセキュリティの脆弱性をいくつか取り上げています。これは、JWT を不適切に管理することによる潜在的なリスクへの警鐘でした。今回のブログ投稿では、これを踏まえ、見過ごされがちな脆弱性、すなわち期限切れでない JWT に焦点を当てたいと思います。この問題がどのようにして発生するのか、関連するセキュリティの脆弱性とともに見ていきます。そして、これらのセキュリティ脆弱性から身を守る方法を知ってもらうために、いくつかのガイダンスを提供します。

一般的なJWT脆弱性の概要

本題に入る前に、前述のブログ記事で強調されたJWTの脆弱性について簡単におさらいしておこう。筆者が言及したJWTに対する6つの脅威は以下の通りである:

  1. サーバがトークンを検証せずに使用することを許可すること:これは、サーバがトークンの完全性をチェックしない場合に発生する可能性があり、攻撃者がトークンを操作して悪用することを容易にします。攻撃者はまた、検証アルゴリズム(alg)をnoneに設定し、サーバがトークンを全く検証しないように操作しようとする可能性があります。
  2. 異なるアプリケーションに同じ秘密鍵を使用すること:鍵が公開されると、複数のアプリケーションを危険にさらす可能性がある。
  3. 弱い署名アルゴリズムの使用:弱い署名アルゴリズムはより簡単にクラックされ、不正アクセスにつながる可能性がある。
  4. 短い秘密鍵や低エントロピーの秘密鍵を選ぶこと:短すぎる鍵やランダム性に欠ける鍵は、ブルートフォース攻撃を受けやすい。
  5. JWTのペイロードに機密データを保持すること:ペイロードに格納された機密情報は、トークンが傍受された場合に漏洩する可能性があります。
  6. キーの混乱:鍵の管理を誤ると、不正な検証を引き起こし、不正アクセスを許してしまう可能性がある。

これらの脆弱性に関する詳細な報道については、ブログ記事をチェックしてほしい。続いて、追加の脆弱性を見てみよう:期限切れでないJWT。

追加の脆弱性:期限切れでない JWT

次のJWTを見てみよう。少し前に私が遭遇した実例に基づいている:

ユーザーのAPIへのアクセスを認証・認可するために使用されるJWTです。なりすましを防ぐため、安全な秘密鍵で署名されている。一見すると問題なさそうに見える。しかし、ペイロードをよく見てみよう:

{
  "platform_code": "@xlist!v1.0.4-c14b73af",
  "issued_at": "2024-04-30T11:15:57.075z",
  "product_code": "1e76ce1e-97c7-49d8-aadf",
  "ttl": 86400000,
  "iat": 1714475757
}

そのttlクレームを見たとき、あなたはおそらくtime-to-liveを思い浮かべるだろう。つまり、これはおそらくJWTが有効である期間に関係している。これは有効期限に違いない。

ここで簡単な計算ができる。たぶん86,400,000は秒数で、その場合、発行者はこのJWTを1000日間有効にするつもりなのだろう。あるいは、ミリ秒という意味かもしれない。その場合、このJWTは1日間有効であることを意図している。それも意味があるかもしれない。

JWTの仕様では、有効期限はttlではなくexpと指定されている:

exp」(有効期限)クレームは、JWTを処理に受け入れてはならない[MUST NOT]有効期限日時を特定する。 exp "主張の処理では、現在の日付/時刻が "exp "主張に記載された有効期限日時より前でなければなら ない[MUST]。
実装者は、クロックスキューを考慮するために、通常は数分以下 の小さな余裕を提供してもよい[MAY]。 その値はNumericDate値を含む数値でなければならない[MUST]。 この主張の使用はオプションである。

では、ここで2つの問題がある。

まず、このJWTの発行者は有効期限を指定するためにttlを使っているが、ttlは標準的なJWTクレームではない。JWTを扱うように設計されたほとんどのライブラリは、ttlをトークンの有効期限に関する命令として認識しません。これは互換性の問題につながり、トークンは期限切れでないものとして扱われる可能性が高い。

第二に、expクレームでは、発行時刻からの相対的なミリ秒(または秒)数ではなく、実際の有効期限のタイムスタンプが必要である。この混乱は、おそらくexpではなくttlを使用したことに起因する。とはいえ、発行者はトークンの適切な有効期限を保証するために、expクレームの期待される形式を理解する必要がある。

JWTの有効期限を設定しなかったり、(この例のように)間違って設定したりすると、JWTは有効期限がないものとして扱われます。そして、これは重大なセキュリティ上の欠陥をもたらす。  

適切な有効期限がなければ、JWTは攻撃者によって再利用されたりによって再利用されたり、意図した寿命を超えて漏洩したりする可能性があります、不正アクセスのリスクが高まります。

JWTセキュリティ脆弱性の緩和

さて、潜在的なセキュリティの脆弱性について説明したところで、次の質問は「それに対してどうすべきなのか」ということだ。幸いなことに、この脆弱性を緩和するのは簡単で単純なことだ!

常に exp claimを 使用する こと。生成するすべてのトークンに有効期限を設定してください。その際、JWTの仕様に準拠し、意図したとおりに期限切れになるように、期待値形式の標準的なexp claimを必ず使用してください。

アプリケーションとライブラリを更新する。アプリケーションと使用しているライブラリが更新され、最新のJWT標準に準拠していることを確認してください。定期的なアップデートは、セキュリティの脆弱性を修正し、互換性を向上させるのに役立ちます。

以上です。これらのシンプルなガイドラインに従えば、期限切れでないJWTを介した不正アクセスのリスクを大幅に減らすことができます。これにより、JWT実装の全体的なセキュリティが向上します。

結論 

JWTの脆弱性を理解し対処することは、アプリケーションのセキュリティを維持するために極めて重要です。この投稿では、期限切れでないトークンのリスクを強調した。exp claimを正しく使用し、ライブラリを更新し続けることで、このリスクを効果的に軽減することができます。

さらなるセキュリティソリューションとベストプラクティスについては、Linodeのドキュメントで利用可能なリソースを検索してください。Linodeは、アプリケーションからセキュリティの脆弱性を取り除くための包括的なガイドを提供しています。

コメント 

コメントを残す

あなたのメールアドレスは公開されません。必須項目には*印がついています。