NestedTokenLoader: read "cty" from the JWE protected header only

オープン 初心者向け
  • 何か問題がありますか？
#757 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
74/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
php
領域
backend-api-design, security

調査の方向性

まず NestedTokenLoader::checkContentTypeHeader() と、それが使用する JWE ヘッダーのアクセサーを読み、保護ヘッダーに cty を書き込む NestedTokenBuilder と比較してください。チェックを変更し、cty は共有保護ヘッダーからのみ受け入れるようにしてから、保護されていないヘッダーにのみ cty がある場合の JSON シリアライズのテストを確認するか、追加してください。そのケースが拒否され、保護された cty が引き続き機能すれば完了です。Issue にはテストファイルの指定がありません。

索引モデルが issue の本文から書いたものです。

説明

enhancement
Version(s) affected

All versions since nested tokens were added (1.1.0): 3.4.x, 4.0.x, 4.1.x, 4.2.x, and the 4.3.x and 5.0.x branches.

Description

NestedTokenLoader::checkContentTypeHeader() decides that a JWE carries a nested token from cty, read from the shared protected header, then from the shared unprotected header, then from the per-recipient header. The last two are not covered by the authentication tag of the JWE. A JWE issued without cty in its protected header can therefore be accepted as a nested token once it is serialized in a JSON form with cty in an unprotected member, which needs no key.

The impact is limited:

  • the JWE must decrypt with the application's keys, and the inner JWS must verify against the application's signature keys: nothing is forged or disclosed, and the inner signature is always checked;
  • a protected cty cannot be overridden or removed, because the headers must be disjoint;
  • the JWE loader must accept a JSON serialization;
  • with public-key key management (RSA-OAEP, ECDH-ES), anyone holding a valid JWS can already wrap it in a JWE with a protected cty.

What remains is a confusion between a JWE the issuer marked as a nested JWT and a JWE around a JWS that the issuer did not mark. NestedTokenBuilder always writes cty in the protected header, and JWTs use the compact serialization, where every header parameter is protected, so the unprotected locations are not needed. The rest of the library already reads security-relevant parameters from the protected header only (alg in JWSVerifier; JWEDecrypter does not take alg/enc from the shared unprotected header).

Possible Solution

Read cty from the shared protected header only. This refuses nested tokens from other producers that put cty only in an unprotected member of a JSON serialization. Either do it in 4.3.0 with an UPGRADE note, or accept that case with a deprecation in 4.3.0 and refuse it in 5.0.0.

Applications can enforce it today with a protected-only cty checker among the header checkers of the JWE loader used by the nested token loader, for example new IsEqualChecker('cty', 'JWT') (protected-only by default, case-sensitive), or a CallableChecker doing a case-insensitive comparison.

Additional Context

Same pattern as GHSA-jc38-x7x8-2xc8 (a decision taken on an unprotected header), without its consequence: decryption and signature verification still use the application's keys.

Found by the Anthropic OSS Scanner (ANT-2026-YGYNZW0J).

主要言語
PHP
スター
954
フォーク
119
平均マージ
48分
マージ済み PR（30日）
17

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

web-token/jwt-framework のほかの issue

web-token/jwt-framework の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。