Question

如果我有一个具有SQL Server数据库的ASP.NET Web应用程序，是否可以安全地假设如果要进行SQL注入攻击，它将通过SqlCommand类的实例？

背景：

我处于一种情况，我继承了一个相当大的Web应用程序，它有一些SQL注入漏洞。我找到了几个只是通过查看其他问题的代码，但我想知道找到所有SQL注入漏洞的安全方法是搜索所有文件的SqlCommand实例，然后检查它们是否是是参数化查询。这是一个可靠的计划吗？

Answer 1

我不会特别为SqlCommand看只是 - 代码可以使用DBCommand或IDbCommand。它可以包含在ORM中，如EF，L2S或NHibernate（都提供一定程度的原始访问）。它可以使用“dapper”或simple.data之类的东西。或者DataTable / DataAdapter。您可能拥有使用旧版OLEDB或ADODB访问的代码。哎呀，我们知道你可以编写自己的低级TDS API。

所以：它归结为检查数据访问代码，这可能采取多种形式。如果您的部门方法是“直接使用SqlCommand”，那么这会改变一切。

另外：SQL注入不仅限于.NET - 例如，您可以在原始命令文本或存储过程中创建SQL注入风险，即使您参数化，如果TSQL确实存在用于生成动态SQL的任何类型的串联，可通过EXEC调用。请注意，sp_executesql可以帮助解决这个问题。

Answer 2

根据您的数据库架构，您可能还需要检查存储过程中的攻击（假设您正在使用存储过程）。我看到人们在他们的代码中使用了参数化的存储过程，但是在proc中他们只是使用EXEC来查询：

CREATE PROC Dummy
(
   @Str VARCHAR(50)
)
AS
EXEC ('SELECT * FROM Table Where Column = ''' + @Str + '''')

Answer 3

您还需要查找使用或包含 SqlCommand的内容。其中包括SqlDataAdapter等。

Answer 4

仅仅因为您使用的是参数化查询库并不意味着它的使用正确。在审计代码时，我已经看到了使用参数化quires的情况，但查询的某些部分仍然使用字符串连接构建。更具体地说，表名和查询的限制/顺序部分是常见错误。

如果您完全参与静态分析，最好的办法是grep应用程序中的所有查询，然后确保每个查询都正确构建。是的，这需要很长时间，而且可能会让人头脑麻木。休息，做笔记并按下。当你发现sql注入它将是有益的！

SQL注入攻击是否可以通过SqlCommand以外的任何其他方式执行？

4 个答案: