Một thư viện phân tích JSON tối giản mới có tên sj.h đã khơi dậy cuộc thảo luận sôi nổi trong cộng đồng lập trình viên về sự cân bằng giữa tính đơn giản và bảo mật trong phần mềm mã nguồn mở. Thư viện này chỉ có 150 dòng mã C99 , hứa hẹn không cấp phát bộ nhớ và trạng thái tối thiểu trong khi cung cấp khả năng phân tích JSON cơ bản.
Thông số kỹ thuật thư viện:
- Kích thước: ~150 dòng code C99
- Bộ nhớ: Không cấp phát bộ nhớ với trạng thái tối thiểu
- Tính năng: Thông báo lỗi với vị trí dòng:cột
- Hạn chế: Không có phân tích cú pháp số hoặc chuỗi tích hợp sẵn
- Giấy phép: Phạm vi công cộng ( Unlicense )
Mối quan ngại về bảo mật trở thành tâm điểm
Tranh cãi chính tập trung xung quanh các lỗ hổng bảo mật tiềm ẩn trong mã của thư viện. Các nhà nghiên cứu bảo mật đã xác định được vấn đề với tràn số nguyên có dấu có thể kích hoạt hành vi không xác định khi xử lý một số đầu vào nhất định. Thư viện không kiểm tra tràn số khi tăng bộ đếm độ sâu hoặc số dòng/cột, điều này có thể bị khai thác bởi các tệp JSON độc hại chứa cấu trúc lồng nhau sâu hoặc các dòng cực dài.
Những người chỉ trích cho rằng bất kỳ thư viện phân tích JSON nào cũng nên xử lý các trường hợp biên này một cách an toàn, đặc biệt là vì JSON thường đến từ các nguồn không đáng tin cậy. Họ chỉ ra rằng trong khi thư viện có thể hoạt động tốt trong môi trường được kiểm soát, nó có thể trở thành rủi ro bảo mật nếu được áp dụng trong các hệ thống sản xuất xử lý dữ liệu bên ngoài.
Lưu ý: Hành vi không xác định đề cập đến mã không có kết quả có thể dự đoán được theo đặc tả ngôn ngữ lập trình.
Các vấn đề bảo mật đã được xác định:
- Tràn số nguyên có dấu trong bộ đếm độ sâu
- Không có kiểm tra tràn số cho số dòng/cột
- Có khả năng xảy ra hành vi không xác định với đầu vào độc hại
- Phân tích cú pháp lỏng lẻo chấp nhận JSON bị lỗi định dạng
- Độ sâu lồng ghép tối đa bị giới hạn bởi INT_MAX (thường là hơn 2 tỷ)
Triết lý của các thư viện tối thiểu
Những người ủng hộ thư viện bảo vệ cách tiếp cận của nó, nhấn mạnh rằng không phải mọi phần mềm đều cần các tính năng bảo mật cấp doanh nghiệp. Họ lập luận rằng thư viện phục vụ một thị trường ngách cụ thể - các lập trình viên cần phân tích JSON nhẹ, đơn giản cho môi trường được kiểm soát hoặc hệ thống nhúng nơi tài nguyên bị hạn chế.
Cuộc tranh luận phản ánh sự chia rẽ triết lý rộng lớn hơn trong phát triển phần mềm. Một số lập trình viên thích các thư viện toàn diện xử lý mọi trường hợp biên có thể, trong khi những người khác ủng hộ các công cụ tối thiểu làm một việc tốt và để lại sự phức tạp bổ sung cho người dùng.
So sánh với các thư viện khác:
- cJSON: Toàn diện hơn, được sử dụng rộng rãi trong sản xuất
- nlohmann/json: Thư viện C++ với 122 triệu bài kiểm tra đơn vị, 13 năm phát triển
- simdjson: Được tối ưu hóa cho hiệu suất
- json.lua: Triển khai Lua thuần túy, chậm hơn nhưng có tính di động
Tác động thực tế và mối quan ngại về việc áp dụng
Cuộc thảo luận đã làm nổi bật một vấn đề phổ biến trong phần mềm mã nguồn mở: các dự án sở thích tỏ ra hữu ích thường được áp dụng trong các hệ thống sản xuất mà không có đánh giá bảo mật thích hợp. Trong khi giấy phép miền công cộng của thư viện nêu rõ rằng nó không có bảo hành, những người chỉ trích lo ngại rằng các lập trình viên có thể sử dụng nó một cách không phù hợp trong các ứng dụng nhạy cảm về bảo mật.
Một số thành viên cộng đồng đã đề xuất các bản sửa lỗi đơn giản, bao gồm thêm giới hạn độ sâu và kiểm tra tràn số sẽ duy trì tính đơn giản của thư viện trong khi giải quyết các mối quan ngại bảo mật nghiêm trọng nhất. Một bản vá được đề xuất giới hạn độ sâu lồng nhau ở 999 cấp độ cho thấy cách các thay đổi tối thiểu có thể cải thiện đáng kể tính an toàn mà không làm tổn hại đến triết lý cốt lõi của thư viện.
Thư viện sj.h đại diện cho một nghiên cứu trường hợp thú vị trong căng thẳng đang diễn ra giữa tính đơn giản và tính mạnh mẽ trong phát triển phần mềm. Mặc dù nó có thể không phù hợp cho tất cả các trường hợp sử dụng, nó phục vụ như một lời nhắc nhở rằng các dự án khác nhau có yêu cầu khác nhau, và đôi khi giải pháp đơn giản nhất chính xác là những gì cần thiết.
Tham khảo: sj.h