Bài viết gốc đăng tải ngày 5 tháng 3 năm 2019
Nếu bạn là nhà phát triển ứng dụng, quản trị cơ sở dữ liệu (DBA), hoặc bất kỳ chuyên gia công nghệ nào, việc tiêm mã (code injection) nên nằm trong tầm ngắm của bạn.
Bạn có một môi trường đám mây an toàn. Bạn đã khóa chặt quyền truy cập cơ sở dữ liệu. Nhưng đâu là mã ứng dụng của bạn? Mặc dù được coi là an toàn hơn, chữ No trong NoSQLi không có nghĩa là nó không thể bị tiêm mã! NoSQL có thể dễ bị tấn công tiêm mã như bất kỳ mã cơ sở dữ liệu nào khác. Không phòng chống lại tiêm mã giống như có hệ thống bảo mật cho cửa trước nhưng để cửa sổ sau mở lớn.
Tiêm mã là gì?
Tiêm mã đơn giản là dữ liệu không được xác thực bị tiêm (hoặc thêm) vào một chương trình dễ bị tổn thương nơi nó thực thi dưới dạng mã ứng dụng, thường dẫn đến kết quả thảm khốc.
SQLi là một trong những loại tiêm phổ biến nhất và, sau hơn một thập kỷ, vẫn còn tràn lan. Vấn đề tiêm không chỉ dành cho ngôn ngữ cơ sở dữ liệu. Ngoài SQL và NoSQL, tiêm có thể xảy ra trong XPath®, XML Parsers, tiêu đề SMTP và các ngữ cảnh khác. Về mức độ nghiêm trọng, tiêm mã tương đương với thực thi mã từ xa (RCE) — màn hình Game Over của kiểm thử xâm nhập.
Việc phát hiện và ngăn chặn NoSQLi trong ứng dụng của bạn là vô cùng quan trọng. Việc cho phép một vector tiêm không được giảm thiệu có thể đe dọa an toàn của người dùng, đại diện cho một mất mát niềm tin có thể chấm dứt doanh nghiệp. May mắn thay, sau khi hiểu cơ chế, bạn có thể thực hiện các bước cụ thể để phát hiện và ngăn chặn các lỗ hổng NoSQLi trong dịch vụ của mình.
Ví dụ NoSQLi đơn giản
Thông thường, MongoDB® ingest dữ liệu Binary JSON (BSON) được xây dựng bằng công cụ xây dựng truy vấn BSON an toàn. Nhưng trong một số trường hợp, MongoDB cũng có thể chấp nhận JSON chưa được tuần tự hóa và biểu thức Javascript (JS), chẳng hạn như toán tử $where. Giống như SQL, toán tử $where dễ bị tiêm tiềm ẩn trong NoSQL. Tuy nhiên, khác với SQL, $where NoSQL biểu diễn điều kiện của nó bằng JS. Điều này có nghĩa là nó có thể sử dụng toàn bộ sức mạnh biểu đạt của JS để tạo ra các truy vấn tiêm tiềm ẩn thay vì bị giới hạn bởi những gì SQL cung cấp.
Đi qua danh sách các chuỗi tiêm MongoDB trong các kho công khai như ví dụ này minh họa một số chiến lược tiêm phổ biến, song song với các lỗ hổng tương tự trong SQL và các ngôn ngữ khác. Ví dụ, một số sử dụng biểu thức kinh điển 1 == 1 để buộc truy vấn trả về giá trị true nhằm cố gắng đọc các tài nguyên và đặc quyền ẩn (hoặc cấp quản trị):
$Where: '1 == 1' Các đoạn mã khác mô phỏng chiến lược tiêm mù bằng cách sử dụng hàm sleep() để làm chậm DB và tạo hiệu ứng phụ — kết hợp với các bộ lọc thiết kế khéo léo — có thể liệt kê thông tin nhạy cảm:
';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000); Và đương nhiên là việc trích xuất dữ liệu đơn giản, nơi truy vấn tiêm cố gắng khớp và truy xuất thông tin quan trọng trực tiếp.
' && this.password.match(/.*/)//+%00 Sau ví dụ đầu tiên, hai ví dụ còn lại không sử dụng toán tử $where. Bạn không cần một biểu thức có phong cách JS làm điểm tựa để tấn công DB NoSQL.
Ngăn chặn NoSQLi
Có một số chiến lược chung để theo đuổi khi cố gắng xây dựng kiến trúc ứng dụng chống NoSQLi. Không ngạc nhiên rằng chúng tuân theo các lời khuyên chống tiêm chung.
MongoDB / NoSQLi không phải ngoại lệ
Một số người xem tiêm mã là vấn đề đặc thù của SQL và đánh giá thấp tính hợp lệ của các nguyên tắc tiêm áp dụng cho các ngữ cảnh khác. Hy vọng bài viết này thuyết phục bạn rằng NoSQLi là thực tế. Điều này được ghi chép kỹ trong các bài viết tương tự như "MongoDB sẽ không ngăn chặn tiêm NoSQL trong ứng dụng Node.js của bạn".
Không tin tưởng dữ liệu người dùng chưa được xác thực
Vì lý do bảo mật, bạn không nên tin tưởng người dùng!
Điều này có thể nghe起来 như một câu nói sáo rỗng trong bảo mật, nhưng hãy kỳ vọng mọi đầu vào đều được dò tìm với ý định độc ác. Ví dụ $where trước đây minh họa rõ ràng tại sao chúng ta không thể làm điều gì đó như $where: unvalidated_input — chúng ta có thể nghĩ rằng chúng ta đang đưa bộ lọc cho người dùng tại thời điểm này (đã đủ tệ!). Thực tế là người dùng đưa dữ liệu chưa được xác thực vào truy vấn lớn hơn là điều xa xôi so với thực hành tốt nhất.
Cẩn trọng với đặc thù ngôn ngữ hoặc tích hợp
Mặc dù NoSQLi không đặc biệt khi nói đến khả năng miễn dịch tiêm (và bị nhiều loại tấn công tương tự), điều đó không có nghĩa là không có chiến lược đặc thù cho NoSQLi — hoặc thậm chí cho các ngôn ngữ hoặc thành phần được xây dựng trên DB NoSQL. Ví dụ nổi bật là vì $where được định dạng theo cách truyền như biến PHP, một DB NoSQL được xây dựng trên ứng dụng PHP phải tính đến điều này và kịch bản có thể xảy ra của việc tiêm chuỗi độc hại được lưu trữ trong $where.
Kết luận
Lại một lần nữa, chữ No trong NoSQLi không có nghĩa là không thể tiêm! NoSQL, tương tự như SQL, tiêu đề SMTP, XML và các ngữ cảnh khác, dễ bị tiêm mã và những cạm bẫy chung là coi những thứ không phải mã ứng dụng như thể chúng là mã ứng dụng mà làm rối ren nhiều công nghệ khác.
Hy vọng bài viết này đã cung cấp cho bạn sự hiểu biết sâu hơn về NoSQLi và ý nghĩa của nó đối với doanh nghiệp của bạn. Bây giờ, bạn có thể điều hướng mã của mình về các quy trình làm cho nó ít phổ biến hơn, ít lan rộng hơn và ít ảnh hưởng hơn. Nếu bạn cần một số lời khuyên quản trị MongoDB để đảm bảo ứng dụng và môi trường lưu trữ của bạn an toàn, Rackspace ObjectRocket có DBA giàu kinh nghiệm có thể giúp đỡ.
Tìm hiểu thêm về Dịch Vụ DBA của Rackspace.
Sử dụng tab Phản Hồi để đưa ra bình luận hoặc đặt câu hỏi. Bạn cũng có thể nhấp vào Sales Chat để trò chuyện ngay và bắt đầu cuộc hội thoại.