28.10.2014 Views

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

232 Chapter 5 • Blind <strong>SQL</strong> <strong>Injection</strong> Exploitation<br />

theory perspective. However, there is still a performance issue with the binary search<br />

technique, since each request is dependent on the result of the previous request; we cannot<br />

make the second request before the answer to the first is known, since our second request<br />

might be to test the byte against 63 or 191. Thus, requests for a single byte cannot be run in<br />

parallel, <strong>and</strong> this violates our good sense.<br />

No t e<br />

Although it is true that bytes could be requested in parallel, there is no<br />

good reason to stop there without attempting to parallelize bit requests.<br />

We’ll look into this further shortly.<br />

This dependence is not intrinsic to the data, since the values of the bytes are not finalized<br />

by our requests; they remain constant in the database (constant in the sense that we are not<br />

changing them—of course, any application accessing the data could make alterations; if that<br />

is the case, all bets are off <strong>and</strong> all inference techniques become unreliable). The binary search<br />

technique grouped eight bits into a byte <strong>and</strong> inferred the value of all eight bits through eight<br />

requests. Could we not instead attempt to infer the value of a single specific bit per request<br />

(say, the second bit of the byte)? If that were possible, we could issue eight parallel requests<br />

for all bits in a byte <strong>and</strong> retrieve its value in less time than the binary search method would<br />

take to retrieve the same byte, since requests would be made side by side rather than one<br />

after the other.<br />

Massaging bits requires sufficiently helpful mechanisms within the <strong>SQL</strong> variant<br />

supported by the database under attack. Toward that end, Table 5.2 lists the bit functions<br />

supported by My<strong>SQL</strong>, <strong>SQL</strong> Server, <strong>and</strong> Oracle on two integers, i <strong>and</strong> j. Because Oracle<br />

does not provide an easily accessible native OR <strong>and</strong> XOR function we can roll our own.<br />

Table 5.2 Bitwise Operations in Three Databases<br />

Database Bitwise AND Bitwise OR Bitwise XOR<br />

My<strong>SQL</strong> i & j i | j i ^ j<br />

<strong>SQL</strong> Server i & j i | j i ^ j<br />

Oracle BITAND(i,j) i–<br />

BITAND(i,j)+j<br />

i–<br />

2*BITAND(i,j)+j

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!