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

Chapter 9 

■

Injecting Code

281

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

---

gameover

maniscprout







Inducing Conditional Errors

In the preceding example, the application contained some prominent func-

tionality whose logic could be directly controlled by injecting into an existing

SQL query. The designed behavior of the application (a successful versus a

failed login) could be hijacked to return a single item of information to the

attacker. However, not all situations are this straightforward. In some cases,

you may be injecting into a query that has no noticeable effect on the applica-

tion’s behavior, such as a logging mechanism. In other cases, you may be

injecting a subquery or a batched query whose results are not processed by the

application in any way. In this situation, you may struggle to find a way of

causing a detectable difference in behavior that is contingent on a specified

condition.

David Litchfield devised a technique that can be used to trigger a detectable

difference in behavior in most circumstances. The core idea is to inject a query

that induces a database error contingent upon some specified condition. When

a database error occurs, this will often be externally detectable, either through

an HTTP 500 response code, or through some kind of error message or anom-

alous behavior (even if the error message itself does not disclose any useful

information).

The technique relies upon a feature of database behavior when evaluating

conditional statements: the database only evaluates those parts of the state-

ment that need to be evaluated given the status of other parts. An example of

this behavior is a 

SELECT

statement containing a 

WHERE

clause:

SELECT X FROM Y WHERE C

This causes the database to work through each row of table 

Y

, evaluating

condition 

C

, and returning 

X

in those cases where condition 

C

is true. If condi-

tion 

C

is never true, then the expression 

X

is never evaluated.

This behavior can be exploited by finding an expression 

X

that is syntacti-

cally valid but that generates an error if it is ever evaluated. An example of

such an expression in Oracle and MS-SQL is a divide-by-zero computation,

such as 

1/0

. If condition 

C

is ever true, then expression 

X

will be evaluated,

causing a database error. If condition 

C

is always false, then no error will be

generated. You can, therefore, use the presence or absence of an error to test an

arbitrary condition 

C

.