Detect SQL Injection

Question

I came to a company that already has a fully grown project... but coders that worked here before me didn\'t follow conventions and didn\'t use parametrized SQL queries... as

Answer 1

You need to check wherever variables are passed in to the SQL strings. For string values, you must you replace every instance of a single quote with a double quote. For non-string values (those that will pass to the SQL unquoted), you must make sure they are strongly typed.

E.g. don't pass something like "SELECT * FROM Users WHERE UserID = " + my_string_user_id. Instead, use code "SELECT * FROM Users WHERE UserID = " + userId_as_int.

This worked back in the day when I had a similar codebase with no parameterized queries at all.

Answer 2

You could give the MS Code Analysis Tool a whirl which (quote):

CAT.NET is a binary code analysis tool that helps identify common variants of certain prevailing vulnerabilities that can give rise to common attack vectors such as Cross-Site Scripting (XSS), SQL Injection and XPath Injection.

Never used it myself, but might be worth a try.

Answer 3

In order to really do this right you need to just divide up the application and go through it one module / page / class / whatever at a time.

This will allow you to not only fix the problem, but also to become much more familiar with the code base in general.

UPDATE
Based on the comment I wanted to add one more thing:

The only thing a tool can do is say look, here is some unsanitized inputs... Which, most likely, is going to be just about every query in your app. Which means you'll have a list of about 3000 or so files that need fixed.

At that point the only thing you can do is designate a day, like Friday, as Fix Sql Day. Divide up the work and then have everyone spend a day (or even just a couple hours) rewriting the queries on a few pages.

At some point you'll either finish or find enough other things wrong to determine if starting over is a good idea.

Answer 4

I applaud your willingness to dive in and fix things, and not just shrug and say, "ehh.. no one will attack our site anyway".

I think that perhaps the best approach would be to sanitize the inputs, assuming they are innocent, across the board. The problem is, there could be legitimate reasons for someone to enter any of the characters that could trigger SQL Injection.

Just trying to detect such patterns would be subject to false positive 'attack' results; Maybe someone tries to search for john's car, not knowing at all that the single-quote could be 'bad'. And maybe they really do need to search for that. Or, what have you...

Answer 5

There is no silver bullet here. SQL injections can come in many obscured forms and trying to detect them using regular expressions or another form in your firewall, or application can protect you from the most simple forms of SQL injection, but an experienced hacker will simply get through. As AdaTheDev already noted, automated tools that inspect your code, such as the MS Code Analysis Tool, might give you a kick start, but again there is no silver bullet. You will need to go through your whole application.

When this is a lot of work, you should make a plan. First of all, make a guideline that states how these types of attacks can be mitigated. Also try to divide your application in parts, from very critical to less critical. This way you can better estimate the costs of repairing the bugs and can let management decide what it may cost and thus what risk they are willing to take. Parts of your application that unauthenticated users can access are most critical. If everybody (in the world) can create an account in your application, all functionality that these users can access is highly critical. The smaller the population and the more you trust those users, the smaller the risk. You perhaps can get away with fixing these parts later. But never underestimate a good hacker. He/she might be able to compromise the account of a user with high privilege and start testing for SQL injection possibilities using that account.

Always try to have a defense in depth strategy, have multiple (or many) layers of defence. For instance, do never connect with your database as SA from within your application. Create an account with just the privileges that are needed and perhaps even create multiple SQL accounts, one account per role (or per a group of roles). While restricting the privileges to the database help a lot in mitigating the risk, again, don't bet on it as a single layer of defense. This article for instance, explains how a hacker can abuse a lower privilege account when she's able to do SQL injection.

It is admirable that you ask this question here, because I’ve seen many developers in the past who just don’t want to know, which is very scary, because the business often trusts its developers (which is scary as well).

I wish you the best of luck.