SQL Injection Attacks and Defense - 2009

138 Chapter 4 • Exploiting SQL Injection
Introduction
Once you have found and confirmed that you have an SQL injection point, what do you do
with it? You may know you can interact with the database, but you don’t know what the
back-end database is, or anything about the query you are injecting into, or the table(s) it is
accessing. Again, using inference techniques and the useful error the application gives you,
you can determine all of this, and more.
In this chapter, we will discuss how deep the rabbit hole goes (you did take the red pill,
didn’t you?). We’ll explore a number of the building blocks you’ll need for later chapters, as
well as exploit techniques for reading or returning data to the browser, for enumerating the
database schema from the database, and for returning information out of band (i.e., not
through the browser). Some of the attacks will be targeted to extract the data that the remote
database stores and others will be focused on the database management system (DBMS) itself,
such as trying to steal the database users’ password hashes. Because some of these attacks need
administrative privileges to be carried out successfully, and because the queries that many
Web applications run are performed with the privileges of a normal user, we will also illustrate
some strategies for obtaining administrative privileges. And finally, so that you don’t have
to do it all manually, we’ll also look at techniques and tools (many written by the authors of
this book) for automating a lot of these steps for efficiency.
Tools & Traps...
The Big Danger: Modifying Live Data
Although the examples in the following sections will deal primarily with injections
into SELECT statements, never forget that your vulnerable parameter could be used in
far more dangerous queries that use commands such as INSERT, UPDATE, or DELETE
instead. Although a SELECT command only retrieves data from the database and
strictly follows a “look but don’t touch” approach, other commands can (and will)
change the actual data in the database that you are testing, which might cause major
problems in the case of a live application. As a general approach, when performing an
SQL injection attack on an application where more than one parameter is vulnerable,
always try to give priority to parameters that are used in queries that do not modify
any data. This will allow you to operate far more effectively, freely using your favorite
techniques without the risk of tainting the data or even disrupting application
functionality.
Continued