Justin Clarke Lead Author and Technical Editor Rodrigo Marcos Alvarez Dave Hartley Joseph Hemler Alexander Kornbrust Haroon Meer Gary O’Leary-Steele Alberto Revelli Marco Slaviero Dafydd Stuttard

 
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.
N
ote
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.

---