Automated SQL Injection ScanningOne possibility is using an automated web application vulnerability scanner, such as HP's WebInspect, IBM's AppScan or Cenzic's Hailstorm. These tools all offer easy, automated ways to analyze your web applications for potential SQL Injection vulnerabilities. However, they're quite expensive, running at up to $25,000 per seat.
Manual SQL Injection TestsWhat’s a poor application developer to do? You can actually run some basic tests to evaluate your web applications for SQL Injection vulnerabilities using nothing more than a web browser. First, a word of caution: the tests I describe only look for basic SQL Injection flaws. They won't detect advanced techniques and are somewhat tedious to use. If you can afford it, go with an automated scanner. However, if you can't handle that pricetag, manual testing is a great first step.
The easiest way to evaluate whether an application is vulnerable is to experiment with innocuous injection attacks that won't actually harm your database if they succeed but will provide you with evidence that you need to correct a problem. For example, suppose you had a simple web application that looks up an individual in a database and provides contact information as a result. That page might use the following URL format:
We can assume that this page performs a database lookup, using a query similar to the following:
Let's experiment with this a bit. With our assumption above, we can make a simple change to the URL that tests for SQL injection attacks:
SELECT phone FROM directory WHERE lastname = 'chapple' and firstname= 'mike'
If the web application hasn't been properly protected against SQL injection, it simply plugs this fake first name into the SQL statement it executes against the database, resulting in:
You'll notice that the syntax above is a little different than that in the original URL. I took the liberty of converting the URL-encoded variable for their ASCII equivalents to make it easier to follow the example. For example, %3d is the URL-encoding for the '=' character. I also added some line breaks for similar purposes.
SELECT phone FROM directory WHERE lastname = 'chapple' and firstname='mike' AND (select count(*) from fake)> 0 OR '1'='1'
Evaluating the ResultsThe test comes when you try to load the webpage with the URL listed above. If the web application is well-behaved, it will strip out the single quotes from the input before passing the query to the database. This will simply result in a weird lookup for someone with a first name that includes a bunch of SQL! You'll see an error message from the application similar to the one below:
On the other hand, if the application is vulnerable to SQL injection, it will pass the statement directly to the database, resulting in one of two possibilities. First, if your server has detailed error messages enabled (which you shouldn't!), you'll see something like this:
Error: No user found with name mike+AND+(select+count(*)+from+fake)+%3e0+OR+1%3d1 Chapple!
On the other hand, if your web server doesn't display detailed error messages, you'll get a more generic error, such as:
Microsoft OLE DB Provider for ODBC Drivers error '80040e37' [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name 'fake'. /directory.asp, line 13
If you receive either one of the two errors above, your application is vulnerable to SQL injection attack! Some steps that you can take to protect your applications against SQL Injection attacks include:
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator to inform of the time the error occurred and of anything you might have done that may have caused the error. More information about this error may be available in the server error log.
- Implement parameter checking on all applications. For example, if you're asking someone to enter a customer number, make sure the input is numeric before executing the query.
- Limit the permissions of the account that executes SQL queries. The rule of least privilege applies. If the account used to execute the query doesn't have permission to execute it, it will not succeed!
- Use stored procedures (or similar techniques) to prevent users from directly interacting with SQL code.