JSON扩展字段SQL注入防御方法解析与参数绑定实践

首页

数据库

热心网友

转载

2026-05-08

# JSON字段解析后直接拼进SQL字符串，等于开门揖盗只要把解析出来的JSON值（比如 `user.get("name")`）用 `+` 或 `String.format()` 塞进SQL字符串里，就立刻回到高危状态。哪怕前面用了 `ObjectMapper.readValue()`、做了非空校验、甚至trim了空格，都拦不住 `' OR '1'='1` 这类输入。数据库只认语法，不认“你本意是不是想查数据”。 **常见错误现象**： - `MySQLSyntaxErrorException` 频发但SQL日志里看不出明显语法错 - 某次传 `{"status":"active' -- "}` 后查询返回全部记录 - 后台日志出现 `UNION SELECT` 或 `EXTRACTVALUE` 等报错注入特征 **必须遵守的铁律**： 1. 所有JSON解析结果（`JsonNode.asText()`、`Map.get()`、`object.field`）都必须视为不可信输入 2. 禁止对JSON字段做任何“看起来安全”的假设——比如认为status只能是active/inactive，就跳过参数化 3. 如果JSON结构固定，优先用Jackson的 `@JsonProperty` + POJO绑定，而非泛型 `Map` ## MyBatis中JSON字段必须用 `#{}`，禁用 `${}` `${}` 是字符串替换，JSON字段值进去就是裸奔；`#{}` 才走PreparedStatement预编译。哪怕字段名来自JSON，只要它是值（不是表名、排序字段），就必须走 `#{}`。 **使用场景**：用户提交 `{"filter":{"name":"admin","age":25}}`，后端解析后用于WHERE条件。 **正确写法**： ```sql WHERE name = #{filter.name} AND age = #{filter.age} ``` **错误写法**： ```sql WHERE name = '${filter.name}' # 单引号包着也无效 ``` **关键细节**： - 模糊查询要加 `concat('%', #{keyword}, '%')`，不能写成 `"%${keyword}%"` - 如果JSON里嵌套了数组（如 `{"ids":[1,2,3]}`），需转成 `IN (?, ?, ?)` 形式，用MyBatis的 `` 动态生成占位符 ## 动态字段名（如JSON中的 `sortField`）必须白名单硬校验 JSON里如果带 `{"sort":"email DESC"}` 这种字段，`ORDER BY ?` 会直接报错——预编译不支持结构参数。这时候不能妥协用 `String.format("ORDER BY %s", sort)`，得靠白名单+正则双保险。性能影响几乎为零，但漏掉一个字符就可能被绕过。 **白名单校验四步法**： 1. **定义明确白名单**：`Set.of("id", "name", "email", "created_at")` 2. **方向单独校验**：`if (!"ASC".equals(dir) && !"DESC".equals(dir)) throw new IllegalArgumentException();` 3. **完整匹配组合**：`"email DESC"` 必须整体在白名单中，不能只校验 `email` 部分 4. **拒绝特殊字符**：用 `sort.trim().replaceAll("\s+", " ")` 规范化后再比对，拒绝任何空白符、Unicode分隔符、不可见字符 ## JSON路径表达式也要参数化 MySQL 8.0+ 和 PostgreSQL 的 JSON 函数虽支持路径字符串，但路径本身若来自用户输入（比如前端传 `path: "$.settings.theme"`），仍可能被构造为 `"$.settings.theme' OR '1'='1"` 导致注入。路径不是值，但它是执行上下文的一部分。 **容易踩的坑**：以为JSON函数自动免疫，结果在 `WHERE JSON_EXTRACT(data, ?) = ?` 里只对右边的值参数化，左边路径没处理。 **防护措施**： - 路径字段必须走白名单：`if (!allowedPaths.contains(path)) throw ...` - 禁止拼接路径字符串：`"$.user." + userInput` 是典型错误 - PostgreSQL 的 `->>` 操作符同理，`json_col ->> ?` 不合法，必须先校验再硬编码 - 如果业务真需要动态路径，改用存储过程封装校验逻辑，应用层只传索引或枚举key ## 总结 JSON字段解析和SQL绑定之间那层薄薄的“信任”，是最容易被忽略的攻击面。参数化不是写了 `#{}` 就万事大吉，而是每个从JSON里掏出来的值，都要重新经历“是否可信→是否白名单→是否参数化”的三重判断。

来源:https://www.php.cn/faq/2414983.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：PostgreSQL中HSTORE类型数据的插入与键值对输入方法下一篇：MySQL 5.7 与 8.0 版本 JSON 功能及索引支持对比详解

相关攻略

编程语言

ThinkPHP JSON解析错误排查与编码转换解决方案

ThinkPHP处理JSON数据时，若报解析错误或返回空值，常因数据读取方式不当或编码问题。应使用`input( , ,false)`或`getInput()`直接获取原始数据，并检查UTF-8BOM、编码一致性及框架中间件干扰。混合提交场景需从`$_POST`手动解码。线上问题还需排查服务器配置对请求体的影响。

热心网友

05.07

数据库

SQL存储过程解析JSON参数使用JSON_VALUE函数详解

在SQLServer存储过程中使用JSON_VALUE函数解析JSON参数时，需确保参数声明为NVARCHAR(MAX)以避免Unicode字符问题。提取标量值要求路径精确匹配，中文键名需转义。解析前必须用ISJSON()函数校验输入字符串的合法性，防止静默失败。当需要提取多个或嵌套字段时，建议使用OPENJSON函数以提高代码可维护性和解析性能。

热心网友

05.07