使用mysql-connector-python调用存储过程是否存在SQL注入风险？

核心结论 #

用cursor.callproc()配合参数化方式调用存储过程，在你当前的使用场景下不存在SQL注入风险，其安全机制和预编译语句完全一致。

安全原理 #

mysql-connector-python的callproc()方法会将传入的args参数作为参数化绑定值处理，不会直接将用户输入拼接到SQL执行逻辑中。MySQL存储过程接收参数时，会把参数当作纯数据而非可执行的SQL代码解析，这就从根源上阻断了注入攻击的可能性。

结合你的测试结果分析 #

你使用的' or 1=1 -- 、" or 1=1 -- 这类注入payload之所以未生效，是因为这些字符串被完整转义后作为arg_test的取值传入存储过程。比如实际执行的查询条件是WHERE test = '\\' or 1=1 -- '（单引号被转义），而非直接拼接成WHERE test = '' or 1=1 -- '，因此无法绕过原有的条件判断。

需要警惕的例外情况 #

如果你的存储过程内部自行拼接动态SQL（比如使用CONCAT拼接SQL字符串，再通过PREPARE/EXECUTE执行），即使外部用callproc()传参，仍会存在注入风险。例如以下不安全的存储过程：

DELIMITER //
CREATE PROCEDURE UnsafeProcedure(IN arg_test VARCHAR(150))
  BEGIN
    SET @dynamic_sql = CONCAT('SELECT * FROM Random_Table WHERE test = ', arg_test);
    PREPARE stmt FROM @dynamic_sql;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
  END //
DELIMITER ;

这种场景下，存储过程内部会把参数当作SQL代码的一部分解析，注入payload就会生效。

最终建议 #

只要你的存储过程直接使用传入参数作为查询条件（不拼接动态SQL），同时始终通过cursor.callproc(proc_name, args=())的参数化方式传递用户输入，就能完全避免SQL注入风险。

内容的提问来源于stack exchange，提问作者BooRuleDie