Tại sao JWT của bạn hết hạn ngay lập tức: điểm kinh nghiệm tính bằng giây chứ không phải mili giây

Được phát hành lúc 10:00, hết hạn lúc 10:00 — mã thông báo bị từ chối trong lần sử dụng đầu tiên và đồng hồ máy chủ không phải là vấn đề

Mã thông báo bị từ chối trong yêu cầu đầu tiên sẽ gây nghi ngờ về sai lệch của máy chủ nhưng hãy kiểm tra các xác nhận quyền sở hữu thô trước khi thay đổi đồng hồ. Nếu một thành phần được tạo `exp` từ đồng hồ mili giây trong khi thành phần khác so sánh số giây Ngày số, thì các giá trị sẽ khác nhau ba bậc độ lớn. Không có sự điều chỉnh đồng bộ hóa thông thường nào giải thích được khoảng cách đó.

Sử dụng mã thông báo dùng một lần hoặc mã thông báo đã được xử lý lại vì mã thông báo mang là thông tin xác thực. Bộ giải mã JWT của ToolAcre đọc dữ liệu tải trọng nhưng cố tình không xác minh chữ ký. Chỉ sao chép xác nhận thời gian bằng số vào trình chuyển đổi dấu thời gian sau khi bảo quản thiết bị kiểm tra ban đầu và tuổi thọ dự định của nó.

RFC 7519 nói gì — NumericDate tính bằng giây kể từ 1970-01-01T00:00:00Z và tại sao đó là số chứ không phải chuỗi

Bài viết JWT được xuất bản liền kề đã nêu rõ hợp đồng quan trọng: `exp` NumericDate tính số giây từ kỷ nguyên Unix. Việc lặp lại lời giải thích tiêu chuẩn của nó sẽ không thêm giá trị gì ở đây. Câu hỏi thực tế là liệu mỗi nhà sản xuất, nhà sản xuất số sê-ri, người kiểm định và thiết bị kiểm tra có tôn trọng quy mô đó hay không.

Tìm mã ranh giới rõ ràng: đồng hồ mili giây được chia thành giây khi phát hành và so sánh giây khi xác thực. Xác nhận quyền sở hữu phải vẫn là số thay vì ngày được định dạng dùng cho số học. UTC mà con người có thể đọc được là một phép chiếu chẩn đoán chứ không phải là bản trình bày có thẩm quyền của mã thông báo.

Ghim hợp đồng này trong các thử nghiệm của nhà phát hành và người xác minh với giá trị khác 0. Kiểm tra sử dụng epoch zero không thể tiết lộ liệu một trong hai bên được chia hay nhân với một nghìn.

Bài viết JWT hiện tại thiết lập giây NumericDate; bài viết này áp dụng thực tế đó để gỡ lỗi hết hạn

Nếu người xác minh diễn giải xác nhận giây hợp lệ là mili giây thì ngày sẽ rơi vào gần 1970 và có vẻ đã hết hạn. Nếu nhà phát hành ghi giá trị mili giây hiện tại vào một trường sau đó được hiểu là giây, thì thời hạn sử dụng sẽ vượt xa thời gian dự định hoặc vượt quá phạm vi được hỗ trợ của thư viện. Triệu chứng nào xuất hiện sẽ xác định bên nào có lỗi cân.

Tránh một "bản sửa lỗi" chấp nhận cả hai hình thức dựa trên số lượng chữ số. Điều đó biến các mã thông báo không đúng định dạng thành một giao thức thay thế vĩnh viễn và có thể ẩn các hồi quy của nhà phát hành. Từ chối các giá trị vi phạm hợp đồng NumericDate của ứng dụng, tạo chính xác và thêm các giá trị cố định để phân biệt giây với mili giây.

Sai sót trong một phần nghìn giây có thể tạo ra sự từ chối ngay lập tức hoặc hết hạn từ xa một cách vô lý tùy thuộc vào bên nào sai

Giải mã tải trọng để hiển thị `exp`, `iat` và `nbf` dưới dạng giá trị thô trước khi khung chuyển đổi chúng. So sánh `exp − iat` với thời gian tồn tại của mã thông báo dự định tính bằng giây. Kiểm tra riêng `nbf`; mã thông báo có thể chưa hết hạn nhưng không thể sử dụng được. Đừng suy luận tính xác thực từ những thời điểm có vẻ hợp lý.

Bộ giải mã của ToolAcre báo cáo rằng việc xác minh chữ ký là sai, vì vậy đầu ra của nó thuộc về việc gỡ lỗi, không bao giờ được cấp phép. Tải trọng được sửa đổi có thể chứa bất kỳ thời hạn sử dụng nào mà kẻ tấn công chọn. Trình xác minh ứng dụng đáng tin cậy vẫn phải thực thi chính sách thuật toán, khóa, nhà phát hành, đối tượng và thời gian trên mã thông báo nhỏ gọn ban đầu.

Ví dụ đã hoạt động: điểm kinh nghiệm của 1700003600 — chuyển đổi nó thành UTC và giờ địa phương, kiểm tra nó với iat và xác nhận thời gian tồn tại là điều bạn dự định

Đối với `iat = 1,700,000,000` và `exp = 1,700,003,600`, phép trừ mang lại 3,600 giây hoặc một giờ. Trình chuyển đổi đọc hết hạn một cách rõ ràng dưới dạng giây và trả về `2023-11-14T23:13:20.000Z`; thời gian phát hành là `2023-11-14T22:13:20.000Z`.

Những con số đó là duy nhất cho ví dụ chẩn đoán của bài viết này. Nếu việc chọn mili giây tạo ra số đọc 1970 tháng 1 thì đó được cho là bằng chứng về thang đo sai. Xác nhận rằng thời gian hiện tại của người xác minh cũng được biểu thị bằng giây trước khi kết luận chính sách một giờ được triển khai chính xác.

Chênh lệch một giờ được tính toán trước khi định dạng, do đó, nó vẫn là một giờ ở mỗi vùng. Màn hình cục bộ có thể khác nhau nhưng `exp − iat` thì không.

Ví dụ đã hoạt động: so sánh exp 1,700,003,600 với iat gần đó bằng cách sử dụng giây rõ ràng

Trình xác minh có thể cho phép một sai số nhỏ do ứng dụng xác định xung quanh các yêu cầu về thời gian để phù hợp với sự khác biệt nhỏ về đồng hồ. Kho lưu trữ này không xác định số giây được đề xuất, do đó không có khoảng thời gian chung nào được quy định ở đây. Chính sách bảo mật và cấu hình thư viện là cơ quan có thẩm quyền.

Dung sai sẽ vẫn rất nhỏ so với hệ số một nghìn. Việc mở rộng nó cho đến khi một xác nhận quyền sở hữu không đúng định dạng được thông qua sẽ làm suy yếu khả năng thực thi hết hạn và khiến lỗi của nhà phát hành vẫn còn tồn tại. Đầu tiên bình thường hóa đơn vị đồng hồ và đồng bộ hóa; sau đó quyết định xem mức trợ cấp giới hạn có phục vụ mô hình mối đe dọa của ứng dụng hay không.

Nếu dung sai được định cấu hình, hãy kiểm tra các giá trị ngay bên trong và bên ngoài ranh giới đó tính bằng giây. Điều này chứng minh chính sách độc lập với bất kỳ hiển thị Ngày hoặc ngôn ngữ nào.

Dung sai không thể sửa chữa sự không khớp hệ số1,000

Chuyển đổi dấu thời gian không thể xác minh chữ ký của mã thông báo, thuật toán được phép, khóa, nhà phát hành hoặc đối tượng. Ngay cả xác nhận quyền sở hữu `exp` trong tương lai được định dạng hoàn hảo cũng có thể nằm trong mã thông báo giả mạo. Bộ giải mã JWT có chủ ý minh bạch về ranh giới này và phải được ghép nối với một trình xác minh đáng tin cậy.

Nó cũng không thể xác định liệu mã thông báo sản xuất bị thu giữ đã bị thu hồi hay liệu chính sách phiên có ghi đè thời hạn danh nghĩa của nó hay không. Gỡ lỗi các giá trị với đồ đạc không nhạy cảm. Nếu một sự cố thực sự yêu cầu kiểm tra thông tin xác thực, hãy sử dụng môi trường được ủy quyền và quy trình xử lý thay vì quy trình làm việc chung trong bảng tạm.

Việc giải mã chỉ nên xảy ra với các thiết bị cố định tổng hợp hoặc được xử lý lại một cách an toàn trong quá trình gỡ lỗi định kỳ. Sao chép thông tin xác thực mang trực tiếp sẽ tạo ra sự cố bảo mật không liên quan đến số học dấu thời gian.

Bài học rút ra: exp có mười chữ số, không phải mười ba — và cách bộ giải mã JWT và trình chuyển đổi dấu thời gian Unix nằm trong cùng một tab để bạn có thể kiểm tra xác nhận quyền sở hữu sau vài giây

Coi các yêu cầu thời gian JWT là giây ở mọi ranh giới và kiểm tra sự khác biệt của chúng dưới dạng thời lượng. Trình chuyển đổi dấu thời gian chuyển một xác nhận quyền sở hữu riêng lẻ thành UTC và ngữ cảnh cục bộ; bộ giải mã JWT hiển thị số thô. Họ cùng nhau giải thích về thời gian mà không đòi hỏi sự tin tưởng.

Việc sửa lỗi lâu dài thuộc về việc phát hành và xác minh mã, không phải trong sổ tay hỗ trợ chuyển đổi các đơn vị cho đến khi mã thông báo hoạt động. Giữ nguyên số giây rõ ràng, từ chối thang đo không đúng định dạng và giữ việc xác minh chữ ký dưới dạng một quyết định bắt buộc riêng biệt.

Sự tách biệt đó cũng cải thiện khả năng quan sát: nhật ký tạo có thể báo cáo chính sách thời lượng mà không làm lộ mã thông báo, trong khi các số liệu xác minh có thể phân biệt các kết quả đã hết hạn, sớm và chữ ký không hợp lệ.