Giải thích Base64, mã hóa URL và JWT

Mã hóa (encoding) không phải là mật mã hóa

Encoding thay đổi cách viết dữ liệu để nó đi qua được một kênh chỉ chấp nhận một số ký tự nhất định. Ai cũng có thể đảo ngược, vì không có khóa nào. Mật mã hóa (encryption) cũng biến đổi dữ liệu, nhưng chỉ người có khóa mới khôi phục được. Hàm băm lại là thứ khác: một dấu vân tay một chiều không thể đảo ngược, như giải thích trong Giải thích về hàm băm.

Base64 và mã hóa URL là encoding. JWT thường được ký, chứng minh ai đã phát hành và nội dung không bị sửa, nhưng bản thân nội dung chỉ được encode. Nếu một giá trị cần giữ bí mật, nó cần mật mã hóa chứ không phải một trong các định dạng này.

Base64 hoạt động thế nào

Base64 đọc dữ liệu theo từng nhóm ba byte (24 bit) và chia thành bốn nhóm sáu bit. Mỗi nhóm là một số từ 0 đến 63, được viết thành một ký tự trong bảng chữ cái 64 ký tự: A–Z cho 0–25, a–z cho 26–51, 0–9 cho 52–61, rồi đến + và /. Từ “Man” cho thấy các bước:

Khi độ dài đầu vào không chia hết cho ba, nhóm cuối được bù thêm và đánh dấu bằng ký tự đệm: dư một byte cho hai ký tự và ==, dư hai byte cho ba ký tự và =. “Ma” thành TWE= và “M” thành TQ==.

Vì cứ ba byte thành bốn ký tự, Base64 làm dữ liệu lớn thêm khoảng một phần ba, cộng thêm dấu xuống dòng mà một số định dạng chèn vào. Một bức ảnh 3 MB gửi làm tệp đính kèm email sẽ truyền đi dưới dạng khoảng 4 MB văn bản, và một ảnh nhúng vào stylesheet dưới dạng data URL nặng hơn tệp gốc khoảng một phần ba.

Bạn gặp Base64 ở đâu

• Tệp đính kèm email (MIME) là văn bản Base64, ngắt dòng ở 76 ký tự.
• Data URL như data:image/png;base64,iVBORw0… đưa một tệp nhỏ thẳng vào HTML hoặc CSS.
• Xác thực HTTP Basic gửi user:password dưới dạng Base64 trong header Authorization. Việc này chỉ che mật khẩu khỏi ánh nhìn lướt qua, nên chỉ an toàn khi dùng HTTPS.
• Chứng chỉ và khóa trong tệp PEM là Base64 nằm giữa các dòng -----BEGIN …----- và -----END …-----, ngắt ở 64 ký tự.
• JSON và XML mang các giá trị nhị phân, như chữ ký hay ảnh thu nhỏ, dưới dạng chuỗi Base64 vì chúng không có kiểu nhị phân.

Base64URL và ký tự đệm

Dấu + và / của Base64 chuẩn có ý nghĩa trong URL và đường dẫn tệp, nên bảng chữ cái thứ hai là Base64URL dùng - và _ thay thế. Nó cũng thường bỏ ký tự đệm =, vì bộ giải mã có thể tự tính độ dài. JWT, nhiều token API và một số tên tệp dùng Base64URL. Để đổi Base64 chuẩn thành Base64URL, thay + bằng -, / bằng _ và bỏ các dấu = ở cuối; để đổi ngược, hoàn tác các thay thế và thêm = cho đến khi độ dài chia hết cho bốn.

Mã hóa phần trăm trong URL

URL chỉ được chứa một tập ký tự giới hạn, và một số ký tự tạo nên cấu trúc địa chỉ: / và ? tách đường dẫn và truy vấn, & và = tách các tham số, # bắt đầu phân đoạn. Khi một giá trị chứa các ký tự này, hoặc bất cứ thứ gì ngoài ASCII, nó được mã hóa phần trăm: mỗi byte trong dạng UTF-8 của nó được viết thành % kèm hai chữ số thập lục phân. “café” thành caf%C3%A9, vì é là hai byte C3 A9.

Chữ cái, chữ số và - . _ ~ không bao giờ cần mã hóa. Đây là những ký tự hay gây rắc rối nhất:

Hãy mã hóa từng giá trị riêng rồi mới ghép URL. Trong JavaScript, encodeURIComponent làm việc này cho một giá trị và mã hóa cả / ? & = #, còn encodeURI dành cho cả địa chỉ nên giữ nguyên các ký tự đó. Dùng encodeURI cho một giá trị đơn lẻ là nguyên nhân phổ biến khiến chuỗi truy vấn bị hỏng.

Dấu cộng, dấu cách và mã hóa hai lần

Biểu mẫu HTML gửi các trường dưới dạng application/x-www-form-urlencoded, trong đó dấu cách thành +. Trong cú pháp URL chung, + chỉ là dấu cộng. Vì vậy, một tìm kiếm “C++” gửi dưới dạng q=C++ sẽ đến máy chủ giải mã dữ liệu biểu mẫu thành “C” kèm hai dấu cách; đúng ra phải gửi là q=C%2B%2B. Khi tự giải mã một chuỗi truy vấn, hãy tìm hiểu xem nó được tạo theo quy tắc nào trước.

Mã hóa hai lần xảy ra khi một giá trị đã được mã hóa lại bị mã hóa lần nữa: %20 thành %2520, vì chính dấu % thành %25. Nếu thấy %25 theo sau là hai chữ số thập lục phân trong URL, thì đâu đó trong chuỗi xử lý đã mã hóa hai lần; hãy giải mã một lần và tìm bước thừa nằm ở đâu.

Bên trong JWT có gì

JSON Web Token (JWT) mang các khẳng định (claim), như người dùng là ai và token có hiệu lực đến khi nào, từ hệ thống phát hành đến các hệ thống chấp nhận nó. Dạng có chữ ký phổ biến gồm ba phần Base64URL ngăn cách bằng dấu chấm: header, payload và chữ ký. Sau khi giải mã, hai phần đầu là JSON bình thường:

Header:  {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "user-42", "role": "editor", "iat": 1767225600, "exp": 1767229200}

Tiêu chuẩn (RFC 7519) định nghĩa một số claim đăng ký sẵn; ứng dụng tự thêm claim riêng, như role ở trên.

Vì payload chỉ được encode, ai có token cũng đọc được nó. Đừng đưa dữ liệu cá nhân hay bí mật vào, và giữ token gọn nhẹ: token đi kèm mọi yêu cầu, và nhiều máy chủ giới hạn kích thước header.

Có chữ ký không có nghĩa là bí mật: cách kiểm tra JWT

Chữ ký được tính trên header và payload. Với HS256, bên phát hành và bên nhận dùng chung một khóa bí mật và dùng HMAC với SHA-256. Với RS256 hoặc ES256, bên phát hành ký bằng khóa riêng và bên nhận kiểm tra bằng khóa công khai tương ứng, nên họ không thể tự tạo token.

Máy chủ nhận token phải xác minh chữ ký bằng thuật toán và khóa mong đợi, và kiểm tra exp, nbf, iss, aud, trước khi tin bất kỳ claim nào. Chỉ giải mã, như công cụ LeedyBox làm, bỏ qua tất cả các bước đó: nó cho thấy token ghi gì, chứ không cho biết token có thật hay không. Thư viện cũng phải từ chối thuật toán “none”, đánh dấu token không ký, trừ khi đã dự kiến dùng token không ký. Khi chính nội dung cần được giấu, token được mật mã hóa (JWE); khi đó nó có năm phần và không thể đọc nếu không có khóa.

Sự cố thường gặp và cách khắc phục

Câu hỏi thường gặp