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

Chapter 9 

■

Injecting Code

273

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

---

numeric range and construct a mapping of document contents to identifiers.

Then, when performing the attack described previously, the attacker can con-

sult this map to determine the identifier for each document received from the

application, and thereby retrieve the ASCII value of the character that they

have successfully extracted.

Using an Out-of-Band Channel

In many cases of SQL injection, the application does not return the results of

any injected query to the user’s browser, nor does it return any error messages

generated by the database. In this situation, it may appear that your position is

futile: even if a SQL injection flaw exists, it surely cannot be exploited to extract

arbitrary data or perform any other action. This appearance is false, however,

and there are various techniques that you can use to retrieve data, and verify

that other malicious actions have been successful. 

There are many circumstances in which you may be able to inject an arbi-

trary query but not retrieve its results. Recall the example of the vulnerable

login form, where the username and password fields are vulnerable to SQL

injection:

SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’

In addition to modifying the logic of the query to bypass the login, you can

inject an entirely separate subquery using string concatenation to join its

results to the item you control. For example:

foo’ ||  (SELECT 1 FROM dual WHERE (SELECT username FROM all_users WHERE

username = ‘DBSNMP’) = ‘DBSNMP’)--

This will cause the application to perform the following query:

SELECT * FROM users WHERE username = ‘foo’ || (SELECT 1 FROM dual WHERE

(SELECT username FROM all_users WHERE username = ‘DBSNMP’) = ‘DBSNMP’)

The database will execute your arbitrary subquery, append its results to 

foo

and then look up the details of the resulting username. Of course, the login

will fail, but your injected query will have been executed. All you will receive

back in the application’s response is the standard login failure message. What

you then need is a means of retrieving the results of your injected query.

A different situation arises when you are able to employ batch queries

against MS-SQL databases. Batch queries are extremely useful, because they

allow you to execute an entirely separate statement over which you have full

control, using a different SQL verb and targeting a different table. However,

because of the way batch queries are carried out, the results of an injected