SQL 注入 (SQLi) 是現存最危險和最常見的漏洞之一。然而，在過去幾年中，由于易用性和可擴展性，NoSQL 數據庫作為 Web 應用程序和分布式云平臺的后端數據庫越來越受歡迎。鑒于在這些 NoSQL（非 SQL/不僅是 SQL）數據庫中不執行 SQL 查詢，這是否意味著非 SQL 數據庫不易受到注入攻擊？抱歉不行。那么，如何防范NoSQL呢？讓我們從 NoSQL 注入的概述開始。
什么是 NoSQL 注入？?
NoSQL 數據庫?
NoSQL是一個廣義術語，用于指代不使用 SQL 查詢語言的非關系數據庫/數據存儲系統。一些示例包括 MongoDB、Cassandra DB、CouchDB 和 Riak。其中，MongoDB 是最受歡迎的數據庫。
雖然 SQL 數據庫存儲在表中，但在非 SQL 數據存儲系統中使用了更適合目的/上下文的多種數據模型。例如，對象、文檔、圖形、鍵值、列族等等。由于支持動態模式定義，因此可以根據敏捷開發周期輕松添加/修改新字段和數據，這與 SQL 數據庫不同。
NoSQL注入?
將惡意負載注入非 SQL 數據庫（例如 MongoDB）的網絡攻擊稱為 NoSQL 注入。
NoSQL 注入如何工作？?
SQL 注入是在查詢（尤其是來自用戶的查詢）未經過清理時引起的，允許攻擊者修改數據庫引擎以包含在數據庫中執行命令的惡意輸入。但是，SQLi 不能在非 SQL 數據庫上執行，因為它們沒有特定的語言。它們具有特定于產品的語法和查詢語法，這些語法和查詢語法是用應用程序語言本身編寫的。
結果?——NoSQL 數據庫不僅可以被攻擊者破壞，而且惡意代碼/未經驗證的輸入可以在應用程序本身中執行。因此，DDoS 攻擊可以被精心策劃，或者服務器被接管或攻擊者利用非 SQL 注入漏洞泄露機密用戶信息。
在典型的 NoSQL 架構中，數據訪問是通過驅動程序完成的。數據庫客戶端的多種語言庫可通過驅動程序訪問協議獲得。考慮到驅動程序可能不易受攻擊，但其中可能存在不安全的 API，如果開發人員不安全地實施這些 API，可能會導致在數據庫和應用程序本身上執行任意代碼。
讓我們考慮一下 MongoDB 的例子。
- MongoDB 使用帶有安全 BSON 查詢組裝工具的 BSON（二進制 JSON）數據格式。鑒于查詢表示為 BSON 對象/二進制數據，直接注入是不可能的。
- 但是，應用程序可以在 MongoDB 的服務器上的組、$where?和?MapReduce操作中運行 JavaScript???，包括數據庫中的潛在注入向量。
- 啟用此功能后，開發人員必須確保用戶無法提交惡意 JavaScript。
- 即使攻擊者無法注入完全任意的代碼，使用有限的函數集注入未經驗證的輸入也足以策劃攻擊。
例如：
下面的代碼片段使用$where查詢運算符檢索名稱為“Rafael Silver”的記錄。
在這里，攻擊者可以通過變量$userData插入未經過濾的用戶輸入
如果注入成功，他可能會注入字符串“a”；sleep (5000)進入變量$userData，這將通過服務器 5 秒——這足以讓攻擊者執行他需要的東西。
如何防止 NoSQL 注入？?
1. 安全編碼實踐?
不安全編碼的風險加劇，因為這些數據庫對于一些只熟悉 SQL 和關系數據庫的開發人員來說仍然是新奇的。必須仔細通讀 NoSQL 數據庫的安全指南和手冊。開發人員必須了解所使用的語言，以確保避免易受攻擊的結構。
開發人員必須選擇這些快速發展且年輕的數據庫的最新可用版本。例如，流行的 MongoDB 的初始版本在多個層面的設計都是不安全的，導致致命的注入攻擊，而最新版本在安全方面得到了加強。
2.輸入驗證?
與 SQL 注入一樣，在構建數據庫查詢時，必須避免在應用程序代碼中使用未經過濾的用戶輸入。必須驗證所有用戶輸入以確保不使用惡意值。雖然內置功能在非 SQL 數據庫（如 MongoDB）中可用，以避免在數據庫查詢中使用 JavaScript，但如果 JavaScript 不可避免，則輸入驗證是必須的。
3. 最小權限策略?
通常，在 Web 應用程序安全中，必須遵循最小權限原則。這樣，在攻擊成功的情況下，攻擊者的影響范圍就會受到限制。
結論
NoSQL ≠ 無注入攻擊。非 SQL 數據庫容易受到危險和破壞性的攻擊，必須主動預防。即使在開發和部署過程中盡了最大努力，應用程序中仍可能存在漏洞，導致非 SQL 注入的風險增加。采用像AppTrana這樣的全面、智能和托管的安全解決方案對于先發制人的攻擊和加強應用程序安全性非常有價值。
