一、NoSQL注入的崛起与威胁

随着非关系型数据库（NoSQL）在互联网应用中的普及，其灵活的数据模型和高扩展性成为开发者首选。然而，NoSQL的查询语法多样性（如MongoDB的BSON、Redis的键值操作）也带来了新的安全挑战——NoSQL注入攻击。此类攻击通过构造恶意查询语句绕过验证，直接操作数据库，可能导致数据泄露、篡改甚至服务中断。

1.1 攻击背景与趋势

传统SQL注入依赖关系型数据库的语法特性，而NoSQL注入则利用不同数据库的查询语言特性。例如：

• MongoDB：通过$where操作符注入JavaScript代码
• Redis：利用键名拼接构造恶意命令
• Cassandra：通过CQL（Cassandra Query Language）注入

据OWASP 2021报告，NoSQL注入漏洞在Web应用中的占比已从2019年的3%上升至12%，且攻击复杂度逐年增加。

1.2 典型攻击场景

场景1：用户认证绕过

攻击者通过构造特殊查询绕过密码验证：

// 恶意请求参数
{
  "username": "admin",
  "password": { "$gt": "" }  // MongoDB中$gt表示"大于"，任何非空密码均满足条件
}

若后端未对输入进行严格校验，攻击者可直接登录管理员账户。

场景2：数据泄露

通过注入$where执行任意JavaScript：

// 恶意查询
db.users.find({ 
  $where: "this.password.match(/password/) && this.email.match(/@example.com/)" 
})

此查询会返回所有密码包含”password”且邮箱为example.com的用户记录。

二、NoSQL注入攻击手法详解

2.1 MongoDB注入技术

2.1.1 操作符注入

MongoDB支持$eq、$ne、$in等操作符，攻击者可利用这些操作符构造逻辑陷阱：

// 正常查询
db.products.find({ price: { $gt: 100 } })
// 恶意注入（绕过价格限制）
db.products.find({ 
  price: { $gt: 100 }, 
  $or: [{ discount: { $exists: true } }, { stock: { $lt: 0 } }] 
})

通过$or注入，攻击者可获取本应被过滤的库存为负或存在折扣的商品。

2.1.2 JavaScript注入

MongoDB的$where操作符允许执行JavaScript表达式，成为攻击重灾区：

// 恶意代码注入
db.users.find({ 
  $where: "function() { 
    require('child_process').exec('rm -rf /'); 
    return true; 
  }" 
})

此攻击若成功执行，将导致服务器文件系统被删除（需数据库配置允许JavaScript执行）。

2.2 Redis注入技术

Redis的键名拼接特性常被利用：

# 正常命令
SET user:1:name "Alice"
# 恶意注入（通过空格绕过）
SET user:1:name "Alice\nSET global:admin true"

攻击者通过换行符注入额外命令，可能提升权限或篡改全局配置。

三、防御策略与最佳实践

3.1 输入验证与过滤

3.1.1 白名单校验

对所有用户输入实施严格的白名单规则：

// Node.js示例：验证用户ID是否为数字
function isValidUserId(id) {
  return /^\d+$/.test(id);
}
if (!isValidUserId(req.params.id)) {
  throw new Error("Invalid user ID");
}

3.1.2 类型转换

强制转换输入类型，避免字符串拼接：

// MongoDB示例：使用ObjectId而非字符串
const { ObjectId } = require('mongodb');
const userId = new ObjectId(req.params.id); // 自动校验格式

3.2 参数化查询

3.2.1 MongoDB官方驱动

使用MongoDB Node.js Driver的参数化API：

const collection = db.collection('users');
collection.findOne({ 
  _id: new ObjectId(req.params.id),
  password: req.body.password // 密码需单独校验
});

3.2.2 Redis安全实践

避免直接拼接用户输入到命令中：

// 使用redis-client的参数化方法
const client = createRedisClient();
client.set(`user:${req.params.id}:name`, "Alice"); // 仍需校验id格式

3.3 最小权限原则

3.3.1 数据库用户权限

为应用分配最小必要权限：

# MongoDB示例：仅授予查询权限
db.grantRolesToUser("appUser", [{ role: "read", db: "appDB" }]);

3.3.2 禁用危险操作

在MongoDB配置中禁用JavaScript执行：

# mongod.conf配置
security:
  javascriptEnabled: false

3.4 安全编码规范

3.4.1 框架选择

优先使用内置防护的ORM/ODM：

• Mongoose（MongoDB）：自动类型转换
• TypeORM：支持NoSQL与SQL数据库

3.4.2 日志与监控

记录所有数据库操作，设置异常查询告警：

// MongoDB中间件示例
app.use((req, res, next) => {
  const query = req.body.query;
  if (query && /\$where|\$function/i.test(JSON.stringify(query))) {
    logAlert("Potential NoSQL injection detected", { ip: req.ip, query });
  }
  next();
});

四、企业级防护方案

4.1 WAF扩展规则

配置Web应用防火墙（WAF）拦截NoSQL特征攻击：

• 检测$where、$function等操作符
• 拦截包含require(、child_process的JavaScript代码

4.2 数据库防火墙

部署数据库防火墙（如MongoDB Atlas的Network Access Rules）：

• 限制IP访问范围
• 启用审计日志记录所有查询

4.3 定期安全测试

4.3.1 自动化扫描

使用工具如nosql-injection-scanner进行测试：

# 示例命令
nosql-scanner --url "http://api.example.com/users" --payloads "payloads.json"

4.3.2 渗透测试

模拟攻击者手法验证防护效果：

1. 尝试注入$gt、$ne等操作符
2. 测试$where执行能力
3. 验证权限隔离是否生效

五、未来趋势与挑战

5.1 云原生环境下的防护

随着Serverless和容器化部署的普及，NoSQL注入攻击可能通过环境变量注入：

# 恶意Kubernetes配置
env:
- name: MONGO_URI
  value: "mongodb://attacker:pass@malicious-host/db?authSource=admin&$where=1"

需加强配置校验和运行时监控。

5.2 AI生成的攻击代码

未来攻击者可能利用AI生成更复杂的注入代码，防御需结合：

• 行为分析（如查询频率异常检测）
• 语义分析（识别恶意JavaScript模式）

六、总结与行动建议

1. 立即行动：检查所有NoSQL查询是否使用参数化API
2. 中期优化：部署WAF规则并配置数据库最小权限
3. 长期规划：将安全测试纳入CI/CD流程，定期更新防护策略

NoSQL注入的防御需要开发者、安全团队和运维人员的协同努力。通过实施本文提出的分层防护体系，可显著降低攻击风险，保障数据安全。