Verify một JWT cho đúng

Câu hỏi mà một lần verify JWT phải trả lời không phải "token này có bị sửa không" mà là "token này có phải do người tôi tin phát ra, cho hệ thống của tôi, cho hành động này, và còn hiệu lực không". Chữ ký chỉ trả lời câu đầu.

Năm thứ phải kiểm, và bốn thứ sau là bốn thứ hay bị bỏ:

Hai lỗ hổng kinh điển, và cả hai đến từ việc tin header của token:

(1) alg: none. JWT cho phép alg: none, nghĩa là không chữ ký. Một thư viện verify "theo alg trong header" sẽ thấy none, kết luận không cần kiểm gì, và trả về thành công. Bản vá: luôn nói ra thuật toán bạn mong đợi, đừng để token tự khai.

(2) Lẫn thuật toán (alg confusion). Nếu server chấp nhận cả RS256 và HS256, kẻ tấn công lấy public key của bạn — thứ công khai — rồi ký một token bằng HS256 với public key đó làm secret. Server thấy alg: HS256, dùng khoá RSA làm secret HMAC, và chữ ký khớp.

Một điều đáng nói vì nó ngược trực giác: kid trong header cũng không đáng tin. Nó chỉ ra khoá nào trong JWKS, và một kid trỏ tới đường dẫn file hoặc một URL do kẻ tấn công đặt từng là một lớp lỗ hổng thật. kid được dùng để tra trong một tập khoá bạn đã biết, không để nạp một khoá mới.

Và một điều về JWT nói chung: không có cách nào thu hồi. Một token đã phát ra thì hợp lệ tới khi exp tới, dù bạn đã đổi mật khẩu, xoá tài khoản, hay gỡ quyền. Đó không phải một lỗi để vá mà là một tính chất phải thiết kế quanh — bài session-lifetime làm việc đó.