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