85

我一直在向我的同事和这里宣讲在 SQL 查询中使用参数的好处，尤其是在 .NET 应用程序中。我什至承诺他们会提供对 SQL 注入攻击的免疫力。

但我开始怀疑这是否真的是真的。是否有任何已知的 SQL 注入攻击可以成功针对参数化查询？例如，您可以发送一个导致服务器缓冲区溢出的字符串吗？

当然，还有其他考虑因素可以确保 Web 应用程序是安全的（比如清理用户输入和所有这些东西），但现在我正在考虑 SQL 注入。我对针对 MsSQL 2005 和 2008 的攻击特别感兴趣，因为它们是我的主数据库，但所有数据库都很有趣。

编辑：澄清我所说的参数和参数化查询的意思。通过使用参数，我的意思是使用“变量”而不是在字符串中构建 sql 查询。
所以不要这样做：

SELECT * FROM Table WHERE Name = 'a name'

我们这样做：

SELECT * FROM Table WHERE Name = @Name

然后在查询/命令对象上设置@Name 参数的值。

4

9 回答 9

50

占位符足以防止注射。您可能仍然对缓冲区溢出持开放态度，但这是与 SQL 注入完全不同的攻击方式（攻击向量不是 SQL 语法，而是二进制）。由于传递的参数都将被正确转义，因此攻击者无法传递将被视为“实时”SQL 的数据。

您不能在占位符中使用函数，也不能将占位符用作列名或表名，因为它们被转义并引用为字符串文字。

但是，如果您在动态查询中使用参数作为字符串连接的一部分，您仍然容易受到注入的影响，因为您的字符串不会被转义，而是文字。使用其他类型的参数（例如整数）是安全的。

也就是说，如果您使用 use 输入来设置类似 的值security_level，那么有人可以让自己成为您系统中的管理员，并且可以免费使用。但这只是基本的输入验证，与 SQL 注入无关。

于 2008-11-20T20:09:16.103 回答
13

不，当您将未经验证的数据插入 SQL 查询时，仍然存在 SQL 注入的风险。

查询参数通过将文字值与 SQL 语法分开来帮助避免这种风险。

'SELECT * FROM mytable WHERE colname = ?'

这很好，但是将数据插入到不能使用查询参数的动态 SQL 查询中还有其他用途，因为它不是 SQL 值，而是表名、列名、表达式或其他一些语法。

'SELECT * FROM ' + @tablename + ' WHERE colname IN (' + @comma_list + ')'
' ORDER BY ' + @colname'

无论您是使用存储过程还是直接从应用程序代码执行动态 SQL 查询，都没有关系。风险依然存在。

在这些情况下，补救措施是根据需要使用FIEO：

  • 过滤输入：在插入数据之前验证数据看起来像合法的整数、表名、列名等。

  • 转义输出：在这种情况下，“输出”意味着将数据放入 SQL 查询中。我们使用函数来转换在 SQL 表达式中用作字符串文字的变量，以便对字符串中的引号和其他特殊字符进行转义。我们还应该使用函数来转换将用作表名、列名等的变量。至于其他语法，例如动态编写整个 SQL 表达式，这是一个更复杂的问题。

于 2008-11-20T20:48:58.490 回答
12

这个线程似乎对“参数化查询”的定义有些混淆。

  • SQL，例如接受参数的存储过程。
  • 使用 DBMS 参数集合调用的 SQL。

鉴于前一个定义，许多链接显示有效的攻击。

但“正常”的定义是后一种。鉴于该定义，我不知道任何有效的 SQL 注入攻击。这并不意味着没有，但我还没有看到它。

从评论中，我表达得不够清楚，所以这里有一个希望更清楚的例子：

这种方法对SQL 注入开放

exec dbo.MyStoredProc 'DodgyText'

这种方法不对SQL 注入开放

using (SqlCommand cmd = new SqlCommand("dbo.MyStoredProc", testConnection))
{
    cmd.CommandType = CommandType.StoredProcedure;
    SqlParameter newParam = new SqlParameter(paramName, SqlDbType.Varchar);
    newParam.Value = "DodgyText";
    .....
    cmd.Parameters.Add(newParam);
    .....
    cmd.ExecuteNonQuery();
}
于 2008-11-20T21:49:32.720 回答
10

任何用于构造动态查询的字符串类型（varchar、nvarchar 等）的 sql 参数仍然容易受到攻击

否则参数类型转换（例如到 int、decimal、date 等）应该消除通过参数注入 sql 的任何尝试

编辑：一个例子，其中参数@p1 是一个表名

create procedure dbo.uspBeAfraidBeVeryAfraid ( @p1 varchar(64) ) 
AS
    SET NOCOUNT ON
    declare @sql varchar(512)
    set @sql = 'select * from ' + @p1
    exec(@sql)
GO

如果从下拉列表中选择@p1，则它是潜在的 sql 注入攻击向量；

如果@p1 以编程方式制定而没有用户干预的能力，那么它不是潜在的 sql 注入攻击向量

于 2008-11-20T20:09:25.743 回答
6

缓冲区溢出不是 SQL 注入。

参数化查询保证您可以安全地抵御 SQL 注入。他们不保证您的 SQL 服务器中不存在漏洞形式的漏洞，但没有任何东西可以保证这一点。

于 2008-11-20T20:10:14.260 回答
2

如果您以任何形式或形式使用动态 sql，您的数据是不安全的，因为权限必须在表级别。是的，您已经限制了来自该特定查询的注入攻击的类型和数量，但不限制用户在找到进入系统的方法时可以获得的访问权限，并且您完全可以让内部用户访问他们不应该访问的内容以进行欺诈或窃取个人信息进行出售。任何类型的动态 SQL 都是危险的做法。如果您使用非动态存储过程，您可以在过程级别设置权限，除了过程定义的内容（当然系统管理员除外）之外，没有用户可以做任何事情。

于 2008-11-20T20:28:31.620 回答
1

存储过程可能会通过溢出/截断容易受到特殊类型的 SQL 注入的影响，请参阅：此处的数据截断启用注入：

http://msdn.microsoft.com/en-us/library/ms161953.aspx

于 2008-11-20T20:15:15.577 回答
1

请记住，使用参数您可以轻松存储字符串，或者如果您没有任何策略，则说用户名，"); drop table users; --"

这本身不会造成任何伤害，但您最好知道该日期在您的应用程序中进一步使用的位置和方式（例如，存储在 cookie 中，稍后检索以执行其他操作。

于 2009-07-22T00:32:49.860 回答
1

您可以运行动态 sql 作为示例

DECLARE @SQL NVARCHAR(4000);
DECLARE @ParameterDefinition NVARCHAR(4000);

SELECT  @ParameterDefinition = '@date varchar(10)'

SET @SQL='Select CAST(@date AS DATETIME) Date'

EXEC sp_executeSQL @SQL,@ParameterDefinition,@date='04/15/2011'
于 2011-04-12T14:47:07.523 回答