在存储过程和MySQL注入中声明变量

我有这种情况，例如：

id       value
 1       data_1
 2       20
 3       data_3
 4       15
 5       data_4
 6       data_6

以及以下存储过程：

DELIMITER $$

CREATE PROCEDURE `test_2`.`test_procedure` (val int(9))
BEGIN

select * from `test` where `value` = val;

END

如果我这样叫程序

 call test_procedure(20);

我有以下结果：

id     value
 2     20

id       value
 1       data_1
 3       data_3
 5       data_4
 6       data_6

直到现在一切都很好

但我不能理解的是，当我这样调用程序时：

call test_procedure("abc");

我有以下结果：

id     value
 2     20

id       value
 1       data_1
 3       data_3
 5       data_4
 6       data_6

这是MySQL数据库的正常行为吗

如果我将变量“val”声明为整数，这是否会阻止MySQL注入

我希望有一个警告或其他东西告诉我输入值不是整数，并且过程停止，而不是显示表中所有非数字的值。

通常通过允许将任意用户数据插入查询字符串来实现。在这种情况下，

val

指的是一个值，而不是任意字符串。如果使用

CONCAT

编写查询，可能会遇到严重的问题。在这种情况下，看起来你没事

正如您所写的，即使

val

在某种程度上是

”；删除数据库数据库--

然后它将在字符串的基础上进行比较，而不是作为实际的内联字符串进行比较。这并不比在一个专栏中有这样的内容并对其进行比较更糟糕

---

您看到的可能是一个任意字符串在内部转换为

0

，因此您的

“abc”

与任何其他计算结果为

0

的字符串相匹配。至于奇怪的结果，可能是由于MySQL将

val

参数和

值

列转换为整数：

SELECT CAST("abc" AS SIGNED); -- returns 0
SELECT CAST("data_1" AS SIGNED); -- also returns 0

所以，如果在MySQL中将“abc”和“data_1”视为整数，它们是相等的。这只是一个理论，但似乎很合适

如果零恰好是

test.value

的无效值，则如果

val

为零，则可以在过程中引发异常。如果没有，你需要一些其他的解决方法

---

顺便说一句，我同意塔德曼的说法，这里没有注射威胁。

这种情况是否与以下语法几乎相同：“'abc'或1=1”，其中该语法的计算结果始终为true，结果将是表中的所有数据？在我的例子中，结果将是表中除数字之外的所有数据，并将信息提供给不必看到它们的人。也许这不是一个注入，但在我看来，这是一个严重的安全问题。你是对的，它与注入类似，它会给用户带来超出他们应该看到的内容。我有一个解决方案的想法；我很快会把它添加到我的答案中。塔德曼是对的。它的计算值为0。同样，这个查询（我测试它）给出了相同的结果：“选择*from

test

where

value

=0”；我认为解决方案是检查变量“val”是否不同于0，如果要继续sql查询，否则就停止。@Catalin-很抱歉延迟发布答案；出了点事。是的，如果0是

val

的无效值，那么您可以让过程检查0并抛出异常或不返回结果。你愿意这样做吗？当然，如果没有其他解决方法，我会检查值是否不等于0，我很高兴我发现了这一点，但我想了解为什么会发生这种情况。这是一个bug，或者是已知的、必须避免的东西？这是真的。它的计算值为0。我不明白为什么where子句“where value=0”给出了所有不是数字的记录。它不应该返回任何结果？值列中存储的所有数据都不等于0。由于字母字符被转换为0，因此可能最终为

其中CONVERT（value，SIGNED）=CONVERT（val，SIGNED）

，这是

其中0=0

。