NestedTokenLoader: read "cty" from the JWE protected header only
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 74/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- php
- Lĩnh vực
- backend-api-design, security
Hướng nghiên cứu
Bắt đầu bằng cách đọc NestedTokenLoader::checkContentTypeHeader() và các accessor của JWE header mà nó sử dụng; so sánh chúng với NestedTokenBuilder, thành phần ghi cty vào protected header. Thay đổi phần kiểm tra để chỉ chấp nhận cty từ shared protected header, sau đó xem lại hoặc bổ sung kiểm thử cho việc tuần tự hóa JSON khi cty chỉ nằm trong unprotected header. Hoàn tất khi trường hợp đó bị từ chối còn protected cty vẫn hoạt động; issue không nêu tên tệp kiểm thử.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
ctycannot 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).
- Ngôn ngữ chính
- PHP
- Star
- 954
- Fork
- 119
- Merge trung bình
- 48 phút
- Pull request đã merge (30 ngày)
- 17
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của web-token/jwt-framework
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
web-token/jwt-framework#773 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 57/100
web-token/jwt-framework#772 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
web-token/jwt-framework#771 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
web-token/jwt-framework#770 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
web-token/jwt-framework#769 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của web-token/jwt-framework
Issue tương tự
-
enhancement priority Sales
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
novalo-dev/Prestashop-MCP-Server#201 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Include flows spanning the full report time windowCó thể đã có người làm @somethingwithproof đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Cacti/plugin_flowview#306 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug origin: upstream priority: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
mattytap/Mattytap-Sermons#105 ·
-
priority:low type:bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
crazy-goat/workerman-bundle#1189 ·
Maintainer thường phản hồi trong vòng 1 ngày