The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

about the problem that occurred on the server.

■

If necessary, systematically modify your initial input in relevant ways 

in an attempt to confirm or disprove your tentative diagnosis of a 

vulnerability.

■

Construct a proof-of-concept test that causes a safe command to be exe-

cuted in a verifiable way, to conclusively prove that an exploitable code

injection flaw exists.

■

Exploit the vulnerability by leveraging the functionality of the target lan-

guage and component to achieve your objectives.

Chapter 9 

■

Injecting Code

239

70779c09.qxd:WileyRed  9/14/07  3:13 PM  Page 239

---

Injecting into SQL

Almost every web application employs a database to store the various kinds of

information that it needs in order to operate. For example, a web application

deployed by an online retailer might use a database to store the following

information:

■■

User accounts, credentials, and personal information

■■

Descriptions and prices of goods for sale

■■

Orders, account statements, and payment details

■■

The privileges of each user within the application

The means of accessing information within the database is Structured Query

Language, or SQL. SQL can be used to read, update, add, and delete informa-

tion held within the database.

SQL is an interpreted language, and web applications commonly construct

SQL statements that incorporate user-supplied data. If this is done in an unsafe

way, then the application may be vulnerable to SQL injection. This flaw is one

of the most notorious vulnerabilities to have afflicted web applications. In the

most serious cases, SQL injection can enable an anonymous attacker to read

and modify all data stored within the database, and even take full control of

the server on which the database is running.

As awareness of web application security has evolved, SQL injection vul-

nerabilities have become gradually less widespread, and more difficult to

detect and exploit. A few years ago, it was very common to encounter SQL

injection vulnerabilities that could be detected simply by entering an apostro-

phe into a HTML form field, and reading the verbose error message that the

application returned. Today, vulnerabilities are more likely to be tucked away

in data fields that users cannot normally see or modify, and error messages are

likely to be generic and uninformative. As this trend has developed, methods

for finding and exploiting SQL injection flaws have evolved, using more sub-

tle indicators of vulnerabilities, and more refined and powerful exploitation

techniques. We will begin by examining the most basic cases and then go on to

describe the latest techniques for blind detection and exploitation.

There is a very wide range of databases in use to support web applications.

While the fundamentals of SQL injection are common to the vast majority of

these, there are many differences. These range from minor variations in syntax

through to significant divergences in behavior and functionality that can affect

the types of attack that you can pursue. For reasons of space and sanity, we

will restrict our actual examples to the three most common databases you are

likely to encounter, namely Oracle, MS-SQL, and MySQL. Wherever applica-

ble, we will draw attention to the differences between these three platforms.