NoSQL 注入的成因
NoSQL 数据库的查询条件常用文档结构表达，如果服务端把请求体里的值直接当查询条件解析，而不是先做类型校验，就会出现类型混淆：原本应该是字符串的字段被替换成对象或数组后，查询运算符被一并携带进去，条件被改写，返回结果因此偏离预期。验证的目标是确认条件是否被改写，而不是导出数据。
基本信息
| 典型场景 | JSON 请求体中字段类型被改写，字符串变成对象或数组 |
|---|---|
| 常见入口 | 登录、筛选、搜索、批量查询接口 |
| 判定信号 | 返回结果与预期不符，或出现异常记录 |
| 验证边界 | 只确认条件是否被改写，不导出数据 |
| 记录要求 | 接口、字段名、类型改写现象与对照请求结果 |
典型使用场景
- 登录接口的用户名字段类型校验
- 列表筛选接口的条件字段类型校验
- 搜索接口的关键词与范围字段处理
- 批量查询接口的标识数组处理
- 接口文档中标注接受任意类型参数的字段
验证清单
验证清单
# 1. 找出接收 JSON 且直接进入查询的接口（登录、筛选、搜索）
# 2. 将某字符串字段改为对象结构提交，观察逻辑是否被改变
# 3. 同时发送一次常规请求做对照，排除业务规则本身的影响
# 4. 记录接口、字段名、类型改写现象（不记录可用条件组合）
# 5. 疑似成立即停止；使用测试账号操作，便于清理与复核结果读法
| 结果 | 含义 | 定级参考 |
|---|---|---|
| 返回记录超出预期 | 查询条件被改写 | 中高，取决于可读数据范围 |
| 校验错误提示 | 存在类型校验 | 正常，记录为已校验 |
| 接口异常报错 | 类型不匹配导致查询失败 | 低到中，属健壮性问题 |
| 结果与常规请求一致 | 条件未被改写 | 正常，标注未复现 |
修复视角：对入参做严格类型校验（该是字符串就必须是字符串），并在数据库层限制应用账号的集合访问权限。
验证只在测试账号与测试数据范围内进行，不要用改写后的条件读取真实用户的业务数据。