開発者ツール · JWT デコーダー
JWT ペイロードは暗号化されていません: トークンを持っている人なら誰でも読み取ることができます
· なぜそれが重要なのか
jwt プライバシー セキュリティ
Base64url はスクランブルのように見えますが、可逆エンコードです。この投稿では、署名付きトークンのクレームがどの程度読みやすいか、クレームに何が含まれているか、代わりに JWE が必要な場合について説明します。
暗号化されているように見える - 個人データをトークンに入れるという誤解
長いbase64urlセグメントはスクランブルされているように見えるため、チームはそれらを隠蔽データとして扱いたくなります。視覚効果は誤解を招きます。署名付き JWT を保持している人は誰でも、署名キーや検証キーを持たずに公開エンコードを反転して JSON ペイロードを読み取ることができます。
ToolAcre は、ヘッダーとペイロードをローカルでデコードすることによってそのプロパティを示します。通常の JWS ペイロードは暗号化されないため、暗号化は解除されません。検査の容易さはトークンの設計を形作るものでなければなりません。すべての正当な所有者とすべての偶発的な受信者が見ることができる情報のみをエンコードします。
署名済み、封印されていない: 有効な JWS はペイロードの機密性ではなく完全性を保護できます。
有効な署名または MAC により、適切に構成された検証ツールが変更を検出し、トークンを信頼できる鍵マテリアルに関連付けることができます。それは、検証者のポリシー内の整合性と出所の証拠です。クライアント、プロキシ、ロガー、または圧縮文字列を取得するその他のユーザーに対して、保護されたコンテンツが隠蔽されることはありません。
デコーダは決して検証しないため、その整合性さえ確立できません。トークンがそれ自体について何を述べているかを示し、署名バイトを未検証として報告します。この区別により、読み取り可能なものは偽造されたものであると想定し、署名されたものは機密であると想定するという 2 つの相反する間違いが回避されます。
デコーダーが示すもの — すべてのクレーム、プレーン JSON で、キーは必要ありません
ヘッダーとペイロードの場合、ToolAcre はbase64url を変換し、パディングを復元し、バイトを UTF-8 として復元し、JSON オブジェクトを解析します。シークレットは参加しません。その後、クレーム テーブルには、文字列値が直接表示され、構造化された値が `sub`、`aud`、`exp` などの登録名の説明とともに JSON テキストとして表示されます。
その出力は透明性を補助するものであり、真実の神託ではありません。偽造されたトークンは、正規のトークンと同じサブジェクトと役割を表示できます。クレームを読むのにキーは必要ありません。認証には成功した検証に加えて、発行者、対象者、時間、および使用側サービスのアプリケーションのチェックが必要であると考えられています。
トークンの漏洩場所 — ログ、URL、リファラーヘッダー、ブラウザ履歴、サードパーティスクリプト
トークンは、アプリケーション ログ、コピーされたサポート メッセージ、URL、リファラー伝播、ブラウザ履歴、スクリーンショット、フィールドにアクセスできるスクリプトを通じて漏洩する可能性があります。正確なパスはシステムによって異なりますが、ペイロードの可読性は、期限切れまたは使用不能なトークンが依然として個人情報や運用情報を漏洩する可能性があることを意味します。
URL クエリ文字列やルーチン ログにコンパクトな資格情報を含めないでください。診断を共有する前にそれらを編集してください。署名はクレームを無害化するものではなく、トランスポート暗号化はエンドポイント間の移動中にデータを保護するだけです。承認されたエンドポイントや偶発的なストレージでは、平文のトークン文字が表示される可能性があります。
ペイロードに含まれるもの — 識別子と認証データ。秘密や保持者が見るべきではないデータは含まれません
ペイロードには通常、受信者が検証後に決定できるように識別子と認証コンテキストが必要です。パスワード、秘密鍵、またはトークン所有者が読み取れないようにする必要がある情報を持ち込んではなりません。個人データを最小限に抑え、消費サービスに必要のないプロファイル フィールドの都合のよい重複を避けます。
ロールとスコープは、エンコードされているという理由だけで秘密ではありませんが、検証されるまで信頼されません。最小限の開示と最小限の特権を中心にクレーム セットを設計します。消費者が文書化されたジョブを実行するためにフィールドを必要としない場合、そのフィールドを除外しておくことで漏洩のあらゆる影響が軽減されます。
実用的な例 — サンプル トークンをデコードし、傍観者が学習する内容を正確にリストする
`sub`、`email`、`tenant`、`roles`、`iat`、および `exp` を含む合成ペイロードをデコードします。傍観者は、指定されたアカウント識別子、アドレス、組織コンテキスト、アサートされたアクセス許可、およびキーなしでタイミングを学習します。それらの主張が本物かどうかは別の問題です。彼らのテキストはすでに公開されています。
有効期限切れの資料またはテスト資料のみを使用して、発行者が作成した各トークン プロファイルで監査を繰り返します。すべてのフィールドとその消費者を記録します。 ToolAcre は、表示されているコンテンツを列挙するのに役立ちますが、組織の合法的な処理、機密性、または保持ルールを決定することはできません。
暗号化されたコンパクト トークンには 5 つの部分があり、この JWS デコーダは復号化するのではなく識別します。
請求を所有者または仲介者に対して秘密にしておく必要がある場合、暗号化された設計が必要になる場合があります。コンパクト JWE は 5 つの部分からなり、受信者の復号化キーを使用します。 ToolAcre は 5 つのセグメントを暗号化された入力として識別し、キーがなければ内容を明らかにできないと説明しています。
暗号化では、このデコーダを超えて、キー配布、アルゴリズム ポリシー、動作障害モードが導入されます。また、整合性チェックと認可チェックの必要性がなくなるわけではありません。これは、含まれるデータが少ないはずのペイロードへの表面的なアップグレードとしてではなく、脅威モデルから選択してください。
要点: ペイロードがパブリックであると仮定します。ToolAcre JWT デコーダーで独自のトークンの 1 つをデコードし、それが公開するものを監査します。
通常の JWT ペイロードは、トークンがどこに移動しても読み取り可能であると仮定します。 ToolAcre のデコード専用ビューは、誰が値を発行したかを証明するためではなく、クレームの暴露を監査するために使用します。シークレットや不要な個人フィールドを隠すためにbase64urlに依存するのではなく、削除してください。
機密性が本当に必要な場合は、文書化されたセキュリティ プロパティに機密性が含まれているメカニズムを使用し、それに応じてキーを管理します。署名されているか暗号化されているかにかかわらず、信頼は設定された暗号検証とポリシーから得られ、デコーダーが構造化された出力を表示したという事実からは決して得られません。