How Common Are SQL Injection Vulnerabilities?
Michael Sutton has run a test to see how many websites have SQL injection issues and finds that 11% of the websites he tests are potentially vulnerable.
The article is well written in that he discusses the methods used to select urls for testing, the change he uses to attempt a non-destructive SQL injection, and how he determines a vulnerability exists.
Michael isn't just testing SQL Server (read the Comments as well) the method will work with just about any database driven website.
You should remember that SQL Injection Attacks can occur whenever the application layer does not correctly verify and restrict input parameters. In the case of the websites Michael found vulnerabilities in, there are actually two big issues:
- User input was not correctly tested and typecast (id values should have been converted to a number, single quotes should have been escaped)
- Error messages were printed out for the user to see (an error handling routine should have hidden this)
In the case of the IIS Webservice in Windows you can create a default 500:100 error page which is displayed whenever an error occurs in your web application. This page should not show the error message to the user, just a polite "sorry we had a problem, please try again". The page should also alert the website administrator of the error and full details should be recorded so the problem can be correctly handled in the future. Using a 500:100 page can help catch any errors a developer may have missed.
Spitting out an internal error message from SQL or any programming language is going to confuse a user. It also tells hackers information about your servers you really don't want them to know.