Can a SQL Injection attack be executed through anything other than SqlCommand?

Question

If I have an ASP.NET web application that has a SQL Server database, is it safe to assume that if a SQL Injection attack is going to be made it will pass through an instance of the SqlCommand class?

Background:

I am in a situation where I inherited a rather large web application that has some SQL Injection vulnerabilities. I have found several just by looking through the code for other issues, but I'm wondering if a safe way to find all SQL Injection vulnerabilities would be to search all files for instances of SqlCommand and then check to see if they are parametrized queries. Is this a solid plan?

Answer 1

I wouldn't look just for SqlCommand specifically - the code could use DBCommand or IDbCommand. It could be wrapped in ORMs like EF, L2S or NHibernate (all offer some level of raw access). It could use something like "dapper" or simple.data. Or DataTable / DataAdapter. You might have code that uses legacy OLEDB or ADODB access. Heck, for all we know you could have written your own low-level TDS API.

So: it comes down to checking data access code, which could take many forms. If your departmental approach is "use SqlCommand directly", then that changes things.

Also: SQL injection isn't limited to .NET - you can, for example, create a SQL injection risk in a raw command text or stored procedure even if you parameterise, if the TSQL does any kind of concatenation to make dynamic SQL, to be invoked via EXEC. Note that sp_executesql can help with that.

Answer 2

Depending on your database schema you may also need to check for attacks in stored procs (assuming you're using stored procs). I have seen people use paramterised stored procedures in their code, but in the proc they just use EXEC to query:

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