SD-JWT: VerifiedSDJWT::getIssuerSignedJwt() keeps the signatures the loader did not verify

未关闭
  • 哪里不对？
#765 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
55/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
php
领域
backend-api-design, security

调研方向

Start by reading SDJWTVerifier::process() and trace how LoadingResult::getSignatureIndex() is used when the JWS is verified and returned. Review JsonSerializationTest::aGeneralSdJwtIsVerifiedByAnyOfItsSignatures; add coverage for a prepended unsigned signature and update the expectation for the returned verified JWT. Done means the returned issuer-signed JWT exposes the verified signature first, while the presented SD-JWT remains available through getSdJwt().

由索引模型根据 Issue 内容生成。

描述

bug
Version(s) affected

4.3.x-dev and 5.0.x-dev (unreleased), since #750

Description

When the loader of the Issuer-signed JWT accepts the general JWS JSON serialization, SDJWTVerifier::verify() and verifyWithKeyBinding() return the whole JWS in VerifiedSDJWT::getIssuerSignedJwt(), every signature included, although only one of them was verified. Whoever holds the SD-JWT can put an entry of their own in front of the Issuer's signature: the protected header at index 0 of the "verified" Issuer-signed JWT is then theirs (typ, kid, x5c…), including a typ that the configured TypeChecker refuses.

The claims, the header checkers and the algorithm check still apply to the signature that was verified, so no token is accepted that should be refused. The impact is on applications that read a header parameter of the result to branch or to attribute the issuer.

Conditions: the loader has JSONGeneralSerializer (jws_json_general in the bundle, whose default is compact only). With key binding, only the Holder can do it, because sd_hash covers the first signature.

How to reproduce
  1. Issue a compact SD-JWT whose protected header is {"alg":"ES256","typ":"visitor+sd-jwt","kid":"issuer-2026"}.
  2. Rewrite it as a general JSON SD-JWT whose signatures start with {"protected": b64u({"alg":"ES256","typ":"staff+sd-jwt","kid":"chosen-by-the-holder"}), "header": {"disclosures": [...]}, "signature": b64u(64 arbitrary bytes)}, followed by the Issuer's entry.
  3. Verify it with a loader that has the compact, flattened and general serializers, ES256 and TypeChecker(['visitor+sd-jwt']).

The token is accepted with the Issuer's claims, the loader reports signature index 1, and getIssuerSignedJwt()->getSignature(0)->getProtectedHeader() is the header written by the holder.

Possible Solution

SDJWTVerifier::process() uses LoadingResult::getSignatureIndex() for its algorithm check, then returns $loaded->getJws() and drops the index. Return $loaded->getJws()->split()[$loaded->getSignatureIndex()] instead, so that signature 0 is the verified one in every serialization; the token as presented stays available from getSdJwt().

Also:

  • say in the docblock of getIssuerSignedJwt() and in the documentation that only the protected header is authenticated (the unprotected header of the verified entry can be changed by anyone, in the flattened serialization too);
  • update JsonSerializationTest::aGeneralSdJwtIsVerifiedByAnyOfItsSignatures, which expects two signatures, and add a test with a prepended unsigned entry.
Additional Context

Found by the Anthropic OSS Scanner (ANT-2026-MHZ2TD30). To be fixed before 4.3.0.

主要语言
PHP
星标
954
派生
119
平均合并
48 分钟
30 天内合并 PR
17

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

web-token/jwt-framework 的其他 Issue

查看 web-token/jwt-framework 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。