Rate this post

Cơ sở dữ liệu NoSQL cung cấp các hạn chế về tính nhất quán lỏng lẻo hơn so với cơ sở dữ liệu SQL truyền thống. Bằng cách yêu cầu ít ràng buộc quan hệ hơn và kiểm tra tính nhất quán, cơ sở dữ liệu NoSQL thường mang lại hiệu suất và lợi ích mở rộng. Tuy nhiên, các cơ sở dữ liệu này vẫn có khả năng dễ bị tấn công chèn ép, ngay cả khi chúng không sử dụng cú pháp SQL truyền thống. Bởi vì các cuộc tấn công tiêm NoSQL này có thể thực thi trong một ngôn ngữ thủ tục, thay vì trong ngôn ngữ SQL khai báo, các tác động tiềm ẩn lớn hơn so với tiêm SQL truyền thống.

Các bài viết liên quan:

Các lệnh gọi cơ sở dữ liệu NoSQL được viết bằng ngôn ngữ lập trình của ứng dụng, lệnh gọi API tùy chỉnh hoặc được định dạng theo quy ước chung (chẳng hạn như XML, JSON, LINQ, v.v.). Đầu vào độc hại nhắm mục tiêu các thông số kỹ thuật đó có thể không kích hoạt các kiểm tra làm sạch ứng dụng chủ yếu. Ví dụ: lọc ra các ký tự đặc biệt phổ biến trong HTML như <> &; sẽ không ngăn chặn các cuộc tấn công chống lại API JSON, trong đó các ký tự đặc biệt bao gồm / {}:.

Hiện có hơn 150 cơ sở dữ liệu NoSQL có sẵn để sử dụng trong một ứng dụng, cung cấp các API bằng nhiều ngôn ngữ và mô hình quan hệ. Mỗi loại cung cấp các tính năng và hạn chế khác nhau. Vì không có ngôn ngữ chung giữa chúng, mã chèn ví dụ sẽ không áp dụng trên tất cả các cơ sở dữ liệu NoSQL. Vì lý do này, bất kỳ ai kiểm tra các cuộc tấn công tiêm NoSQL sẽ cần phải tự làm quen với cú pháp, mô hình dữ liệu và ngôn ngữ lập trình cơ bản để tạo ra các bài kiểm tra cụ thể.

Các cuộc tấn công tiêm NoSQL có thể thực thi trong các khu vực khác nhau của ứng dụng so với việc tiêm SQL truyền thống. Khi SQL injection sẽ thực thi trong cơ sở dữ liệu, các biến thể NoSQL có thể thực thi trong lớp ứng dụng hoặc lớp cơ sở dữ liệu, tùy thuộc vào API NoSQL được sử dụng và mô hình dữ liệu. Thông thường, các cuộc tấn công tiêm NoSQL sẽ thực thi khi chuỗi tấn công được phân tích cú pháp, đánh giá hoặc nối thành một lệnh gọi API NoSQL.

Các cuộc tấn công định thời bổ sung có thể liên quan đến việc thiếu kiểm tra đồng thời trong cơ sở dữ liệu NoSQL. Những điều này không được bao gồm trong kiểm tra tiêm. Tại thời điểm viết bài, MongoDB là cơ sở dữ liệu NoSQL được sử dụng rộng rãi nhất và vì vậy tất cả các ví dụ sẽ có các API MongoDB.

Làm thế nào để kiểm tra

Kiểm tra lỗ hổng NoSQL Injection trong MongoDB

API MongoDB mong đợi các lệnh gọi BSON (Binary JSON) và bao gồm một công cụ lắp ráp truy vấn BSON an toàn. Tuy nhiên, theo tài liệu MongoDB – các biểu thức JSON và JavaScript chưa được công nghệ hóa được cho phép trong một số tham số truy vấn thay thế. Lệnh gọi API được sử dụng phổ biến nhất cho phép nhập JavaScript tùy ý là toán tử $ where.

MongoDB $ nơi toán tử thường được sử dụng như một bộ lọc hoặc kiểm tra đơn giản, vì nó nằm trong SQL.

db.myCollection.find ({$ where: "this.credits == this.debits"});

Theo tùy chọn, JavaScript cũng được đánh giá để cho phép các điều kiện nâng cao hơn.

<code>db.myCollection.find( { $where: function() { return obj.credits - obj.debits &lt; 0; } } );</code>

ví dụ 1

Nếu kẻ tấn công có thể thao túng dữ liệu được truyền vào toán tử $ where, kẻ tấn công đó có thể bao gồm JavaScript tùy ý để được đánh giá như một phần của truy vấn MongoDB. Một lỗ hổng mẫu được tiết lộ trong đoạn mã sau, nếu thông tin đầu vào của người dùng được chuyển trực tiếp vào truy vấn MongoDB mà không cần làm sạch.

db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;

Giống như việc thử nghiệm các kiểu tiêm khác, người ta không cần phải khai thác hết lỗ hổng để chứng minh sự cố. Bằng cách đưa các ký tự đặc biệt có liên quan đến ngôn ngữ API đích và quan sát kết quả, người thử nghiệm có thể xác định xem ứng dụng đã khử trùng đầu vào một cách chính xác hay chưa. Ví dụ: trong MongoDB, nếu một chuỗi có chứa bất kỳ ký tự đặc biệt nào sau đây được chuyển qua chế độ không xác thực, nó sẽ gây ra lỗi cơ sở dữ liệu.

' " \ ; { }

Với SQL injection thông thường, một lỗ hổng tương tự sẽ cho phép kẻ tấn công thực thi các lệnh SQL tùy ý – để lộ hoặc thao túng dữ liệu theo ý muốn. Tuy nhiên, vì JavaScript là một ngôn ngữ có đầy đủ tính năng, điều này không chỉ cho phép kẻ tấn công thao túng dữ liệu mà còn chạy mã tùy ý. Ví dụ: thay vì chỉ gây ra lỗi khi kiểm tra, việc khai thác đầy đủ sẽ sử dụng các ký tự đặc biệt để tạo JavaScript hợp lệ.

Đầu vào này

0; var date = new Date (); do {curDate = new Date ();} while (curDate-date &lt;10000) 

được chèn vào $ userInput trong mã ví dụ trên sẽ dẫn đến việc thực thi hàm JavaScript sau. Chuỗi tấn công cụ thể này sẽ yêu cầu toàn bộ cá thể MongoDB thực thi ở mức sử dụng 100% CPU trong 10 giây.

function() { return obj.credits - obj.debits &lt; 0;var date=new Date(); do{curDate = new Date();}while(curDate-date&lt;10000); }

Ví dụ 2

Ngay cả khi đầu vào được sử dụng trong các truy vấn hoàn toàn được làm sạch hoặc được tham số hóa, vẫn có một đường dẫn thay thế trong đó người ta có thể kích hoạt chèn NoSQL. Nhiều phiên bản NoSQL có tên biến dành riêng, độc lập với ngôn ngữ lập trình ứng dụng.

Ví dụ: trong MongoDB,$ trong đó cú pháp chính nó là một toán tử truy vấn dành riêng. Nó cần được chuyển vào truy vấn chính xác như được hiển thị; bất kỳ thay đổi nào sẽ gây ra lỗi cơ sở dữ liệu. Tuy nhiên, vì $ where cũng là một tên biến PHP hợp lệ, kẻ tấn công có thể chèn mã vào truy vấn bằng cách tạo một biến PHP có tên $ where. Tài liệu PHP MongoDB cảnh báo rõ ràng cho các nhà phát triển:

Vui lòng đảm bảo rằng đối với tất cả các toán tử truy vấn đặc biệt (bắt đầu bằng $), bạn sử dụng các dấu ngoặc kép để PHP không cố gắng thay thế $ exist bằng giá trị của biến $ exist.

Ngay cả khi một truy vấn không phụ thuộc vào dữ liệu người dùng nhập vào, chẳng hạn như ví dụ sau, kẻ tấn công có thể khai thác MongoDB bằng cách thay thế toán tử bằng dữ liệu độc hại.

db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } );

Một cách để có thể gán dữ liệu cho các biến PHP là thông qua Ô nhiễm tham số HTTP (xem: Kiểm tra ô nhiễm tham số HTTP). Bằng cách tạo một biến có tên $ trong đó thông qua ô nhiễm tham số, người ta có thể kích hoạt lỗi MongoDB cho biết rằng truy vấn không còn hợp lệ. Bất kỳ giá trị nào của $ không phải là chuỗi $ mà chính nó, phải đủ để chứng minh tính dễ bị tổn thương. Kẻ tấn công sẽ khai thác toàn bộ bằng cách chèn các nội dung sau:

$where: function() { //arbitrary JavaScript here }

Xem thêm Kiểm tra lỗ hổng bảo mật SQL injection cho MS Access

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now