Vượt kiểm tra issuer trong authlib joserfc do xử lý claim JWT dạng mảng

joserfc là một thư viện Python cung cấp triển khai của một số tiêu chuẩn JSON Object Signing and Encryption (JOSE). Trước phiên bản 1.7.3, JWTClaimsRegistry áp dụng phép đối sánh theo membership cho các claim iss và sub có giá trị dạng list, cho phép một iss dạng mảng chứa issuer kỳ vọng vượt qua phép kiểm tra equality vốn được dự định và dẫn đến bypass kiểm tra issuer. Vấn đề này đã được sửa trong phiên bản 1.7.3.

• CNA xác định authlib joserfc bị ảnh hưởng ở các phiên bản < 1.7.3.
• GitHub advisory biểu diễn cùng phạm vi là <=1.7.2 và xác định phiên bản đã được vá là 1.7.3.
• Không có sản phẩm song song, nhánh phát hành bổ sung hoặc qualifier về deployment nào được xác nhận trong bằng chứng hiện có.

Lỗi nằm trong JWTClaimsRegistry, nơi các claim được cấu hình có giá trị dạng list bị kiểm tra theo cơ chế membership matching thay vì luôn được so sánh bằng giá trị và kiểu dữ liệu mong đợi. Với các registered claim vốn chỉ được phép là một StringOrURI như iss, sub, jti và nonce, một giá trị dạng mảng chứa chuỗi hợp lệ vẫn có thể vượt qua kiểm tra. Đối với iss, điều này cho phép một token có issuer dạng mảng chứa issuer kỳ vọng được chấp nhận như thể phép kiểm tra equality đã thành công. Điều kiện khai thác là token phải đi qua một verifier sử dụng đường dẫn validation bị ảnh hưởng; bằng chứng hiện có không xác định cách attacker có được chữ ký hợp lệ trong mọi deployment. Advisory của vendor minh họa vấn đề bằng một token đã được ký và cho thấy payload do attacker kiểm soát có thể được verifier chấp nhận. Bản sửa tách validation riêng cho các claim đơn giá trị và chỉ duy trì xử lý list cho aud hoặc các claim được ứng dụng ghi nhận rõ là đa giá trị.

Lỗi có thể bị tiếp cận qua mạng khi ứng dụng nhận JWT và dùng JWTClaimsRegistry để kiểm tra claim. Đánh giá được cung cấp cho thấy không yêu cầu quyền đặc biệt và không cần user interaction, nhưng attack complexity được đánh giá là cao vì attacker vẫn phải đưa được token qua các kiểm tra còn lại của deployment. Bản ghi đánh dấu public exploit là true và advisory của vendor có chứa proof of concept. Điều này xác nhận exploit material công khai, nhưng không tự nó chứng minh việc khai thác trong một chiến dịch, nạn nhân hoặc môi trường cụ thể.

Kết quả kỹ thuật trực tiếp là issuer-validation bypass khi iss dạng mảng chứa giá trị issuer kỳ vọng được xử lý như một equality match thành công. Nếu ứng dụng dùng issuer hoặc subject để gắn token với tenant, người dùng, service hoặc quyền truy cập, attacker có thể khiến payload do mình kiểm soát được verifier chấp nhận và từ đó có khả năng đạt quyền hoặc thực hiện hành động trái phép. Đây là khả năng phụ thuộc vào logic authorization của ứng dụng, không phải kết quả bắt buộc trong mọi deployment. Bản đánh giá hiện có không xác định tác động đến tính sẵn sàng của dịch vụ.

Một verifier bị ảnh hưởng có thể coi token chứa issuer hoặc claim định danh bị giả mạo là hợp lệ. Tùy thiết kế của ứng dụng phụ thuộc vào issuer, subject hoặc các claim liên quan, điều này có thể dẫn đến truy cập trái phép, giả mạo danh tính hoặc thực hiện các thao tác có ảnh hưởng đến tính toàn vẹn của dữ liệu và phiên làm việc. Mức độ dữ liệu bị lộ và quyền đạt được phụ thuộc vào các quyết định authorization phía ứng dụng, không chỉ vào thư viện. Bản ghi không nêu một nạn nhân, chiến dịch hoặc sự cố cụ thể.

1. Nâng cấp authlib joserfc lên phiên bản 1.7.3, là phiên bản được CNA và vendor xác định đã sửa lỗi.
2. Nếu chưa thể nâng cấp, áp dụng kiểm tra bổ sung để từ chối giá trị dạng list cho các claim đơn giá trị iss, sub, jti và nonce; chỉ cho phép nhánh xử lý list đối với aud hoặc claim được tài liệu hóa rõ là đa giá trị.
3. Kiểm thử lại toàn bộ authentication và authorization flow sau khi thay đổi, bao gồm các trường hợp issuer hợp lệ, issuer sai và claim có kiểu dữ liệu không hợp lệ.
4. Không suy luận rằng các nhánh phát hành khác đã an toàn chỉ từ việc một phiên bản cụ thể được vá; cần xác minh trạng thái của mọi nhánh đang được triển khai.

1. Kiểm kê các môi trường Python, lockfile và dependency tree có cài authlib joserfc, sau đó đối chiếu từng bản cài đặt với ranh giới affected và patched trong phần affected_summary.
2. Tìm các đường dẫn sử dụng JWTClaimsRegistry để kiểm tra iss, sub, jti hoặc nonce, đặc biệt trong các service dùng claim để xác định danh tính hoặc quyền truy cập.
3. Trong môi trường kiểm thử, xác nhận verifier từ chối các registered claim đơn giá trị khi giá trị của chúng được biểu diễn dưới dạng list, đồng thời vẫn xử lý đúng các trường hợp aud đa giá trị được ứng dụng hỗ trợ.
4. Rà soát telemetry và log xác thực để tìm các JWT được chấp nhận trong khi iss, sub, jti hoặc nonce có kiểu mảng. Đây là dấu hiệu cần điều tra, không phải IOC đã được vendor xác nhận.
5. Không coi việc không thấy sự kiện trong log là bằng chứng hệ thống an toàn; cần kết hợp kiểm tra dependency với kiểm tra code path và hành vi validation.