SQL Injection Attacks and Defense - 2009

Testing for SQL Injection • Chapter 2 51
Application Response
In the previous section, you saw the kinds of errors that applications typically display when
the back-end database fails to execute a query. If you see one of those errors, you can be
almost certain that the application is vulnerable to some kind of SQL injection. However,
applications react differently when they receive an error from the database, and sometimes
identifying SQL injection vulnerabilities is not as easy as previously shown. In this section,
you will see other examples of errors not directly displayed in the browser, which represent
different levels of complexity.
No t e
There is no golden rule to determine whether certain input triggered an
SQL injection vulnerability, as the possible scenarios are endless.
It is simply important that you remain focused and pay attention to detail
when investigating potential SQL injections. It is recommended that you use
a Web proxy, as your Web browser will hide details such as HTML source
code, HTTP redirects, and so forth. Besides, when working at a lower level
and watching the HTML source code you are more likely to discover other
vulnerabilities apart from SQL injection.
The process of finding SQL injection vulnerabilities involves identifying user data entry,
tampering with the data sent to the application, and identifying changes in the results
returned by the server. You have to keep in mind that tampering with the parameters can
generate an error which could have nothing to do with SQL injection.
Generic Errors
In the previous section, you saw the typical errors returned from the database. In that kind of
scenario, it is very easy to determine whether a parameter is vulnerable to SQL injection. In
other scenarios, the application will return a generic error page regardless of the kind of failure.
A good example of this is the Microsoft .NET engine, which by default returns the
Server Error page shown in Figure 2.6 in the event of runtime errors.