Question

我正在从用户那里获取文本输入，然后将其转换为 2 字符长度字符串（2-Grams）

例如

RX480变为

"rx","x4","48","80"

现在，如果我直接查询下面的服务器，他们可以以某种方式进行SQL注入吗？

select * 
from myTable 
where myVariable in ('rx', 'x4', '48', '80')

Answer 1

SQL注入不是长度问题。

当有人向现有查询添加代码时，就会发生这种情况。他们通过将恶意额外代码作为表单提交（或其他内容）发送来实现此目的。当您的SQL代码执行时，它没有意识到有多个事情要做。它只是执行它所说的。

您可以从简单的查询开始，例如：

select * 
from thisTable 
where something=$something

所以你最终可能得到一个看起来像这样的查询：

select * 
from thisTable 
where something=; DROP TABLE employees;

这是一个奇怪的例子。但它或多或少地表明它为何危险。第一个查询会失败，但是谁在乎呢？第二个实际上会起作用。如果你有一张名为“雇员”的桌子，那么你就不用了。

Answer 2

在这种情况下，两个字符足以在查询中出错并可能显示有关它的一些信息。例如，尝试使用字符串')480并观察应用程序的行为方式。

Answer 3

虽然答案不是很多，但这确实不符合评论。

您的代码会扫描一个表，检查列值是否与用户提供的字符串中的任何一对连续字符匹配。用另一种方式表达：

declare @SearchString as VarChar(10) = 'Voot';
select Buffer, case
  when DataLength( Buffer ) != 2 then 0 -- NB: Len() right trims.
  when PatIndex( '%' + Buffer + '%', @SearchString ) != 0 then 1
  else 0 end as Match
  from ( values
    ( 'vo' ), ( 'go' ), ( 'n ' ), ( 'po' ), ( 'et' ), ( 'ry' ),
    ( 'oo' ) ) as Samples( Buffer );

在这种情况下，您只需将@SearchString的值作为参数传递，避免出现IN子句。

或者，字符对可以作为表参数传递，并与IN一起使用：where Buffer in ( select CharacterPair from @CharacterPairs )。

就SQL注入而言，将文本限制为字符对确实无法添加完整的语句。正如其他人所指出的那样，它确实会破坏查询并导致查询失败。在我看来，这构成了一个问题。

我仍然试图想象一个用于这种相当奇怪的模式匹配的用例。它不会匹配比搜索字符串长两（或更短）的列值。

Answer 4

如果我有[某种特殊的数据处理方式]我的查询仍然容易受到攻击，那么肯定应该对所有这些无数的规范答案“的问题。

首先，你应该问问自己 - 你为什么要给自己买这样的放纵？是什么原因？为什么要为数据处理添加例外？为什么要将你的数据分成绵羊和山羊，告诉自己“这个数据是安全的”，我不会正确处理它并且数据不安全，我必须做点什么？

出现这样一个问题的唯一原因是您的应用程序架构。或者说，缺乏架构。因为只有在意大利面条代码中，用户输入直接添加到查询中，才会出现这样的问题。否则，您的数据库层应该能够处理任何类型的数据，完全不知道它的性质，来源或所谓的“安全”。

2个字符长度变量是否会导致SQL注入漏洞？

4 个答案: