通过 MySQL 连接器在存储过程中进行 SQL 注入

Question

我使用

mysql-connector-python

驱动程序来执行数据库操作。最近，我在 MySQL 中遇到了存储过程，并决定将我的一些 API 从使用

cursor.execute()

迁移到

cursor.callproc(proc_name, args=())

。事实证明，这一转变是成功的，一切都顺利进行。但是，我不确定这些存储过程是否存在 SQL 注入漏洞。

为了评估这一点，我创建了一个测试存储过程并检查了它对 SQL 注入有效负载的敏感性。

存储过程：

DELIMITER //
CREATE PROCEDURE TestProcedure(IN arg_test VARCHAR(150))
  BEGIN
    IF EXISTS (SELECT 1 FROM Random_Table WHERE test = arg_test) THEN
        SELECT 'success' AS message;
    ELSE
        SELECT 'failed' AS message;
    END IF;
  END //
DELIMITER ;

有效负载：

• ' or 1=1 -- 

• " or 1=1 -- 

令人惊讶的是，这些有效负载都没有产生任何成功的结果。为了寻求进一步的保证，我咨询了公司的一位数据库管理员。尽管他表示不确定，但他建议这些存储过程的功能与准备好的语句类似。这与我的观察结果一致，即

cursor.callproc()

方法通过

args

参数接受用户输入作为参数，类似于准备好的语句。

如果这种解释是准确的，则意味着使用

cursor.callproc()

方法可确保后端安全，免受 SQL 注入问题。尽管有这些积极的迹象，我想在这里寻求额外的确认，以保证这种方法的安全性。

Answer 1

像大多数人一样，你把事情搞混了。它造成了很多麻烦（和漏洞）。程序员应该始终严格定义自己的定义。

您所说的是在查询中使用 SQL 变量。当然，使用变量是完全安全的。您的

arg_test

是一个 SQL 变量。 SQL 将其视为变量，而不是 SQL 的一部分（从这个意义上来说，它确实类似于准备好的语句，但从技术上讲，这是完全不同的事情）。

你看，SQL 中没有

+

标志。这意味着 arg_test 被评估为变量，而不是将其内容包含在 SQL 正文中 - 这确实是 SQL 注入的原因。

说到存储过程，它们与注入无关。人们可以编写一个不受注入影响且易于注入的程序。就像任何其他代码一样。