Base64UrlSafe accepts bytes 0x80 to 0xFF when ext-sodium is loaded

Đang mở
  • Có gì không ổn?
#766 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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ó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
76/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, security

Hướng nghiên cứu

Start with Base64UrlSafe::decodeNoPadding() and compare its sodium path with the pure PHP decoder; the issue says the class handles key material too. Check how the existing code raises RangeException for invalid input, then verify that bytes outside the base64url alphabet are rejected consistently while valid input still decodes. The issue gives a reproduction using QUJ_ and QUJ\xFF; use these to confirm the behavior.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug
Version(s) affected

3.4.9 to 3.4.12, 4.0.7 to 4.0.8, 4.1.0 to 4.1.10, 4.2.0 to 4.2.5, and the 4.3.x and 5.0.x branches, when ext-sodium is linked against libsodium 1.0.21 or older on a platform where char is signed (x86-64)

Description

When ext-sodium is loaded, Base64UrlSafe::decodeNoPadding() hands its input to sodium_base642bin() and relies on libsodium to reject characters outside the base64url alphabet. Up to 1.0.21, libsodium decodes every byte from 0x80 to 0xFF as _ where char is signed (seen with 1.0.18 on x86-64). This was fixed upstream in 1.0.22 (jedisct1/libsodium@a615d0ed74, "base64: reject signed chars"). The pure PHP decoder of the same class rejects these bytes, so the result depends on the environment.

Every token segment goes through this decoder. Each _ in the signature of a compact JWS, or in the encrypted key, IV, ciphertext or tag of a compact JWE, can be replaced by any byte from 0x80 to 0xFF, and the token still loads with the same header, payload and plaintext. The header and payload segments are used as received, so they cannot be changed this way.

Nothing is forged or disclosed. A token holder can however produce other strings for a token the application accepts, which matters to applications that recognise a token by its string or its hash (deny-list of revoked tokens, replay cache).

The sodium path was added in #636 (4.1.0) and backported in #644 (3.4.9, 4.0.7).

How to reproduce
use Jose\Component\Core\Util\Base64UrlSafe;

echo bin2hex(Base64UrlSafe::decodeNoPadding('QUJ_')), PHP_EOL;    // 41427f
echo bin2hex(Base64UrlSafe::decodeNoPadding("QUJ\xFF")), PHP_EOL; // 41427f with ext-sodium, RangeException without it
Possible Solution

Reject the bytes outside the alphabet on the sodium path too, with the same RangeException as the pure PHP path. The class also decodes key material (k, d…), so the check should not take a time that depends on the characters, which strspn() does before PHP 8.4. Decoding, re-encoding the result with sodium_bin2base64() and comparing with hash_equals() rejects all 128 high bytes, gives the same output on valid input, and keeps most of the speed-up of the sodium path (22 ms on 1.3 MiB, against 12.5 ms today and 409 ms for the pure PHP path).

Additional Context

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

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

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của web-token/jwt-framework

Tất cả issue của web-token/jwt-framework

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.