20

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

背景：

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

4

4 回答 4

20

我不会专门寻找SqlCommand - 代码可以使用 DBCommand 或 IDbCommand。它可以封装在 EF、L2S 或 NHibernate 等 ORM 中（都提供某种级别的原始访问）。它可以使用“dapper”或 simple.data 之类的东西。或数据表/数据适配器。您可能有使用旧版 OLEDB 或 ADODB 访问的代码。哎呀，据我们所知，您可以编写自己的低级 TDS API。

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

此外：SQL 注入不限于 .NET - 例如，即使您参数化，您也可以在原始命令文本或存储过程中创建 SQL 注入风险，如果 TSQL 执行任何类型的连接以生成动态 SQL，则通过 EXEC 调用。请注意， sp_executesql 可以提供帮助。

于 2012-11-21T00:25:22.407 回答
10

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

CREATE PROC Dummy
(
   @Str VARCHAR(50)
)
AS
EXEC ('SELECT * FROM Table Where Column = ''' + @Str + '''')
于 2012-11-21T00:24:19.423 回答
8

您还需要寻找使用或包含SqlCommand. 其中包括SqlDataAdapter，等等。

于 2012-11-21T00:19:10.407 回答
7

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

如果您完全专注于静态分析，最好的办法是对应用程序中的所有查询进行 grep，然后确保每个查询都正确构建。是的，这将需要很长时间，而且可能会让人麻木。休息一下，做笔记，然后继续。当您发现 sql 注入时，它将获得回报！

于 2012-11-21T00:20:13.927 回答