JSON解析后直接拼SQL属高危行为,必须用预处理语句;表名、字段名、JSON路径、排序字段等动态部分须白名单校验;IN查询需动态占位符;DTO绑定不等于SQL安全。
json_decode 后直接拼 SQL 字符串,等于把数据库大门钥匙交给前端——无论字段值看着多“正常”,只要没走参数化查询,就是高危状态。
json_decode 后必须用预处理语句常见错误是:json_decode($json, true) 得到数组,再用 "INSERT INTO t (name) VALUES('".$row["name"]."')" 拼 SQL。一旦 $row["name"] 是 NASA's 或 admin' --,SQL 就崩,且可被注入。
正确做法:
PDO 或 MySQLi 的预处理:先 $stmt = $pdo->prepare("INSERT INTO t (name) VALUES (?)"),再 $stmt->execute([$row["name"]])
in_array($table_name, ["news", "users", "logs"], true)
mysql_real_escape_string 或 addslashes——它们依赖字符集,宽字节下形同虚设,且 PHP 7+ 已废弃#{},禁用 ${}
${} 是字符串硬替换,#{} 才走 PreparedStatement。哪怕你加了 @Valid 或 DTO 强类型绑定,只要用了 ${id},恶意输入照样进 SQL。
典型陷阱:
@Select("SELECT * FROM ${tableName} WHERE name = #{name}") —— ${tableName} 必须白名单校验,#{name} 才安全WHERE content->>'${path}' = #{value} —— ${path} 是 JSON 路径,必须限制为 Set.of("title", "author") 等固定值ORDER BY ${sortField} ${sortDir},两个变量都得完整匹配白名单条目,比如 "created_at DESC" 要整体在列表里,不能只校验字段名IN 查询必须动态占位符遇到 {"ids": [1,2,3]},绝不能写成 "id IN (" . implode(",", $ids) . ")",也不能用 ${ids} 拼接——这等于把攻击面直接暴露给数组长度和内容。
实操要点:
<foreach item="id" collection="filter.ids" open="id IN (" separator="," close=")">#{id}</foreach>
$placeholders = str_repeat('?,', count($ids) - 1) . '?'; $sql = "SELECT * FROM t WHERE id IN ($placeholders)"; $stmt = $pdo->prepare($sql); $stmt->execute($ids);
ANY(ARRAY[?]),参数必须传 PHP 数组,不是字符串;否则仍可能被绕过ObjectMapper.readValue(json, User.class) 能校验结构、类型、非空,但不会过滤内容。{"name": "admin'; DROP TABLE users; -- "} 反序列化后,user.getName() 还是那个字符串。
关键判断点:
"WHERE name = '" + user.getName() + "'",等于前功尽弃{"custom": {"field": "xxx"}})无法靠 DTO 绑定防护,字段名本身来自用户输入,必须白名单限制路径setString()、setLong() 等明确类型的 PreparedStatement 方法,不能图省事用 setObject()
真正容易被忽略的,是那些“看起来不危险”的地方:表名拼接、JSON 路径拼接、ORDER BY 动态字段、IN 列表构造——它们都不支持问号占位符,但开发者常误以为“反正没拼值,就没事”,结果成了注入入口。