Tiếng Việt

Công cụ dành cho nhà phát triển · Bộ giải mã JWT

Base64 so với Base64url: Tại sao JWT không thành công trong bộ giải mã Base64 tiêu chuẩn

· Cách thức hoạt động

jwt base64 mã hóa

Hai bảng chữ cái mã hóa hội tụ trên JWT byte được giải mã
Hình minh họa vector ToolAcre gốc

Dán phân đoạn JWT vào bộ giải mã base64 thông thường và phân đoạn này có thể gặp vấn đề về ký tự hoặc phần đệm. Bài đăng này giải thích các yêu cầu của biến thể base64url JWS và cách chuyển đổi giữa hai biến thể này.

Ký tự không hợp lệ, phần đệm không chính xác - lỗi xuất hiện khi base64 đáp ứng base64url

Thông báo "ký tự không hợp lệ" hoặc "đệm không chính xác" thường có nghĩa là phân đoạn JWT đã được cấp cho bộ giải mã mong đợi Base64 thông thường. Mã thông báo có thể được sao chép chính xác. Cách biểu diễn của nó tuân theo các quy ước base64url, trong khi tiện ích nhận chấp nhận một bảng chữ cái có liên quan nhưng không giống hệt nhau hoặc nhấn mạnh vào phần đệm rõ ràng.

ToolAcre tránh sự không phù hợp đó cho tiêu đề và tải trọng. Bộ giải mã byte của nó loại bỏ khoảng trắng, dịch các ký hiệu an toàn URL, khôi phục phần đệm bị bỏ qua khi độ dài cho phép, sau đó chuyển đổi byte thành UTF-8 nghiêm ngặt. Lỗi ở bất kỳ giai đoạn nào sẽ trở thành lỗi INVALID_JWT thay vì ngoại lệ thô của trình duyệt.

Hai bảng chữ cái — dấu cộng và dấu gạch chéo so với dấu gạch nối và dấu gạch dưới và lý do URL buộc phải thay đổi

Base64 tiêu chuẩn sử dụng dấu cộng và dấu gạch chéo cho hai vị trí bảng chữ cái cuối cùng. Base64url gán dấu gạch nối và dấu gạch dưới cho các vị trí tương tự. Các giá trị sáu bit cơ bản không thay đổi, do đó việc dịch `-` sang `+` và `_` sang `/` sẽ bảo toàn mọi byte được giải mã; chỉ thay đổi chính tả an toàn vận chuyển.

Những sự thay thế đó quan trọng trong các kênh mà dấu cộng hoặc dấu gạch chéo đã có cú pháp. Chính tả an toàn URL giúp giảm việc diễn giải ngẫu nhiên bằng cách xử lý biểu mẫu hoặc đường dẫn. Nó không thêm tính bí mật, tính toàn vẹn hoặc tính xác thực. Bất kỳ ai nhận được một phân đoạn đều có thể đảo ngược các thay thế và khôi phục các byte tương tự mà không cần khóa mật mã.

Phần đệm - tại sao JWS loại bỏ các dấu bằng và cách khôi phục chúng cho bộ giải mã nghiêm ngặt

ToolAcre chấp nhận phần đệm bị bỏ qua. Sau khi chuẩn hóa bảng chữ cái, nó kiểm tra độ dài đoạn theo modulo 4. Phần còn lại của hai cần hai dấu bằng và phần còn lại của ba cần một. Phần còn lại của một là không thể có đối với giá trị Base64 hoàn chỉnh và bị từ chối dưới dạng một chuỗi bị cắt bớt thay vì được đoán thành hình dạng.

Khôi phục phần đệm là việc đóng khung cơ học chứ không phải sửa chữa mã thông báo. Việc thêm dấu bằng không thể khôi phục các ký tự bị mất trong quá trình sao chép và việc giải mã byte thành công không cho thấy các byte đến từ nhà phát hành. Việc triển khai chỉ đơn thuần là xây dựng lại độ dài chuẩn mà bộ giải mã trình duyệt yêu cầu trước khi gọi `atob`.

Giải mã toàn bộ mã thông báo cùng một lúc - sai lầm khi không tách các dấu chấm trước

Mã thông báo có chữ ký nhỏ gọn phải được phân tách trên các dấu chấm của nó trước khi bất kỳ phân đoạn nào được giải mã. Việc chuyển `header.payload.signature` tới hàm Base64 sẽ giới thiệu các dấu chấm thuộc về tuần tự hóa JWT chứ không phải bảng chữ cái Base64. ToolAcre yêu cầu chính xác ba phân đoạn cho đầu vào có hình JWS này và báo cáo số lượng quan sát được khi không có cấu trúc đó.

Trường hợp gồm năm phần nhận được một thông báo JWE riêng biệt vì tuần tự hóa thu gọn được mã hóa không phải là cùng một đối tượng. Thay vào đó, hai hoặc bốn phần gợi ý việc cắt bớt hoặc nhập sai. Quá trình kiểm tra cấu trúc này diễn ra trước phần diễn giải JSON, giúp phân biệt lỗi sao chép với văn bản được mã hóa không đúng định dạng hoặc JSON không đúng định dạng.

Ví dụ đã hoạt động - chuyển đổi một phân đoạn từ base64url sang base64, đệm nó và giải mã nó thành JSON

Để chuyển đổi thành công, hãy thực hiện `eyJhbGciOiJIUzI1NiJ9`. Nó không chứa các ký tự bảng chữ cái khác nhau giữa các biến thể, nhưng phần đệm bị thiếu của nó vẫn minh họa cho đường dẫn. Chiều dài của nó cho phép phục hồi phần đệm; giải mã mang lại UTF-8 byte cho `{"alg":"HS256"}` và phân tích cú pháp JSON tạo ra một đối tượng có một thuộc tính `alg`.

Đoạn chứa dấu gạch nối hoặc dấu gạch dưới tuân theo cùng một trình tự với hai lần thay thế ký hiệu trước tiên. ToolAcre thực hiện các thao tác này bên trong `base64ToBytes`, sau đó `decodeSegment` phân tích cú pháp văn bản kết quả. Thuật toán được hiển thị là bất cứ điều gì mà tiêu đề chưa được xác minh khai báo; nó không được chọn làm chính sách xác minh.

Unicode trong xác nhận quyền sở hữu - tại sao các byte được giải mã phải được đọc dưới dạng UTF-8 để hiển thị tên chính xác

Xác nhận quyền sở hữu có thể chứa dấu, CJK ký tự hoặc biểu tượng cảm xúc. Base64 hoạt động trên byte, do đó việc coi mỗi byte được giải mã là một ký tự độc lập sẽ làm hỏng văn bản nhiều byte. Đường dẫn chính xác được mã hóa các ký hiệu thành byte, sau đó là bộ giải mã UTF-8. ToolAcre xây dựng `TextDecoder` với chế độ nghiêm trọng nên UTF-8 không hợp lệ bị lỗi nặng.

Các thử nghiệm bao gồm tải trọng chứa `Zoë 世界 🙂` và mong đợi chuỗi chính xác sau khi giải mã. Kết quả đó chứng tỏ quy trình chuyển byte thành văn bản đã bảo toàn giá trị thử nghiệm này. Nó vẫn không nói gì về việc liệu người được đặt tên theo tải trọng có tồn tại hay không, liệu nhà phát hành có chấp thuận yêu cầu hay không hoặc mã thông báo có bị thay đổi hay không.

Điều này không bao gồm những gì - phân đoạn chữ ký, giải mã thành byte thay vì văn bản và cần một khóa để có ý nghĩa gì đó

Đoạn chữ ký nằm ngoài đường dẫn JSON. ToolAcre giữ nguyên dạng mã hóa ban đầu và chỉ cố gắng đo độ dài byte đã giải mã. Chữ ký Base64 không hợp lệ tạo ra cảnh báo nhưng không ngăn cản việc kiểm tra tiêu đề và tải trọng; phân đoạn thứ ba trống tạo ra một cảnh báo khác rằng không có byte chữ ký nào hiện diện.

Không có kết quả nào là kết quả xác minh. Xác thực chữ ký có ý nghĩa cần có tài liệu khóa đáng tin cậy, thuật toán được phép được chọn độc lập với đầu vào do kẻ tấn công kiểm soát và kiểm tra ứng dụng. Số byte rất hữu ích khi chẩn đoán hình dạng, nhưng 0 hoặc 32 byte được đo không thể ủy quyền yêu cầu hoặc thiết lập tổ chức phát hành.

Bài học rút ra: sử dụng bộ giải mã đọc base64url — bộ giải mã ToolAcre JWT xử lý bảng chữ cái và phần đệm cho tiêu đề và tải trọng

Sử dụng bộ giải mã hiểu base64url khi công việc trước mắt là kiểm tra JSON. ToolAcre xử lý bảng chữ cái, bỏ qua phần đệm, UTF-8 nghiêm ngặt và JSON chỉ đối tượng cho hai phân đoạn đầu tiên. Nó cũng loại bỏ các độ dài không thể chấp nhận được và bao bọc các lỗi phân tích cú pháp trong các thông báo xác định xem tiêu đề hoặc tải trọng có bị lỗi hay không.

Dừng lại ở ranh giới đó. Giải mã rõ ràng có nghĩa là chuỗi có byte có thể phục hồi và các đối tượng JSON phù hợp. Điều đó không có nghĩa là các tuyên bố của nó là đáng tin cậy, được xác thực, được ủy quyền hoặc không được sửa đổi. Chỉ người xác minh được định cấu hình riêng mới có thể trả lời những câu hỏi đó và công cụ trình duyệt này cố tình không tiết lộ hoạt động xác minh nào.