Spring Data MongoDB查询方法注入风险防范

Spring Data MongoDB 通过方法名推导查询语句的机制，是提升开发效率的利器，但也是注入风险的温床。很多人以为 MongoDB 作为 NoSQL 数据库，天然免疫 SQL 注入那套攻击，这种认知极其危险。实际上，当你在 Repository 接口中写下 findByUsername(String username) 这样的方法时，如果参数未经处理就进入查询推导链路，攻击者完全可以通过构造恶意参数实现 NoSQL 注入，轻则绕过认证逻辑，重则导致数据泄露甚至拖库。

Spring Data MongoDB 的方法名解析机制，本质上是将方法名按照特定规则拆解成查询条件树，然后将参数值填充进去。这个过程看似安全，但问题出在参数值的处理上。当你的方法参数是字符串类型，且业务代码直接将该参数传入时，攻击者可以注入 MongoDB 的操作符。举个例子，假设你有一个根据用户名查找用户的方法：

public interface UserRepository extends MongoRepository<User, String> {
    User findByUsername(String username);
}

正常情况下，调用 findByUsername("john") 会生成查询条件 {"username": "john"}。但如果攻击者传入的参数是 {"$ne": null} 这个 JSON 字符串，而你的代码恰好使用了某些会解析 JSON 字符串的查询机制，或者参数本身被当作对象处理，那么查询条件就可能变成 {"username": {"$ne": null}}，这会匹配所有用户名不为 null 的记录，导致返回非预期的数据。更危险的是，如果攻击者传入 {"$gt": ""}，配合正则或者其他操作符，就能遍历整个集合的数据。

Spring Data MongoDB 在参数绑定时，对于普通字符串类型参数，框架会将其作为字面值处理，不会解析其中的操作符。这是框架层面的基础防护。但问题在于，很多开发者会在方法参数中使用 org.bson.Document 或者 com.mongodb.BasicDBObject 这类对象类型，这时候框架就不会做任何转义处理，直接将对象内容合并到查询条件中。比如下面这个写法就存在高风险：

@Query("{ 'username': ?0 }")
User findByUsername(Document username);

调用方如果构造一个 Document 对象，内部包含 {"$ne": null}，查询条件就会被污染。更隐蔽的情况是，当你的方法参数是 Map 类型或者自定义对象时，Spring Data MongoDB 的查询构造器会递归处理嵌套结构，攻击者可以在多层嵌套中埋入操作符，绕过简单的字符串过滤逻辑。

使用 @Query 注解编写自定义查询时，风险更加直接。很多开发者习惯用字符串拼接的方式构建查询条件，比如：

@Query("{ 'username': '" + username + "' }")
User findByUsername(String username);

这种写法等于把查询条件的控制权完全交给了调用方。攻击者传入的 username 值如果是 ' || '1'=='1，虽然 MongoDB 的查询语法和 SQL 不同，但攻击者可以闭合引号后追加新的查询条件。更实际的攻击手法是传入 {$gt: ''}，配合闭合技巧，构造出能够遍历数据的查询语句。正确的做法是使用参数占位符，让框架来处理参数绑定：

@Query("{ 'username': ?0 }")
User findByUsername(String username);

这样框架会将 username 参数作为字面值处理，不会解析其中的操作符。但即使使用了占位符，如果参数类型是 Document 或 Map，框架依然会递归解析其内部结构，所以参数类型的约束同样重要。

很多项目会使用 Criteria 类来动态构建查询条件，这种方式的灵活性最高，但风险也最大。因为 Criteria 的 API 设计本身就支持操作符，开发者很容易在不经意间将用户输入直接作为操作符使用。比如下面这段代码：

String operator = request.getParameter("operator");
String value = request.getParameter("value");
Criteria criteria = Criteria.where("age").is(new Document(operator, value));

攻击者通过控制 operator 参数，可以传入 $regex、$where 等高危操作符。$where 操作符尤其危险，它允许执行 JavaScript 代码，攻击者可以注入任意的 JavaScript 表达式来执行服务端代码。虽然 MongoDB 对 $where 的执行有沙箱限制，但信息泄露和拒绝服务的风险依然存在。正确的做法是建立操作符白名单，严格限制允许使用的操作符集合：

private static final Set<String> ALLOWED_OPERATORS = Set.of("$gt", "$gte", "$lt", "$lte", "$eq");

public Criteria buildSafeCriteria(String operator, String value) {
    if (operator == null || !ALLOWED_OPERATORS.contains(operator)) {
        throw new IllegalArgumentException("Invalid operator");
    }
    return Criteria.where("age").is(new Document(operator, value));
}

MongoDB 的全文搜索和正则表达式功能是注入攻击的高发区。很多开发者为了快速实现模糊搜索，直接将用户输入拼接到正则表达式中：

@Query("{ 'title': { $regex: ?0 } }")
List<Article> findByTitleRegex(String regex);

攻击者可以传入精心构造的正则表达式来触发 ReDoS 攻击，也就是正则表达式拒绝服务。比如传入 (a+)+b 这样的恶意模式，会导致正则引擎回溯次数呈指数级增长，耗尽 CPU 资源。正确的做法是对用户输入进行转义，去除正则特殊字符，或者使用文本索引配合 $text 操作符来替代正则搜索。如果业务必须使用正则，至少要对输入长度和复杂度进行限制：

public String sanitizeRegex(String input) {
    if (input.length() > 100) {
        throw new IllegalArgumentException("Regex pattern too long");
    }
    return Pattern.quote(input);
}

单靠代码层面的修复不足以彻底防范注入风险，需要建立多层防护体系。第一层是输入验证，在 Controller 层就对所有用户输入进行严格的类型校验和格式检查。对于字符串参数，使用 @Pattern 注解限制字符集；对于数值参数，使用 @Min 和 @Max 限制范围。第二层是业务逻辑层的参数清洗，根据业务场景对查询参数进行二次过滤，剔除可能被利用的特殊字符和操作符。第三层是数据访问层的类型约束，Repository 方法的参数尽量使用明确的字符串、数值等基础类型，避免使用 Document、Map 等可嵌套的复杂类型。第四层是数据库权限控制，为应用账号分配最小必要权限，禁用或限制 $where、$eval 等高危操作符的执行权限。MongoDB 从 4.2 版本开始支持字段级权限控制，可以进一步限制应用账号只能访问特定字段。

即使防护措施到位，也需要建立完善的监控机制来及时发现攻击行为。在数据访问层增加审计切面，记录所有查询操作的原始参数和执行时间。对于包含 $where、$regex 等敏感操作符的查询，记录警告日志并触发告警。监控查询执行时间，如果某个查询的耗时突然从毫秒级飙升到秒级，很可能是正则注入或者数据遍历攻击的征兆。建立异常查询模式库，对短时间内大量返回不同记录的查询行为进行限流和阻断。这些监控数据不仅能帮助发现攻击，还能为后续的安全策略优化提供依据。

Spring Data MongoDB 的维护团队一直在修复安全相关的问题，保持框架版本更新是基础的安全实践；

2.x 版本中存在的某些参数绑定绕过漏洞，在 3.x 和 4.x 版本中已经修复。如果你的项目还在使用老版本，升级的优先级应该提到最高。同时要关注 Spring 官方的安全公告，及时应用安全补丁。在依赖管理上，使用 BOM 来统一管理 Spring 生态的版本，避免因为依赖冲突导致部分组件停留在有漏洞的老版本上。

技术手段最终要靠人来执行，建立团队级别的安全编码规范比任何工具都重要。规范中要明确禁止在 @Query 注解中使用字符串拼接，禁止 Repository 方法使用 Document 或 Map 作为参数类型，禁止直接将用户输入作为正则表达式或操作符使用。代码审查时要重点关注数据访问层的代码，对于任何涉及用户输入的查询构建逻辑都要仔细检查。定期进行安全培训，让团队成员了解 NoSQL 注入的原理和危害，而不仅仅是知道规则。引入静态代码分析工具，比如 SonarQube 配合自定义规则，自动扫描潜在的注入风险点，将安全检查前置到开发阶段。

Spring Data MongoDB 的查询方法注入风险，本质上不是框架的缺陷，而是开发者对 NoSQL 注入缺乏认知，以及编码习惯不够严谨导致的。理解了注入的原理，建立了多层防护体系，配合持续的监控和规范的编码实践，这类风险完全可以控制在可接受范围内。安全是一个持续的过程，而不是一次性的修复工作。