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

occurs, thus establishing the number of brackets you need to close to

control the rest of the query:

*);cn;

*));cn;

*)));cn;

*))));cn;

■

Try adding extra attributes to the end of your input, using commas to

separate each item. Test each attribute in turn — an error message indi-

cates that the attribute is not valid in the present context. Attributes

commonly used in directories queried by LDAP include:

cn,c,mail,givenname,o,ou,dc,l,uid,objectclass,postaladdress,dn,sn

Preventing LDAP Injection

If it is necessary to insert user-supplied input into an LDAP query, this opera-

tion should only be performed on simple items of data that can be subjected to

strict input validation. The user input should be checked against a white list of

acceptable characters, which should ideally include only alphanumeric char-

acters. Characters that may be used to interfere with the LDAP query should

be blocked, including 

( ) ; , * | &

and 

=

. Any input that does not match the

white list should be rejected, not sanitized.

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

---

Chapter Summary

We have examined a wide range of code injection vulnerabilities, and the prac-

tical steps that you can take to identify and exploit each one. There are many

real-world injection flaws that can be discovered within the first few seconds

of interacting with an application — for example, by entering an apostrophe

into a search box. In other cases, code injection vulnerabilities may be highly

subtle, manifesting themselves in scarcely detectable differences in the appli-

cation’s behavior, or reachable only through a multistage process of submit-

ting and manipulating crafted input.

To be confident that you have uncovered the code injection flaws that exist

within an application, you need to be both thorough and patient. Practically

every type of injection can manifest itself in the processing of practically any

item of user-supplied data, including the names and values of query string

parameters, 

POST

data and cookies, and other HTTP headers. In many cases, a

defect will emerge only after extensive probing of the relevant parameter, as

you learn exactly what type of processing is being performed on your input

and scrutinize the obstacles that stand in your way. 

Faced with the huge potential attack surface presented by code injection vul-

nerabilities, you may feel that any serious assault on an application must entail a

titanic effort. However, part of learning the art of attacking software is to acquire

a sixth sense for where the treasure is hidden and how your target is likely to

open up so that you can steal it. The only way to gain this sense is through prac-

tice, rehearsing the techniques we have described against the real-life applica-

tions you encounter, and seeing how they stand up to them.

Questions

Answers can be found at 

www.wiley.com/go/webhacker.

1. You are trying to exploit a SQL injection flaw by performing a 

UNION

attack to retrieve data. You do not know how many columns the origi-

nal query returns. How can you find this out?

2. You have located a SQL injection vulnerability in a string parameter.

You believe the database is either MS-SQL or Oracle but are unable at

this stage to retrieve any data or an error message to confirm which

database is running. How can you find this out?

3. You have submitted a single quotation mark at numerous locations

throughout the application, and from the resulting error messages have