Lỗ hổng bảo mật JWT gây tranh cãi về việc triển khai Row-Level Security trong PostgreSQL

Nhóm Cộng đồng BigGo
Lỗ hổng bảo mật JWT gây tranh cãi về việc triển khai Row-Level Security trong PostgreSQL

Một extension thử nghiệm mới của PostgreSQL sử dụng JSON Web Tokens ( JWT ) cho row-level security đã châm ngòi cho cuộc tranh luận sôi nổi về các lỗ hổng bảo mật JWT và các phương pháp thay thế. Extension jwt_context , được phát triển bởi Tomas Vondra , nhằm giải quyết các vấn đề về connection pooling với row-level security truyền thống dựa trên role, nhưng các chuyên gia bảo mật đang đưa ra cảnh báo về phương pháp này.

Row-level security ( RLS ) trong PostgreSQL truyền thống dựa vào các database role để thiết lập trusted context. Tuy nhiên, phương pháp này tạo ra thách thức với connection pooling và yêu cầu các quản trị viên cơ sở dữ liệu phải quản lý role cho từng người dùng ứng dụng. Extension mới này cố gắng giải quyết những vấn đề này bằng cách sử dụng JWT token được ký mật mã để thiết lập trust mà không cần dựa vào các role dựa trên xác thực.

Mối quan ngại về bảo mật trở thành tâm điểm

Mối quan ngại lớn nhất được cộng đồng đưa ra tập trung vào các lỗ hổng JWT đã được ghi chép đầy đủ. Các nhà nghiên cứu bảo mật đã xác định những lỗ hổng nghiêm trọng trong việc triển khai JWT , đặc biệt là xung quanh các cuộc tấn công algorithm confusion nơi mà các tác nhân độc hại có thể chuyển đổi giữa các phương pháp mật mã đối xứng và bất đối xứng để bỏ qua các kiểm soát bảo mật.

Ồ nhìn kìa, thiết lập điển hình cho một lỗ hổng JWT cổ điển... Bạn thực sự nên cân nhắc không sử dụng JWT cho các thiết kế mới mà không cần thiết phải tương tác với JWT từ trước.

Cấu trúc code của extension jwt_context dường như tuân theo các pattern đã từng dẫn đến vi phạm bảo mật trong các triển khai JWT khác. Những lỗ hổng này đã ảnh hưởng đến các nền tảng lớn bao gồm Firebase và nhiều npm package khác nhau, chứng minh rằng ngay cả các tổ chức được thiết lập tốt cũng có thể trở thành nạn nhân của các vấn đề bảo mật liên quan đến JWT .

So sánh bảo mật JWT vs PASETO

  • Vấn đề của JWT: Các cuộc tấn công nhầm lẫn thuật toán, lỗ hổng chuyển đổi khóa đối xứng/bất đối xứng, các vi phạm bảo mật trong lịch sử tại Firebase và các gói npm
  • Ưu điểm của PASETO: Được thiết kế để tránh các cạm bẫy mật mã học, bảo mật hơn theo mặc định, loại bỏ các cuộc tấn công nhầm lẫn thuật toán
  • Tác động hiệu suất: Việc triển khai bảo mật cấp độ hàng có thể tiêu tốn tới 30% hiệu suất máy chủ cơ sở dữ liệu

Các phương pháp thay thế nhận được sự chú ý

Cuộc thảo luận đã làm nổi bật PASETO ( Platform-Agnostic Security Tokens ) như một giải pháp thay thế an toàn hơn cho JWT . Không giống như JWT , PASETO được thiết kế từ đầu để tránh các cạm bẫy mật mã gây khó khăn cho việc triển khai JWT . Một số thành viên cộng đồng bày tỏ sự ngạc nhiên khi tìm hiểu về những giải pháp thay thế này, cho thấy khoảng cách kiến thức trong cộng đồng developer về các vấn đề bảo mật JWT .

Thú vị là, một số tổ chức đã triển khai thành công các giải pháp tương tự. Neon , một dịch vụ PostgreSQL cloud, đã phát triển hệ thống RLS dựa trên JWT của riêng họ với các biện pháp bảo mật bổ sung. Phương pháp của họ bao gồm sử dụng random JSON Web Keys cho mỗi kết nối, monotonic token ID để ngăn chặn token smuggling, và quản lý connection pool nghiêm ngặt để ngăn chặn việc tái sử dụng context.

Thách thức triển khai trong thực tế

Ngoài các mối quan ngại về bảo mật, cuộc thảo luận cộng đồng đã tiết lộ những thách thức thực tế với việc triển khai RLS dựa trên JWT . Performance overhead vẫn là một vấn đề đáng kể, với một developer báo cáo rằng row-level security tiêu thụ khoảng 30% hiệu suất máy chủ cơ sở dữ liệu trong việc triển khai của họ từ hai thập kỷ trước.

Khả năng tương thích connection pooling, mặc dù được cải thiện bởi phương pháp JWT , vẫn yêu cầu quản lý cẩn thận. Extension lưu trữ context trong các biến session-level phải được xóa và khôi phục đúng cách khi các kết nối được tái sử dụng. Điều này thêm độ phức tạp cho việc triển khai connection pool và yêu cầu sửa đổi cơ sở hạ tầng cơ sở dữ liệu hiện có.

Extension hiện tại chỉ hỗ trợ các tính năng JWT cơ bản, thiếu các biện pháp bảo mật quan trọng như token expiration và khả năng key rotation. Những hạn chế này khiến nó không phù hợp cho môi trường production mà không có phát triển bổ sung đáng kể.

Hạn chế của Extension jwt_context

  • Các Thuật toán Được Hỗ trợ: Chỉ có HS256 (HMAC) và ES256 (ECDSA)
  • Các Tính năng Còn thiếu: Kiểm tra hết hạn token, quản lý xoay vòng khóa, mã hóa payload của token
  • Yêu cầu Bảo mật: Cấp độ đặc quyền SUSET cho cấu hình khóa, quyền truy cập superuser có thể làm tổn hại bảo mật
  • Connection Pooling: Yêu cầu quản lý ngữ cảnh phiên và dọn dẹp phù hợp giữa các lần tái sử dụng kết nối

Việc áp dụng trong ngành và triển vọng tương lai

Bất chấp các mối quan ngại về bảo mật, các hệ thống xác thực và ủy quyền dựa trên JWT vẫn được áp dụng rộng rãi trong ngành. Nhiều tổ chức tiếp tục sử dụng JWT token vì sự tiện lợi và khả năng tương tác của chúng, thường không nhận thức được các rủi ro bảo mật cơ bản. Cuộc tranh luận làm nổi bật một thách thức rộng lớn hơn trong ngành công nghệ: cân bằng giữa sự tiện lợi và chuẩn hóa với các thực hành bảo mật tốt nhất.

Cuộc thảo luận cũng tiết lộ rằng các phương pháp tương tự đã được triển khai thành công bởi nhiều tổ chức khác nhau trong những năm qua, cho thấy rằng bản thân khái niệm này có giá trị khi được thực hiện đúng cách. Tuy nhiên, việc lựa chọn JWT làm công nghệ cơ bản vẫn gây tranh cãi trong số các chuyên gia bảo mật.

Khi extension vẫn ở trạng thái thử nghiệm, phản hồi của cộng đồng có thể ảnh hưởng đến hướng phát triển tương lai của nó. Liệu các developer sẽ giải quyết các mối quan ngại về bảo mật bằng cách chuyển sang các định dạng token thay thế hay triển khai các biện pháp bảo vệ bổ sung vẫn còn phải chờ xem.

Tham khảo: Using JWT to establish a trusted context for RLS