Security has always been a top priority at Xibis.
7th September 2006
Security has always been a top priority at Xibis. When we write web software, we assume that every user on the site knows exactly how our software works, has an in-depth understanding of web security, and is out to attack it. It is this kind of paranoia that keeps our systems secure.
The problem when outsourcing web development is that the person outsourcing the work often does not understand what the developer is doing. Once the software is completed, if it more or less works then you’re happy. But how do you know it’s safe from security threats?
Today, I want to look at one of the major problems in web site security: SQL Injection. The tips I am going to give you will not give you the assurance that your site is free of SQL Injection issues - for that you’ll need a full audit. However, it should give you the reassurance that the developer has at least thought about security.
But first: what is SQL Injection?
Interactive web sites generally involve databases. There is usually one point where it takes information from the user and uses it to query a database. This might be as simple as getting a number from a query string and using it to retrieve a news article of that number. You’ve probably seen this on the web where a URL ends something like "?id=5". Typically, that number 5 will be used within a database query to find the 5th news item, product, or whatever the site is programmed to find.
When the web site received the request, it will:
1. Get whatever parameter was passed to it (in this case 5).
2. Verify that the parameter passed was a number.
3. Add it into a query (e.g. "Get the news item where the reference is [insert parameter]").
4. Display the results on a page.
SQL Injection can occur when you miss out stage 2: "Verify that the parameter was a number". If the software is not written to verify the input, it will just pass anything onto the database. If your database query is simply (I’ve obviously translated the query language into English for you):
Get me all of the products in category [whatever is on the end of the query sting]
So when the system is used normally, it would create a query something like this:
Get me all of the products in category 5
Then by carefully constructing the query string, it’s easy to get it to do this:
Get me all of the products in category 5 and all of the administration passwords
The site will then just display the passwords where it should be displaying the product information. By changing the 5 to 0, you can usually hide all the products so all you get are the passwords.
SQL Server and some other database management systems allow software to submit multiple queries at once. So you could also manipulate a site to do something like:
Get me all of the products in category 5 and then delete all of the products and users from the database
Above, I’ve used the example of passing a number, but anything (text, dates etc) that is taken from the user and sent in a database query needs to be properly cleaned to prevent attacks.
Here are some simple tests you can do to test for SQL Injection. They’re not 100% effective as the developer could have suppressed the error messages; however, most of the time these tests will show you if there are any serious problems. Important: only perform these tests on your sites or with the site owner’s permission.
Before you run the tests change Internet Explorer's settings so that you can see the error messages. Go to Tools > Internet Options > Advanced -> Show friendly HTTP error messages and uncheck the checkbox.
First, test the query string pages. Look for pages where the URL ends with a query string, for example:
news.asp?id=7
Or it might be passing several parameters, e.g.
news.asp?id=7&category=12
Now try passing it some different parameters and see what it does. Do this separately for each item first adding a letter, and then an apostrophe. So for the 2nd URL above, you would try the following 4 requests, one after another:
news.asp?id=7A&category=12
news.asp?id=7'&category=12
news.asp?id=7&category=12A
news.asp?id=7&category=12'
When you try each URL, you will possibly get an error message. The error message could come from the software (in which case you’re probably OK) or it could come from the DBMS (database management system), in which case you’ve almost certainly got a problem. If you get any of the following words in the error message, it's almost certainly the latter:
MSSQL, SQL Server, SQL, MySQL, Jet,
Access, OLE DB, Oracle, ODBC
If these words aren't included in the error message, there is still a fair chance that there is a SQL injection problem - get it checked out.
If the parameters in the URL contains text instead of a number, there’s no point in trying the "A" - but it’s still worth trying the apostrophe.
Next, test any forms on the site. Enter text as normal, but include an apostrophe within the text. Look for the same errors and remember to try the login forms. If you get on a login form after entering an apostrophe, the chances are that a quick (and well-known) trick will allow anyone to bypass login process.
Finally, I’d like to emphasise again that these tests are good for a quick look over, SQL injection is a complex issue and we’ve barely scratched the surface - the tests will highlight that the developer has at least has understood the basics of protecting against SQL injection, but they won’t confirm that the site is in any way invulnerable to it. For a proper check, I would recommend having the system thoroughly audited.