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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#757 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
backend-api-design, security

Línea de trabajo

Empieza leyendo NestedTokenLoader::checkContentTypeHeader() y los accesores del encabezado JWE que utiliza; compáralos con NestedTokenBuilder, que escribe cty en el encabezado protegido. Cambia la comprobación para que acepte cty solo del encabezado protegido compartido y luego revisa o añade cobertura para la serialización JSON con cty solo en un encabezado no protegido. El trabajo estará completo cuando ese caso se rechace y cty protegido siga funcionando; el issue no indica ningún archivo de pruebas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).

Lenguaje dominante
PHP
Estrellas
954
Forks
119
Merge medio
48 min
PR fusionados (30 d)
17

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de web-token/jwt-framework

Todos los issues de web-token/jwt-framework

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.