SQL Injection Attacks and Defense - 2009

Exploiting SQL Injection • Chapter 4 139
On the other hand, if the only vulnerable parameters at your disposal are used
to modify some data, most of the techniques outlined in this chapter will be useful for
exploiting the vulnerability. However, be extra careful in what you inject and how this
might affect the database. If the application you are testing is in production, before
performing the actual attack make sure all the data is backed up and that it is possible
to perform a full rollback after the security testing of the application has been
completed.
This is especially true when using an automated tool such as the ones I will introduce
at the end of the chapter. Such tools can easily execute hundreds or thousands
of queries in a very short time to do their job, all with minimal user interaction. Using
such a tool to inject on an UPDATE or a DELETE statement can wreak havoc on a
DBMS, so be careful!
Understanding
Common Exploit Techniques
Arriving at this point, you have probably found one or more vulnerable parameters on the
Web application you are testing, by either using the techniques for testing the application
outlined in Chapter 2, or reviewing the code outlined in Chapter 3. Perhaps a single quote
inserted in the first GET parameter that you tried was sufficient to make the application
return a database error, or maybe you literally spent days stubbornly going through each
parameter trying entire arrays of different and exotic attack vectors. In any case, now is the
time to have some real fun with the actual exploitation.
It is very useful at this stage to have a local installation of the same database system that
sits behind the application you are attacking. Unless you have the Web application source
code, SQL injection requires a black-box attack approach, and you will have to craft the
queries to inject by observing how your target responds to your requests. Being able to
locally test the queries you are going to inject in order to see how the database responds to
such queries makes this phase a lot easier.
Exploiting an SQL injection vulnerability can mean different things in different situations
depending on the conditions in place, such as the privileges of the user performing the queries,
the exact DBMS server that sits on the back end, and whether you are more interested in
extracting data, modifying data, or running commands on the remote host. However, at this
stage what really makes a difference is whether the application presents in the HTML code
the output of your SQL queries (even if the DBMS returns only the error message). If you
don’t have any kind of SQL output displayed within the application, you will need to perform
a blind SQL injection attack, which is more intricate (but a lot more fun). We’ll cover blind
SQL injection in Chapter 5. For now, and unless specified otherwise, we will assume that the
remote database returns SQL output to some extent, and we will go through a plethora of
attack techniques that leverage this fact.