如何应对SQL注入威胁_使用存储过程封装查询降低风险-SQL-PHP中文网

存储过程不能自动防止sql注入，关键在于是否安全编写；若内部拼接用户输入（如mysql用concat），仍会中招，必须使用参数化方式（如prepare+execute配合using）或静态sql。

如何应对sql注入威胁_使用存储过程封装查询降低风险

存储过程真能防SQL注入？先看它怎么失效

不能自动防，关键在怎么写。存储过程只是把 SQL 逻辑移到数据库端执行，如果内部拼接了用户输入，照样中招。常见错误是用 CONCAT 或 + 拼接参数进查询字符串，比如在 MySQL 里写 SET @sql = CONCAT('SELECT * FROM users WHERE name = ''', in_name, ''''); —— 这和应用层字符串拼接没区别，in_name 传入 ' OR 1=1 -- 就直接穿透。

必须用参数化方式执行动态 SQL：MySQL 用 PREPARE + EXECUTE 配合 USING；SQL Server 用 sp_executesql 并显式声明参数
静态 SQL（不拼接）天然安全：直接写 WHERE username = @username，数据库会把参数当值处理，不会解析为语法
别信“存储过程+权限收紧=万无一失”，如果账号有 EXECUTE 权限且过程本身不设防，攻击面还在

MySQL 存储过程中安全传参的写法

MySQL 对参数化支持较弱，尤其动态查询场景。核心原则：不用字符串拼接，改用占位符 + USING。

CREATE PROCEDURE search_user(IN p_name VARCHAR(50))
BEGIN
  SET @sql = 'SELECT id, email FROM users WHERE name = ?';
  PREPARE stmt FROM @sql;
  EXECUTE stmt USING p_name;
  DEALLOCATE PREPARE stmt;
END

? 是唯一合法占位符，不能写成 '?' 或拼进字符串里
USING 后只能跟变量名，不能是表达式或函数调用（如 USING UPPER(p_name) 会报错）
每次 EXECUTE 前必须 PREPARE，但别在循环里反复 PREPARE/DEALLOCATE，性能差；可考虑复用语句句柄或改用静态 SQL

SQL Server 存储过程里最常踩的坑

sp_executesql 是安全底线，但很多人只用对了一半。典型错误：把参数名硬编码进 SQL 字符串，或者漏写参数类型。

-- ❌ 错误：参数名被当成字面量，实际未绑定
EXEC sp_executesql N'SELECT * FROM orders WHERE status = @status',
                   N'@status VARCHAR(20)',
                   @status = 'shipped';
<p>-- ✅ 正确：参数名、类型、值三者严格对应
DECLARE @sql NVARCHAR(200) = N'SELECT * FROM orders WHERE status = @status';
DECLARE @params NVARCHAR(50) = N'@status VARCHAR(20)';
EXEC sp_executesql @sql, @params, @status = 'shipped';</p>