MongoDB tránh khả năng xảy ra sự cố bằng cách không phân tích cú pháp.
Bất kỳ API nào, ở bất kỳ đâu, liên quan đến việc mã hóa dữ liệu người dùng dưới dạng văn bản định dạng được phân tích cú pháp đều có khả năng khiến người gọi và người gọi không đồng ý về cách phân tích văn bản đó. Những bất đồng này có thể là vấn đề bảo mật khi dữ liệu bị hiểu sai thành siêu dữ liệu. Điều này đúng cho dù bạn đang nói về chuỗi định dạng printf, bao gồm nội dung do người dùng tạo trong HTML hay tạo SQL.
Vì MongoDB không phân tích cú pháp văn bản có cấu trúc để tìm ra những việc cần làm, nên không có khả năng hiểu sai thông tin đầu vào của người dùng dưới dạng hướng dẫn và do đó không có lỗ hổng bảo mật nào có thể xảy ra.
Tình cờ, lời khuyên tránh các API yêu cầu phân tích cú pháp là mục 5 trong http://cr.yp.to/qmail/guarantee.html. Nếu bạn quan tâm đến việc viết phần mềm an toàn, thì 6 gợi ý khác cũng đáng xem.
Cập nhật (2018):Câu trả lời ban đầu như tôi đã đưa ra vẫn đúng theo hiểu biết của tôi. Từ thời điểm những gì được gửi đến MongoDB đến những gì được gửi lại, không có cuộc tấn công SQL injection nào. Các cuộc tấn công tiêm mà tôi biết xảy ra bên ngoài MongoDB và thực sự là các vấn đề trong cách các ngôn ngữ và thư viện bên ngoài thiết lập cấu trúc dữ liệu sẽ được chuyển tới MongoDB. Hơn nữa, vị trí của lỗ hổng là cách dữ liệu được phân tích cú pháp trên đường trở thành cấu trúc dữ liệu. Do đó, câu trả lời ban đầu mô tả chính xác cả cách tránh các cuộc tấn công tiêm chích và điều gì khiến bạn gặp rủi ro về chúng.
Nhưng độ chính xác này là sự thoải mái lạnh lùng đối với một lập trình viên bị tấn công bởi các cuộc tấn công tiêm nhiễm từ các lỗi không rõ ràng trong mã của chính họ. Rất ít người trong chúng ta phân biệt giữa công cụ bên ngoài và tất cả các lớp giữa mã của chúng tôi và công cụ bên ngoài đó. Và thực tế vẫn là nó đòi hỏi sự cảnh giác từ phía chúng ta để dự đoán và ngăn chặn các cuộc tấn công tiêm chích. Với tất cả các công cụ. Và điều này sẽ vẫn xảy ra trong tương lai gần.
