什麼是 NoSQL 注入？運作原理與預防方法

什麼是 NoSQL 注入？

NoSQL 注入是一種漏洞，讓攻擊者透過未經淨化的使用者輸入，插入惡意運算子、JavaScript 程式碼或特製語法，操控傳送至 NoSQL 資料庫的查詢。在通用弱點列舉 (CWE) 中，此漏洞正式歸類為 CWE-943，即「資料查詢邏輯中的特殊元素未妥善中和」。它鎖定 MongoDB、Redis、Cassandra 和 Elasticsearch 等資料庫；這些資料庫使用彈性、無結構描述的查詢語言，而非標準 SQL。

成功利用此漏洞的影響，遠不止一筆遭竄改的查詢。攻擊者可完全繞過身分驗證、逐字元擷取敏感資料、修改紀錄、造成阻斷服務，或在伺服器上執行任意程式碼。正如 OWASP WSTG 所指出，「潛在影響比傳統 SQL 注入更大」，因為 NoSQL 注入酬載可能在 JavaScript 等程序式語言中執行，而不僅限於宣告式查詢語言。

從登入系統、聊天平台到電子商務目錄和 IoT 管理主控台，NoSQL 資料庫如今無所不在。隨著採用日益普遍，加上許多人誤以為「沒有 SQL 就不會有注入」，這類漏洞始終構成風險。這個迷思是錯的，攻擊者正是看準了這一點。 

在探討 NoSQL 注入的實際運作方式前，先了解它在標準漏洞分類架構中的位置。

OWASP 分類

OWASP 在 2021 年及 2025 年 Top 10 中，均將 NoSQL 注入歸類為注入類別。它與 SQL 注入屬於同一風險類別，但根本原因的分類不同，影響測試與回報方式。

關鍵差異在於對應的 CWE。傳統SQL 注入屬於 CWE-89 (SQL 命令中使用的特殊元素未妥善中和)，而 NoSQL 注入對應 CWE-943 (資料查詢邏輯中的特殊元素未妥善中和)。CWE-943 涵蓋 SQL 以外的查詢語言，包括 MongoDB 的二進位 JSON (BSON) 運算子、Redis 通訊協定命令，以及 CouchDB 以 REST 為基礎的查詢。

如果您的安全測試計畫或合規報告只追蹤 CWE-89，NoSQL 注入的發現可能被錯誤分類，甚至完全遺漏。讓工具與分類方式對應 CWE-943，就能消除這個盲點。 

釐清分類後，下一步是了解攻擊者利用 NoSQL 查詢介面的具體手法。

NoSQL 注入如何運作？

NoSQL 注入利用應用程式預期的使用者輸入與實際收到的內容之間的落差。相較之下，SQL 注入針對的是通用查詢語言，NoSQL 注入則因資料庫而異。MongoDB 使用 BSON/JSON 查詢運算子，Redis 使用 Redis 序列化通訊協定 (RESP) 線路通訊協定，而 CouchDB 則提供 HTTP REST API。每種資料庫都有不同的 攻擊面, 但核心原理不變：使用者可控制的資料未經適當驗證就進入查詢，進而改變查詢邏輯.

運算子注入：最常見的模式

在典型的 MongoDB 後端 Node.js 應用程式中，登入端點可能會建立如下查詢：

合法請求會傳送 {"username":"admin","password":"secret"}. 但攻擊者可以提交：

The $ne (不等於) 運算子會指示 MongoDB 傳回使用者名稱和密碼都不等於 "invalid" 的所有使用者，這會符合每個有效帳戶. 只需一次請求就能繞過身分驗證，無須暴力破解.

透過 $where

當應用程式將使用者輸入傳入 MongoDB 的 $where 運算子或 mapReduce, $accumulator, 或 $function 等函式時，資料庫會將其作為伺服器端 JavaScript 執行. 攻擊者若注入忙碌迴圈酬載，就能使 MongoDB 執行個體無法運作，造成阻斷服務. 除了存取資料，執行任意 JavaScript 也可能導致 遠端程式碼執行，發生於資料庫伺服器上.

盲注擷取

當應用程式不直接傳回查詢結果時，攻擊者會使用布林值或時間差技術，逐字元擷取資料. 透過提交 password[$regex]=^a 之類的正規表示式模式，並觀察回應是否與已知為假的條件不同，攻擊者即使從未直接看到資料外洩，也能重建密碼、權杖和其他機密資料.

透過 CRLF 進行 Redis 命令注入

在 RESP 中，命令以歸位字元和換行字元 (CRLF) 序列 (\r\n) 分隔. 當應用程式未經清理就將使用者輸入串接至 Redis 通訊協定層級的命令時，攻擊者便能注入 CRLF 序列，結束目前的命令，並在同一連線中附加未經授權的命令.

Redis 以鍵值對儲存資料，注入的命令如 SET, GET, 以及 CONFIG 可讀取敏感資料、覆寫鍵，甚至完全重新設定伺服器. 此技術經常與伺服器端請求偽造 (SSRF) 串連使用：攻擊者利用 SSRF 漏洞連線至未對公用網際網路開放的內部 Redis 執行個體，再透過 SSRF 通道注入附加命令.

CouchDB 中的 HTTP API 注入

CouchDB 提供 REST/HTTP API，表示所有資料庫操作都透過含有 JSON 酬載的標準 HTTP 請求執行. 當應用程式將未經清理的使用者輸入傳入 CouchDB 查詢參數、檢視定義或 Mango 選擇器物件時，就會發生注入.

由於 CouchDB 使用以 JavaScript 撰寫的 MapReduce 檢視，因此存在與 MongoDB 的 $where 運算子類似的伺服器端執行風險. 攻擊者若能影響 MapReduce 檢視中執行的 JavaScript，就能在資料庫伺服器上執行任意程式碼. 攻擊者也能透過特製的 HTTP 請求濫用 CouchDB 的複寫功能，對內部服務發動 SSRF.

無論是 MongoDB 的 BSON 運算子、Redis 的通訊協定層級 CRLF 注入，或 CouchDB 的 REST API，每種 NoSQL 資料庫都有不同的攻擊面. 您的 NoSQL 注入防禦措施必須對應各資料庫的特定查詢介面.

這些機制適用於各種內容類型、傳輸層和框架. 其背後的根本原因反覆出現, 而這種重複性正是防禦者取得優勢的關鍵.

NoSQL 注入的成因

NoSQL 注入並非源於單一程式設計錯誤. 它是架構假設、框架行為與缺少驗證層共同作用的結果, 這些因素在執行時相互疊加.

輸入驗證不當及缺乏型別強制檢查

您的應用程式可能假設像 password 這樣的欄位一定會以字串形式傳入, 但 HTTP 請求主體、JSON 酬載和 URL 編碼參數都能傳遞物件與陣列. 當 Express.js body-parser 收到 password[$ne]=x, 它會在應用程式程式碼接觸到資料之前, 自動將其反序列化為 { password: { $ne: "x" } }, 也就是 MongoDB 運算子物件.

動態建構查詢

如果您使用字串串接或插值, 而非結構化查詢物件來組合查詢, 攻擊者就能破壞查詢語法並注入新邏輯. 根據 MongoDB 論壇的說明: "在大多數情況下, 外部注入是建立查詢時不安全地串接字串所造成的."

伺服器端 JavaScript 未停用

MongoDB 支援透過 $where, mapReduce, $accumulator, 和 $function. 這份 MongoDB 檢查清單明確建議, 若未使用這些操作, 應透過 --noscripting 停用伺服器端指令碼. 若未停用, 就會形成可執行任意程式碼的攻擊面.

框架層級的型別轉換

PHP 會自動將 username[$ne]=toto 轉換為 ['username' => ['$ne' => 'toto']]. Express.js body-parser 也會對 URL 編碼的表單資料執行相同操作, 將 password[$ne]=x 反序列化為 { password: { $ne: "x" } }, 也就是 MongoDB 運算子物件, 而此時請求尚未進入應用程式程式碼. 這些框架行為不需開發人員刻意操作, 就會將看似無害的 HTTP 參數轉換為資料庫運算子.

ORM 層漏洞

即使 MongoDB 本身已經過安全強化, 您的應用程式所使用的物件關聯對映 (ORM) 程式庫仍可能引入注入攻擊面. CVE-2024-53900 顯示, 攻擊者可透過使用者可控制的輸入利用 Mongoose 的 $where 運算子, 而 CVE-2025-23061 則顯示, 首次修補並不完整, $where 仍可透過巢狀置於以下項目之下來繞過 $or 在 Mongoose 的 populate().match 功能中，完全繞過伺服器層級的防護.

停用線路協定驗證

MongoDB 透過 net.wireObjectCheck 設定在線路協定層級驗證傳入的文件. 停用此設定會移除一道結構性防線，讓格式錯誤的 BSON 得以進入查詢引擎.

這些成因形成了攻擊面，涵蓋從 HTTP 解析到資料庫執行的各個環節，直接轉化為業務風險.

影響與風險

NoSQL 注入會影響機密性、完整性與可用性 (CIA) 三要素的每個面向，而且往往同時發生.

• 機密性: 攻擊者可讀取任意文件、列舉欄位名稱，並利用盲注技術逐字元擷取憑證. 在 CVE-2021-22911 案例中，研究人員從 Rocket.Chat 執行個體洩漏了管理員密碼雜湊值和密碼重設權杖.
• 完整性: 運算子注入與濫用原始查詢讓攻擊者能修改、取代或刪除文件. 夾帶的查詢可插入全新紀錄，或覆寫現有欄位值.
• 可用性: $where 忙碌迴圈酬載可使 MongoDB 執行個體持續處於高負載狀態，無須在網路層發動大量流量攻擊，就能讓資料庫實際上無法運作.
• 繞過身分驗證是最常見的已記錄影響之一. 這使 NoSQL 注入成為取得對外開放應用程式初始存取權的直接途徑.
• 供應鏈與下游風險會擴大 NoSQL 注入對平台產品的影響範圍. 當漏洞危及 Rocket. Chat 或 Parse Server 等平台時，影響會延伸至該平台的租戶與下游使用者. 後端即服務產品中的單一注入漏洞，可能暴露建構於該平台上的多個應用程式，使一個漏洞演變成多個環境遭入侵.
• 法規與合規後果直接源於機密性遭破壞. 當 NoSQL 注入導致個人識別資訊、憑證或客戶通訊內容遭竊取時，組織須依 GDPR、HIPAA、PCI DSS及各州隱私法等規範履行資料外洩通報義務. 盲注攻擊所使用的逐字元擷取技術，可能在長時間內悄悄竊取敏感資料. 這種緩慢的資料外洩容易被忽略，因此及早偵測至關重要.

• 遠端程式碼執行已透過伺服器端 JavaScript 執行得到證實. OWASP WSTG 指出，"由於 JavaScript 是功能完整的程式語言，這不僅讓攻擊者能操縱資料，還能執行任意程式碼." 一篇發表於 2025 年數位鑑識與安全國際研討會 (ISDFS) 的論文直言這項風險："由於 JavaScript 功能強大，暴露這類漏洞就像把機關槍交給頂尖罪犯."

了解攻擊者手法的防禦者，能在每個階段阻止攻擊. 以下說明攻擊者如何行動.

攻擊者如何利用 NoSQL 注入

攻擊者依循一套有系統的方法尋找並利用 NoSQL 注入，從偵察逐步進入資料竊取或程式碼執行階段.

階段 1: 尋找輸入途徑

攻擊者找出傳遞至 NoSQL 後端的參數：URL 參數、JSON POST 主體、HTTP 標頭和 WebSocket 訊息. 他們會提交模糊測試字元 (' " \ ; { }) 並觀察是否出現揭露資料庫互動情形的錯誤訊息或行為變化.

階段 2: 確認運算子注入

攻擊者針對登入端點, 將一般的憑證字串替換為 $ne 運算子:

如果應用程式回傳其他使用者的登入成功結果, 即可確認運算子注入. 攻擊者也可能測試 $gt (大於) 運算子, 作為另一種確認方式:

The $gt 運算子搭配空字串, 可比對任何非空白的密碼值. 如果沒有有效密碼也能成功登入管理員帳號, 就能進一步確認運算子注入.

階段 3: 繞過身分驗證

攻擊者在兩個欄位中注入運算子, 進一步擴大攻擊:

此操作專門鎖定具備特權的帳號, 回傳第一個使用者名稱符合清單, 且密碼為任意非空白字串的使用者.

階段 4: 資料外洩

透過 $where JavaScript 注入, 攻擊者探測欄位是否存在:

如果回應符合已知有效的模式, 表示 resetToken 欄位存在. 接著攻擊者透過布林式盲注, 逐字元擷取其值. 此技術的做法是提交如下的規則運算式模式 {"resetToken":{"$regex":"^A"}} 並觀察 HTTP 回應. 成功狀態碼或特定回應內容表示字元相符, 不同的回應則表示不相符. 攻擊者逐一測試每個字元位置, 每一步都測試完整的候選字元集. 如 CVE-2024-37405 所記載, 這種擷取方式可透過反覆發送請求並比較回應差異來進行, 因此盲注是實際可行的攻擊, 而非僅止於理論上的疑慮.

階段 5: 權限提升與橫向移動

取得憑證或重設權杖後, 攻擊者便能取得管理權限. 接著, 他們可以轉向後端系統, 透過使用 $lookup 或 $unionWith (獲 PortSwigger 提名為頂尖網頁入侵技術) 進行聚合管線注入, 存取其他集合, 或透過伺服器端程式碼執行建立持續存取能力. 使用 $lookup 進行聚合管線注入具有高度影響力, 因為它能讀取應用程式查詢原本不應存取的集合, 實質突破集合層級的存取邊界, 使整個資料庫的資料暴露.

切換 Content-Type

攻擊者經常在 application/x-www-form-urlencoded 和 application/json 之間切換, 尋找只存在於其中一種內容類型的注入點. 此技術對處理多種格式的 REST API 特別有效.

只要 NoSQL 資料庫接受使用者輸入, 這些攻擊技術就可能奏效. 某些應用程式比其他應用程式更容易直接遭受攻擊.

哪些對象會受到影響?

凡是將使用者可控的輸入傳送至 NoSQL 資料庫, 卻未妥善強制檢查資料類型的應用程式, 都可能受到 NoSQL 注入影響. 根據已確認的 CVE 證據, 暴露風險最高的應用程式類別包括:

• 身分驗證系統: 各大主要資料來源均記載, 登入端點是典型的攻擊面.
• 團隊協作平台: 多年來, Rocket.Chat 涉及多項 NoSQL 注入 CVE, 其中包括身分驗證前的漏洞 (CVE-2021-22911).
• 使用 Mongoose 的 Node.js/Express 應用程式: Mongoose 是物件文件對應器 (ODM)，會在 ORM 層形成注入攻擊面，不受 MongoDB 本身的控制措施影響。
• 平台即服務後端: Parse Server (CVE-2022-24815, CVE-2026-30941) 和 Steedos Platform (CVE-2020-35666) 顯示後端即服務產品也存在風險。
• 物聯網與網路管理: Ubiquiti 的 UniFi Network Application 存在供應商確認的 NoSQL 注入漏洞，並獲指派 CVE 編號。此漏洞可導致權限提升。
• 電子商務平台: AquilaCMS 的密碼重設功能存在 NoSQL 注入漏洞，嚴重程度評為「嚴重」(CVE-2024-48573)。
• GraphQL API: 未經清理就直接帶入 MongoDB 查詢的 GraphQL 篩選引數，會形成經常被忽略的注入攻擊面。

MongoDB 使用廣泛，Node.js/Express 也普遍用於後端開發。兩者結合形成廣泛的攻擊面。 NIST IR 8504 正式將 NoSQL 注入列為美國政府系統已知的風險類別，凸顯這項風險也適用於企業環境，而不僅限於新創公司或 SaaS 環境。

GraphQL API 已成為越來越常見的攻擊途徑，因為篩選引數經常在沒有明確允許清單的情況下直接帶入 MongoDB 查詢，而傳統的傳統式 網頁應用程式防火牆 (WAF) 規則著重於 SQL 類型的酬載，難以涵蓋這種模式。

共同點不是產業，而是技術架構。如果應用程式使用 MongoDB、Redis、CouchDB 或 Elasticsearch 處理使用者輸入，就可能成為攻擊目標。若採用會自動轉換資料型別的 JavaScript 框架，風險尤其高。以下經確認的事件顯示實際攻擊如何發生。

真實案例

已確認的 CVE 和公開的攻擊鏈，顯示 NoSQL 注入如何影響協作平台、電子商務、後端即服務產品與網路基礎設施的正式系統。

Rocket.Chat: 無須驗證即可接管管理員帳號 (CVE-2021-22911)

SonarSource 的研究 顯示，Rocket.Chat 的 getPasswordPolicy() 方法無須驗證即可呼叫。攻擊者可將 MongoDB 的 $regex 運算子注入密碼重設權杖參數，透過傳送 {"$regex":"^A"} 並觀察回應差異，逐字元擷取權杖。

經確認的 HackerOne 報告 揭露了攻擊鏈: 洩漏管理員使用者名稱、電子郵件地址、密碼雜湊值及重設權杖，最終完全接管管理員帳號。

@feathersjs/mongodb: WebSocket 物件注入 (CVE-2026-29793)

Socket.IO 用戶端可將任意 JavaScript 物件作為 id 引數，傳給任何 Feathers 服務方法。傳輸層未執行型別檢查。將 {$ne: null} 作為 id 傳送，會符合資料集合中的每份文件。此漏洞的追蹤編號為 CVE-2026-29793。

Ubiquiti UniFi: 通過驗證後提升權限 (CVE-2026-22557)

Ubiquiti 自行發布的安全公告確認，UniFi Network Application 存在通過驗證後可利用的 NoSQL 注入漏洞，能導致權限提升。任何通過驗證的使用者都可利用此漏洞取得更高權限，從低權限帳號全面掌控網路基礎設施的管理權。

Rocket.Chat Livechat: 串連式注入攻擊 (CVE-2024-37405)

兩個不同的 NoSQL 注入點被 串接起來: 先透過 $regex 盲注擷取訪客權杖, 接著在 rid 參數中進行第二次注入, 傾印所有 Livechat 訊息. 這種驗證前攻擊暴露了面向客戶的通訊資料.

AquilaCMS: 密碼重設功能中的重大注入漏洞 (CVE-2024-48573)

AquilaCMS, 一個開放原始碼電子商務平台, 因密碼重設功能存在 NoSQL 注入漏洞, 被評為極嚴重 (9.8). 未經身分驗證的攻擊者可將 MongoDB 運算子注入重設權杖參數, 操縱密碼重設流程, 完全繞過原有的驗證邏輯. 由於 AquilaCMS 用於建置電子商務店面, 一旦漏洞遭到成功利用, 客戶帳戶資料, 付款資訊及訂單記錄都將面臨風險. 此漏洞無須身分驗證, 可透過標準 HTTP 請求從遠端利用, 因此任何能透過網路存取店面的攻擊者都可能利用此漏洞.

Parse Server: 反覆出現的注入漏洞 (CVE-2022-24815, CVE-2026-30941)

Parse Server 是廣泛使用的開源後端即服務平台, 多年來反覆出現 NoSQL 注入漏洞. CVE-2022-24815 結合原型污染與 NoSQL 注入, 顯示 JavaScript 層的漏洞如何與資料庫注入交互作用, 形成單一漏洞無法造成的利用路徑. 多年後, CVE-2026-30941 揭露該平台仍存在注入途徑, 使權杖值在未經型別驗證的情況下傳入資料庫查詢. 後端即服務產品是高價值目標, 因為單一漏洞就會影響以該平台建置的每個應用程式. 一旦 Parse Server 遭入侵, 仰賴它的行動應用程式, 網頁應用程式與 IoT 後端都可能面臨相同風險.

這些事件橫跨多年與不同技術堆疊. NoSQL 注入不斷在正式環境中重現, 這條時間線顯示此模式已持續多久.

NoSQL 注入時間線

2026 年集中出現的 CVE 顯示研究人員日益關注 Node.js/MongoDB 技術堆疊, 也意味著 NoSQL 注入可能重新受到重視, 而非逐漸淡出視野. 這個趨勢使偵測成為優先要務. 好消息是, 相關跡象已相當明確.

如何偵測 NoSQL 注入

找出 NoSQL 注入需要結合靜態程式碼分析, 對實際運作端點進行動態測試, 以及執行階段行為監控, 才能發現其他防護措施遺漏的漏洞利用行為.

靜態分析與程式碼審查

檢查程式碼庫中的高風險模式. 標記所有 Mongoose .find(), .findOne(), 或 .populate() 呼叫中直接傳入 req.body, req.query, 或 req.params 而未強制檢查型別。檢查是否有任何使用 $where 處理使用者可控制輸入的情況、任何納入使用者可控制篩選物件的聚合管線, 以及任何接受用戶端原始 JSON 查詢物件的端點。此外, 標記任何使用 eval(), Function(), 或使用範本字面值將使用者輸入串接至查詢字串的情況。若聚合管線使用 $lookup 或 $unionWith 搭配使用者可控制的集合名稱或管線階段, 應特別仔細檢查, 因為這些情況可能突破集合層級的存取邊界。

動態測試

遵循 OWASP WSTG-INPV-05.6 的方法:

1. 提交模糊測試字串 '"\{ ;$Foo} $Foo \xYZ` 以找出語法注入點。
2. 提交特殊字元 ' " \ ; { } 以找出運算子注入點。
3. 使用 HTTP 參數污染注入 $where 參數, 並觀察 MongoDB 的錯誤回應。
4. 使用已知為真與已知為假的條件測試布林回應差異, 以找出盲注漏洞。

您也應專門測試 WebSocket 通道。 CVE-2026-29793 顯示 Socket.IO 用戶端可將任意 JavaScript 物件作為服務方法引數傳送, 繞過所有 HTTP 層檢查。許多掃描器只關注 HTTP 端點, 因而完全漏掉 WebSocket 注入面。對採用即時通訊框架的應用程式進行手動或專門的 WebSocket 測試, 可補足這項缺口。

執行階段行為監控

監控基礎架構中顯示攻擊得逞的行為指標:

• 資料庫服務程序 (mongod, redis-server) 啟動非預期的子程序或 shell
• 包含 MongoDB 運算子語法的異常查詢模式 ($where, $regex, $ne, $gt) 出現在應用程式日誌中
• MongoDB 伺服器的 CPU 使用率飆升，但沒有對應的合法查詢負載
• 密碼重設端點的權杖欄位收到物件，而非字串
• 公開端點的回應時間出現差異，可能是基於時間的盲注跡象

滲透測試工具

專用工具可協助您在評估期間探測 NoSQL 注入：

• NoSQLMap: 專為 NoSQL 注入測試與利用打造的開放原始碼工具
• nosqli: 用於自動探索 NoSQL 注入的命令列工具
• Burp Suite: 透過 Repeater 和 Intruder 模組進行手動測試，並使用擴充功能自動測試 NoSQL 酬載
• OWASP ZAP: 適用於 NoSQL 端點的主動掃描規則

知道從哪裡著手檢查，只是挑戰的一半。另一半是建立防禦措施，從源頭防止漏洞遭到利用。

如何防止 NoSQL 注入

防止 NoSQL 注入，首先要在所有使用者輸入到達資料庫層之前，強制執行嚴格的型別檢查。以下防禦措施針對前述各項根本原因，涵蓋框架層級的型別強制轉換到繞過 ORM 層的手法。

建構查詢前強制執行型別檢查

在輸入欄位到達 ORM 或資料庫驅動程式之前，拒絕任何非純量值（字串、數字、布林值）。明確進行型別強制轉換是最有效的單一防禦措施：

移除或拒絕 MongoDB 運算子鍵

檢查 req.body、req.query 和 req.params 中的所有鍵是否含有 $ 前綴，並在這些鍵到達資料庫層之前予以拒絕。請使用 key.startsWith('$') 進行檢查，而非使用正規表示式；如 CVE-2021-22910 所述，正規表示式存在已知的繞過方式。

停用伺服器端 JavaScript

在 MongoDB 設定中使用 --noscripting，或將 set security.javascriptEnabled: false。這可徹底消除 $where 攻擊面。條件邏輯應優先使用 $expr 和具備型別檢查的查詢建構器。

使用結構描述驗證框架

在請求處理流程的早期，使用 Joi、Ajv 或 Zod 等函式庫強制驗證資料型別。當預期為純量值卻收到陣列或物件時，這些工具會予以拒絕，在運算子注入抵達資料庫前加以阻止。

鎖定 Mongoose 和 ORM 版本，留意安全公告

ORM 層的漏洞可能完全繞過應用程式層和資料庫層的控制措施。 CVE-2024-53900 和 CVE-2025-23061 顯示，即使停用 MongoDB 伺服器端 JavaScript，Mongoose 的 populate().match 功能仍可能遭到利用。CVE-2025-23061 是 CVE-2024-53900 修補不完整所造成的漏洞，這表明修補程式本身可能不足以解決問題，必須獨立驗證。

訂閱 Mongoose 和其他 ODM/ORM 函式庫的安全公告，明確鎖定相依套件版本，並在結束修復工單前，驗證每項安全修補程式是否已徹底解決公告中的漏洞。

絕不接受來自用戶端的原始 JSON 查詢

該 OWASP 速查表 明確指出：「不要接受來自用戶端的原始 JSON 查詢。」用戶端提交以下酬載可能導致遠端程式碼執行或 CPU 資源耗盡：{ "$where": "this.balance > 0" }。

採用最小權限原則設定資料庫

使用權限最低的專用應用程式資料庫帳戶。絕不使用 root 或管理員憑證連線。不要將資料庫連接埠或管理主控台暴露於公用網際網路。

保持啟用 Wire Object Check

MongoDB 的 net.wireObjectCheck 設定會在傳輸協定層級驗證所有文件。此設定預設為啟用，絕不可停用。

保護 GraphQL 篩選條件

透過明確的允許清單轉換 GraphQL 篩選參數。絕不可將不受信任的物件直接展開至 MongoDB 或 Mongoose 查詢篩選條件中。

完善的應用程式層控制措施可縮小攻擊面，但無法完全消除風險。分層偵測與回應能涵蓋未被攔截的威脅。

偵測與防護工具

結合應用程式層控制措施、測試工具與執行階段監控，建立抵禦 NoSQL 注入的分層防禦。

• 應用程式層防禦措施包括輸入驗證函式庫 (Joi、Ajv、Zod)、ORM 層防護措施 (Mongoose 結構描述驗證、明確的型別轉換)，以及 MongoDB 內建的安全控制措施 (--noscripting、wireObjectCheck、角色型存取控制)。
• 測試工具，如 NoSQLMap、nosqli、Burp Suite 和 OWASP ZAP，可在開發與滲透測試期間探測 NoSQL 注入漏洞。
• WAF 提供周邊防禦層，可封鎖已知的注入模式。然而，WAF 仰賴特徵碼規則，無法阻止新型酬載、經過混淆的運算子，或透過 WebSocket 通道發動的注入攻擊。
• 執行階段行為監控可填補 WAF 留下的防護缺口。新型酬載、Mongoose populate().match 問題等 ORM 層漏洞，或 WAF 未檢查的 WebSocket 通道，都可能繞過應用程式層控制措施。無論酬載透過何種途徑傳遞，執行階段監控都能觀察成功注入後的影響，例如資料庫程序啟動非預期的 Shell、異常的 JavaScript 執行模式，或異常的查詢量。當注入酬載躲過特徵碼檢查並抵達資料庫時，隨之出現的異常行為便是最可靠的入侵指標。

SentinelOne 如何提供協助？

檢查酬載是 WAF 的工作。SentinelOne 則監控後續活動，找出並阻止 NoSQL 注入成功後的行為後果：應用程式層控制措施未察覺的程序異常、橫向移動及漏洞利用後活動。

SentinelOne 的 Singularity™ Platform 包含 Singularity AI SIEM, 可在單一資料湖中關聯端點, 雲端工作負載, 身分識別系統和第三方來源的遙測資料. 在 2024 年 MITRE ATT&CK 評測中, Singularity Platform 達到 100% 偵測率且零延遲, 產生的警示數量比中位數少 88%. 雜訊更少, 您的團隊就能專注處理已確認的威脅. 當 NoSQL 注入攻擊從 Web 應用程式延伸至資料庫伺服器, 再導致憑證遭竊時, AI SIEM 無須手動關聯, 就能串聯不同攻擊面的事件.

在 Singularity Endpoint 中，Storyline 技術持續串連每個受保護端點上的處理程序建立事件、網路連線、檔案修改及憑證使用情形，形成完整的溯源鏈。對於利用 $where 執行伺服器端 JavaScript 的攻擊，Storyline 會自動將接收惡意請求的網頁伺服器處理程序、出現異常行為的資料庫服務、衍生的直譯器處理程序及任何子 Shell 串連起來，並歸入同一個 Storyline ID。當 mongod 或 redis-server 等資料庫處理程序衍生非預期的子處理程序時，Storyline Active Response (STAR) 自訂規則便會觸發。這是命令注入成功的高可信度行為指標。

Purple AI™ 透過自然語言查詢加快調查速度。根據 IDC 的數據，Purple AI 客戶的威脅識別速度提升 63%，平均修復時間 (MTTR) 縮短 55%。您可以詢問「顯示過去 24 小時內由 mongod 啟動的所有程序」，或直接參照 T1190（利用公開應用程式）和 T1059（命令與指令碼直譯器）等 MITRE ATT&CK 技術。Purple AI 的 Auto Investigation 功能會自主收集跨技術堆疊的證據、整合威脅資料，並建立完整的攻擊時間軸，將過去耗時數小時的調查縮短至數分鐘。

Cloud Workload Security 為雲端託管的 NoSQL 資料庫提供執行階段防護。它即時監控工作負載行為，並運用 Verified Exploit Paths 揭示有證據支持的發現結果。當針對雲端託管 MongoDB 或 Redis 執行個體的 NoSQL 注入導致入侵後活動時，您就能看見。

對於大規模運作 NoSQL 資料庫的組織，這些功能能填補應用程式層級預防與入侵後可視性之間的缺口。 

預約 SentinelOne 示範，親眼了解這些功能如何運作。

相關漏洞

NoSQL 注入與以下幾類相關漏洞有共同的根本原因和攻擊模式：

• SQL 注入 (CWE-89)：這是關聯式資料庫中的對應漏洞。兩者都利用資料庫查詢未妥善處理使用者輸入的問題，但 NoSQL 注入可執行程序式語言，因此影響不只限於資料竄改，還可能執行任意程式碼。
• 伺服器端請求偽造 (SSRF)： Redis CRLF 注入經常與 SSRF 串連使用。攻擊者利用 SSRF 存取內部 Redis 執行個體，再透過 CRLF 序列夾帶注入命令。
• 命令注入 (CWE-78)： 當 NoSQL 注入透過 $where 達成伺服器端 JavaScript 執行時，所取得的能力與作業系統命令注入十分相近。
• 原型污染：CVE-2022-24815 顯示 Parse Server 中的原型污染可與 NoSQL 注入結合，說明 JavaScript 層的漏洞如何加劇資料庫注入的影響。
• 跨網站指令碼攻擊 (XSS)：XSS 與 NoSQL 注入都源於輸入驗證不足。容易遭受其中一種攻擊的組織，往往也存在系統性的驗證弱點，因而面臨另一種攻擊風險。

了解這些關聯，有助於您跨相關漏洞類別排定測試與修補的優先順序，而非逐一孤立處理。下表列出已確認的 NoSQL 注入 CVE，供您參考。