如何修复MySQL存储过程中的SQL注入漏洞-mysql教程-PHP中文网

mysql存储过程并非sql注入免疫区，使用concat()拼接用户输入或prepare+execute执行动态sql仍会引发注入；安全做法是：值用execute ... using绑定参数，表名/列名等语法元素须严格白名单校验。

如何修复mysql存储过程中的sql注入漏洞

MySQL存储过程中为什么还会存在SQL注入

存储过程本身不是“免疫区”——只要里面用了 CONCAT() 或 EXECUTE IMMEDIATE（在 MySQL 中是 PREPARE + EXECUTE）拼接用户输入，就可能被注入。常见错误是：把前端传进来的参数直接拼进动态 SQL 字符串里，再执行。

典型危险写法：

DELIMITER $$
CREATE PROCEDURE get_user_by_name(IN p_name VARCHAR(50))
BEGIN
  SET @sql = CONCAT('SELECT * FROM users WHERE username = ''', p_name, '''');
  PREPARE stmt FROM @sql;
  EXECUTE stmt;
  DEALLOCATE PREPARE stmt;
END$$
DELIMITER ;

攻击者调用 CALL get_user_by_name('admin'' OR ''1''=''1'); 就能绕过条件，查出所有用户。

用参数化方式重写动态 SQL（MySQL 8.0+ 支持）

MySQL 8.0.13 起，EXECUTE ... USING 支持绑定变量，这是唯一真正安全的动态 SQL 方式。必须把用户输入作为参数传入，而不是拼进字符串。

把 CONCAT() 拼接整条 SQL 的逻辑全部删掉
只对固定结构部分使用字符串拼接（如表名、字段名），且这些值必须来自白名单或严格校验
所有用户可控内容（如查询条件值）一律通过 USING 绑定

安全改写示例：

DELIMITER $$
CREATE PROCEDURE get_user_by_name(IN p_name VARCHAR(50))
BEGIN
  SET @sql = 'SELECT * FROM users WHERE username = ?';
  PREPARE stmt FROM @sql;
  EXECUTE stmt USING p_name;  -- ← 关键：这里传参，不是拼接
  DEALLOCATE PREPARE stmt;
END$$
DELIMITER ;

注意：? 占位符只能替代**值**，不能替代表名、列名、排序方向（ASC/DESC）等语法结构。这些若需动态，必须额外做白名单校验。