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.