Take the 2-minute tour ×

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?


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?

share|improve this question
add comment

4 Answers

up vote 20 down vote accepted

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.

share|improve this answer
That last bit is super important if you're talking over someone else's project. If there are sprocs you want to audit them thoroughly. Just because data is already in the db does not mean it's safe to concatenate into a sql command. –  Wedge Nov 21 '12 at 6:14
Great answer! Last question - if an injection attack were to take place at the SQL Server level would it have to be done through the use of EXEC? –  Abe Miessler Dec 4 '12 at 18:26
add comment

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:

   @Str VARCHAR(50)
EXEC ('SELECT * FROM Table Where Column = ''' + @Str + '''')
share|improve this answer
add comment

You will also need to look for things which use or contain a SqlCommand. These include SqlDataAdapter, among others.

share|improve this answer
In addition, look specifically for usages that concatenate parameters into the query string, instead of setting them up as parameters. If you have one function that simply executes any string passed in, mark it obsolete and refactor any usages that error to use an overload accepting a collection of parameters. –  KeithS Nov 21 '12 at 0:21
In dealing with code that uses string concatenation, I've found a useful first step to use ReSharper to turn the concatenation into a call on String.Format. I'll then refactor the format strings into constants, or else refactor the String.Formats into named methods. It then becomes much easier to find duplication, and to refactor that into methods that create a SqlCommand instead of methods that create strings. –  John Saunders Nov 21 '12 at 0:24
There could be helper libraries. The 'Data Access Application Block' or old SqlHelper allow for easy injection vulnerabilities. –  Tass Nov 21 '12 at 0:37
add comment

Just because you are using a parametrized query library doesn't mean its used properly. While auditing code I have seen cases where parametrized quires are being used, but some parts of the query are still built using string concatenation. More specifically the table name and the limit/order part of the query are common mistakes.

If you are totally set on static analysis the best bet is to grep for all queries in the application and then make sure each one is built properly. Yes this will take a long time, and it can be mind numbing. Take breaks, take notes and press on. When you find sql injection it will be rewarding!

share|improve this answer
add comment

Your Answer


