Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• JWT không được mã hóa, chỉ được mã hóa định dạng (encoded), do đó bất kỳ ai cũng có thể đọc nội dung payload.
• Ba lỗ hổng giả mạo phổ biến bao gồm: tấn công 'alg: none', đoán khóa bí mật offline và tấn công chuyển đổi thuật toán (RS256 sang HS256).
• Quy tắc vàng: Không bao giờ tin tưởng thuật toán được khai báo trong header của token; luôn sử dụng danh sách cho phép (allowlist) phía server.

JSON Web Tokens (JWT) hiện là tiêu chuẩn mặc định cho việc truyền tải thông tin xác thực trên web. Chúng xuất hiện trong mọi Authorization header, trong cookie và trong các lời gọi API giữa các dịch vụ. Tuy nhiên, sự im lặng của chúng khi vận hành chính là cái bẫy chết người. Một JWT được ký bằng khóa bí mật thực sự trông không khác gì một token được ký bằng một chuỗi ngẫu nhiên đơn giản, cho đến khi kẻ tấn công bắt đầu chạy các từ điển mật khẩu và chiếm quyền quản trị hệ thống của bạn.

Hiểu về cấu trúc JWT và rủi ro tiềm ẩn

Một JWT bao gồm ba phần được phân tách bằng dấu chấm: Header, Payload và Signature. Header xác định thuật toán ký, Payload chứa các thông tin (claims), và Signature được tính toán dựa trên cả hai phần trước. Một sự thật quan trọng mà nhiều kỹ sư thường bỏ quên là Payload chỉ được mã hóa base64url, không phải mã hóa bảo mật (encrypted). Bất kỳ ai sở hữu token đều có thể đọc toàn bộ thông tin bên trong.

Kịch bản 1: Tấn công bằng thuật toán none

Đây là cách tấn công đơn giản nhất. Trong các phiên bản cũ, giá trị none trong header cho phép token không cần chữ ký. Kẻ tấn công chỉ cần thay đổi header thành {"alg":"none"}, sửa payload thành "role":"admin", xóa bỏ signature và gửi đi. Nếu server không kiểm tra chặt chẽ, nó sẽ chấp nhận token này như một thực thể hợp lệ.

Kịch bản 2: Tấn công đoán khóa bí mật (Offline Brute-force)

Đối với các thuật toán như HS256, HS384, HS512, bảo mật phụ thuộc hoàn toàn vào độ phức tạp của khóa bí mật (secret). Vì kẻ tấn công đã có token trong tay, chúng có thể thực hiện tấn công offline mà không lo bị chặn bởi cơ chế rate-limiting hay lockout của hệ thống.

Kịch bản 3: Tấn công chuyển đổi thuật toán (Algorithm Confusion)

Đây là lỗ hổng tinh vi nhất. Kẻ tấn công thay đổi header từ RS256 (sử dụng khóa công khai/riêng tư) sang HS256 (sử dụng khóa bí mật chung). Nếu server không kiểm tra thuật toán, nó sẽ sử dụng khóa công khai (public key) làm khóa bí mật để xác thực token. Vì public key là công khai, kẻ tấn công dễ dàng tạo ra một token giả mạo hợp lệ.

Quy tắc vàng: Không tin tưởng dữ liệu trong token

Nguyên nhân gốc rễ của mọi cuộc tấn công trên là việc server tin tưởng vào thuật toán được khai báo ngay trong header của token. Để ngăn chặn, bạn phải áp dụng quy tắc: Không bao giờ để token tự chọn thuật toán của nó.

Mẹo hay: Hãy luôn định nghĩa một danh sách thuật toán cho phép (allowlist) cứng trong mã nguồn phía server. Ví dụ trong Python với thư viện PyJWT:
`claims = jwt.decode(token, public_key, algorithms=["RS256"])

Chỉ chấp nhận RS256, loại bỏ hoàn toàn none hoặc các thuật toán khác.`

Việc thực hiện kiểm soát chặt chẽ này giúp bảo mật hệ thống tốt hơn, tương tự như cách chúng ta tối ưu hóa các thành phần hệ thống khác như giải mã cơ chế ROWID trong Oracle Database để đảm bảo tính toàn vẹn dữ liệu. Ngoài ra, hãy đảm bảo rằng bạn không bao giờ lưu trữ thông tin nhạy cảm trong payload, vì như đã đề cập, nó chỉ là dữ liệu được mã hóa định dạng. Nếu bạn đang xây dựng các hệ thống phức tạp, việc hiểu rõ nợ kỹ thuật từ người khác cũng là một phần quan trọng của quản trị bảo mật.

Đánh giá & Lời khuyên Thực tiễn

Từ góc nhìn của một Senior Tech Lead, JWT là một công cụ mạnh mẽ nhưng đòi hỏi sự kỷ luật cao trong triển khai.

• Ưu điểm: Hiệu năng cao, stateless, dễ dàng scale cho các kiến trúc microservices.
• Nhược điểm: Khó thu hồi (revoke) token, dễ bị giả mạo nếu cấu hình sai.
• Phạm vi ứng dụng: Phù hợp cho các hệ thống cần xác thực nhanh giữa các service hoặc client-server không duy trì session dài hạn.

Lưu ý: Khi triển khai trên Production, hãy đảm bảo khóa bí mật được quản lý qua các dịch vụ như AWS KMS hoặc HashiCorp Vault. Đừng bao giờ hardcode khóa vào mã nguồn. Nếu bạn quan tâm đến việc tối ưu hóa hiệu năng xác thực, hãy tham khảo thêm về JWT vs Session Tokens để có cái nhìn toàn diện hơn.

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

Tại sao tôi không nên dùng thuật toán none?

Thuật toán none vô hiệu hóa hoàn toàn cơ chế kiểm tra chữ ký, cho phép bất kỳ ai cũng có thể tạo token với quyền quản trị mà không cần khóa bí mật.

Làm thế nào để kiểm tra token của tôi có bị lỗ hổng không?

Bạn có thể sử dụng các công cụ như jwt-auditor để kiểm tra xem token của mình có chấp nhận thuật toán none hoặc bị tấn công chuyển đổi thuật toán hay không.

Tôi có nên lưu trữ thông tin người dùng trong JWT không?

Chỉ nên lưu trữ các thông tin định danh cơ bản. Tuyệt đối không lưu mật khẩu hoặc thông tin nhạy cảm vì JWT có thể bị giải mã bởi bất kỳ ai.

Kết luận

Bảo mật JWT không phải là một nhiệm vụ phức tạp nếu bạn nắm vững các nguyên tắc cơ bản. Bằng cách áp dụng danh sách cho phép thuật toán và quản lý khóa bí mật chặt chẽ, bạn đã loại bỏ được hầu hết các rủi ro giả mạo phổ biến. Hãy bắt đầu kiểm tra lại hệ thống của bạn ngay hôm nay. Nếu bạn thấy bài viết này hữu ích, đừng quên theo dõi hi_dev để cập nhật những kiến thức kỹ thuật chuyên sâu mới nhất.