参数真的足以防止Sql注入吗？

Question

我一直在向我的同事和其他人宣讲在SQL查询中使用参数的好处，特别是在.NET应用程序中。我甚至向他们承诺对SQL注入攻击具有免疫力。

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

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

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

因此，与其这样做：

SELECT * FROM Table WHERE Name = 'a name'

我们这样做：

SELECT * FROM Table WHERE Name = @Name

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

Answer 1

占位符足以防止注入。您可能仍然对缓冲区溢出敞开大门，但这是一种与SQL注入完全不同的攻击方式(攻击载体不是SQL语法，而是二进制)。由于传递的所有参数都将被正确转义，因此攻击者没有任何方法传递将被视为“活动”SQL的数据。

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

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

也就是说，如果您使用use input来设置security_level之类的值，那么某些人就可以让自己成为您系统中的管理员，这样就可以自由使用了。但这只是基本的输入验证，与SQL注入无关。

Answer 2

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

查询参数通过将文字值从SQL语法中分离出来，有助于避免这种风险。

'SELECT * FROM mytable WHERE colname = ?'

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

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

无论是使用存储过程还是直接从应用程序代码执行动态SQL查询，这都无关紧要。风险仍然存在。

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

SQL :在插入

• Filter输出之前，验证数据看起来像是合法的整数、表名、列名等。在本例中，“”表示将数据放入them.
• Escape查询中。我们使用函数来转换SQL表达式中用作字符串文字的变量，以便对字符串中的引号和其他特殊字符进行转义。我们还应该使用函数来转换变量，这些变量将用作表名、列名等。至于其他语法，比如动态编写整个SQL表达式，这是一个更复杂的问题。

Answer 3

在这个线程中似乎有一些关于“参数化查询”的定义的混淆。

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

根据前一种定义，许多链接显示了有效的攻击。

但“正常”的定义是后者。根据这个定义，我不知道有哪种SQL注入攻击可以奏效。这并不意味着没有一个，但我还没有看到它。

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

这种方法对SQL注入是开放的。

exec dbo.MyStoredProc 'DodgyText'

这种方法对注入不是开放的

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();
}