是否有某种方法可以注入 SQL，即使' 角色被删除？

Question

如果我从 SQL 查询中删除所有 ' 字符，是否还有其他方法对数据库进行 SQL 注入攻击？

如何做呢？ 谁能给我举个例子吗？

Answer 1

我只能重复别人说过的话。 参数化 SQL 是正确的选择。 当然，编码起来有点痛苦——但是一旦你完成了一次，那么剪切和粘贴该代码并进行所需的修改并不困难。 我们有很多 .Net 应用程序，允许网站访问者指定整个范围的搜索条件，并且代码会动态构建 SQL Select 语句 - 但用户可能输入的所有内容都会进入参数。

Answer 2

当您需要数字参数时，您应该始终验证输入以确保它是数字。 除了帮助防止注入之外，验证步骤还将使应用程序更加用户友好。

如果您在预期 id = 1044 时收到 id = "hello"，那么最好向用户返回有用的错误，而不是让数据库返回错误。

Answer 3

就在这里。 摘自 维基百科

“SELECT * FROM data WHERE id = " + a_variable + "; "

从这个声明中可以清楚地看出，作者希望 a_variable 是与“id”字段相关的数字。 但是，如果它实际上是一个字符串，那么最终用户可以根据自己的选择操作该语句，从而绕过转义字符的需要。 例如，将 a_variable 设置为

1;DROP TABLE users

将从数据库中删除（删除）“users”表，因为 SQL 将呈现如下：

SELECT * FROM DATA WHERE id =1;DROP TABLE users;

SQL 注入不是一种简单的攻击。 如果我是你，我会非常仔细地研究。

Answer 4

是的，取决于您使用的语句。 您最好通过使用存储过程或至少参数化查询来保护自己。

有关预防示例，请参阅维基百科。

Answer 5

我建议您将变量作为参数传递，而不是构建自己的 SQL。 否则总会有一种方法可以进行 SQL 注入，而这种方式是我们目前不知道的。

您创建的代码类似于：

' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));

如果您的名字像我的一样，其中包含 '。 非常烦人的是，所有 '- 字符都被删除或标记为无效。

您可能还想查看有关 SQL 注入的 Stackoverflow 问题。

Answer 6

是的，这绝对是可能的。

如果您希望在下一个 SELECT 语句中使用整数，那么您可以输入类似的内容：

SELECT * FROM thingy WHERE attributeID=

• 5 （好答案，没问题）
• 5; 删除表用户； （糟糕、糟糕、糟糕...）

以下网站详细介绍了经典 SQL 注入技术： SQL 注入备忘单。

使用参数化查询或存储过程也好不到哪儿去。 这些只是使用传递的参数预先进行的查询，它们也可以作为注入源。 此页面上也对此进行了描述：攻击 SQL 中的存储过程。

现在，如果您抑制简单的引用，则只能阻止一组给定的攻击。 但不是全部。

一如既往，不要相信来自外部的数据。 在这 3 个级别上过滤它们：

• 界面级别用于明显的内容（下拉选择列表比自由文本字段更好）
• 逻辑级别用于与数据性质（整数、字符串、长度）、权限（这种类型的数据可以是该用户在此页面使用）...
• 数据库访问级别（转义简单引用...）。

玩得开心，别忘了查看维基百科来获取答案。

Answer 7

参数化内联 SQL 或参数化存储过程是保护自己的最佳方法。 正如其他人指出的那样，简单地剥离/转义单引号字符是不够的。

您会注意到我专门谈论“参数化”存储过程。 如果您恢复将过程传递的参数连接在一起，那么仅仅使用存储过程也是不够的。 换句话说，将完全相同的易受攻击的 SQL 语句包装在存储过程中并不会使其更安全。 您需要在存储过程中使用参数，就像使用内联 SQL 一样。

Answer 8

另外，即使您只是查找撇号，您也不想删除它。 你想逃避它。 您可以通过用两个撇号替换每个撇号来做到这一点。

但参数化查询/存储过程要好得多。

Answer 9

由于这是一个相对较旧的问题，我不会费心写一个完整而全面的答案，因为该答案的大部分方面已被一个或另一个海报在这里提到。
然而，我确实发现有必要提出另一个这里没有人涉及的问题——SQL 走私。 在某些情况下，即使您尝试删除引号字符 '，也有可能将其“走私”到您的查询中。 事实上，即使您使用了正确的命令、参数、存储过程等，这也是可能的。

查看完整的研究论文 http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf（披露，我是这方面的主要研究人员）或者只是谷歌“SQL Smuggling”。

Answer 10

。 。 。 呃，大约 50000000 种其他方式

可能类似于 5; 删除表员工； --

生成的 sql 可能类似于：
从 number = 5 的地方选择 *； 删除表员工； -- 和 Sadfsf

（-- 开始评论）

Answer 11

是的，绝对的：根据您的 SQL 方言等，有很多方法可以实现不使用撇号的注入。

针对 SQL 注入攻击的唯一可靠防御是使用数据库接口提供的参数化 SQL 语句支持。

Answer 12

我不会尝试找出要过滤掉的字符，而是坚持使用参数化查询，并完全消除问题。

Answer 13

这取决于您如何组合查询，但本质上是的。

例如，在 Java 中，如果您要这样做（故意的令人震惊的示例）：

 String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");

那么您很可能会遭受注入攻击。

Java 有一些有用的工具来防止这些问题，例如PreparedStatements（您可以在其中传递“SELECT name_ from Customer WHERE ID = ?”之类的字符串，并且 JDBC 层会在为您替换 ? 标记时处理转义），但也有一些其他语言对此没有太大帮助。

Answer 14

问题是撇号可能是真正的输入，当你在代码中使用内联 SQL 时，你必须通过将它们加倍来转义它们。 您正在寻找的是一个正则表达式模式，例如：

\;.*--\

用于提前结束真实语句的分号，一些注入的 SQL，后跟双连字符以注释掉原始真实语句中的尾部 SQL。 攻击中的连字符可以省略。

因此答案是：不，仅仅删除撇号并不能保证您免受 SQL 注入的影响。