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

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

根据您的数据库架构,您可能还需要检查存储过程中的攻击(假设您正在使用存储过程).我看到人们在他们的代码中使用了paramterised存储过程,但是在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注入它将是有益的!