如何防止SQL子查询引发注入风险-SQL-PHP中文网

子查询参数化必须独立处理，否则存在sql注入风险；常见错误是仅对主查询使用preparedstatement而拼接子查询，或在mybatis中误用${}导致绕过#{}防护；正确做法是将子查询也参数化或使用预编译集合参数。

如何防止sql子查询引发注入风险

子查询参数化必须独立处理

子查询本身不是安全漏洞，但一旦用字符串拼接方式嵌入外部输入，就和主查询一样危险。常见错误是只对主SQL用了PreparedStatement，却把子查询当“静态结构”直接拼进去。

比如 Java 中这样写就是高危的：

String subQuery = "SELECT id FROM logs WHERE ip = '" + userInputIp + "'";
String sql = "SELECT * FROM users WHERE id IN (" + subQuery + ")";
// 即使外层用 PreparedStatement，subQuery 已经被污染

子查询中的 userInputIp 没经过任何绑定，单引号、括号、分号全可逃逸
数据库执行时会先解析整个字符串，PreparedStatement 的占位符机制对拼进去的子串完全无效
尤其在 MySQL 中，子查询支持多语句（如 ; 分隔），堆叠注入风险比主查询更高

MyBatis 里 #{} 不自动保护子查询

很多人误以为 MyBatis 的 #{} 能兜住所有 SQL 片段，其实它只作用于该占位符所在位置——如果子查询是通过字符串拼接到 SQL 模板里的，#{} 就不生效。

错误示范：

<select id="getUserByLogIp" resulttype="User">
  SELECT * FROM users 
  WHERE id IN (
    SELECT user_id FROM logs WHERE ip = '${ip}'  <!-- 这里用 ${} 直接拼接，危险！-->
  )
</select>

${} 是字符串替换，等同于 Java 的 + 拼接，' OR '1'='1 会原样进入子查询
即使主查询用 #{} ，子查询里用了 ${}，整条语句仍不可信
正确做法是把子查询也改造成独立的参数化语句，或用 <foreach></foreach> 配合预编译集合参数

存储过程调用子查询时权限要收敛

用存储过程封装子查询看似安全，但如果过程内部用了动态 SQL（如 CONCAT() 或 EXECUTE IMMEDIATE），且参数未校验，照样会中招。

MySQL 存储过程中典型陷阱：

DELIMITER //
CREATE PROCEDURE GetUserByIp(IN ip_input VARCHAR(45))
BEGIN
  SET @sql = CONCAT("SELECT * FROM users WHERE id IN (
    SELECT user_id FROM logs WHERE ip = '", ip_input, "')");
  PREPARE stmt FROM @sql;
  EXECUTE stmt;
  DEALLOCATE PREPARE stmt;
END //
DELIMITER ;