19.09.2017 Views

the-web-application-hackers-handbook

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

290 Chapter 9 n Attacking Data Stores<br />

all o<strong>the</strong>r accounts via <strong>the</strong> <strong>application</strong>. Fur<strong>the</strong>rmore, if <strong>the</strong> query returns <strong>the</strong><br />

details for more than one user, most <strong>application</strong>s will simply process <strong>the</strong> first<br />

user whose details are returned. An attacker can often exploit this behavior to<br />

log in as <strong>the</strong> first user in <strong>the</strong> database by supplying <strong>the</strong> username:<br />

‘ OR 1=1--<br />

This causes <strong>the</strong> <strong>application</strong> to perform <strong>the</strong> query:<br />

SELECT * FROM users WHERE username = ‘’ OR 1=1--’ AND password = ‘foo’<br />

Because of <strong>the</strong> comment symbol, this is equivalent to:<br />

SELECT * FROM users WHERE username = ‘’ OR 1=1<br />

which returns <strong>the</strong> details of all <strong>application</strong> users.<br />

NOTE Injecting into an interpreted context to alter <strong>application</strong> logic is a<br />

generic attack technique. A corresponding vulnerability could arise in LDAP<br />

queries, XPath queries, message queue implementations, or indeed any<br />

custom query language.<br />

HACK STEPS<br />

Injection into interpreted languages is a broad topic, encompassing many<br />

different kinds of vulnerabilities and potentially affecting every component of<br />

a <strong>web</strong> <strong>application</strong>’s supporting infrastructure. The detailed steps for detecting<br />

and exploiting code injection flaws depend on <strong>the</strong> language that is being<br />

targeted and <strong>the</strong> programming techniques employed by <strong>the</strong> <strong>application</strong>’s<br />

developers. In every instance, however, <strong>the</strong> generic approach is as follows:<br />

1. Supply unexpected syntax that may cause problems within <strong>the</strong> context of<br />

<strong>the</strong> particular interpreted language.<br />

2. Identify any anomalies in <strong>the</strong> <strong>application</strong>’s response that may indicate <strong>the</strong><br />

presence of a code injection vulnerability.<br />

3. If any error messages are received, examine <strong>the</strong>se to obtain evidence<br />

about <strong>the</strong> problem that occurred on <strong>the</strong> server.<br />

4. If necessary, systematically modify your initial input in relevant ways in an<br />

attempt to confirm or disprove your tentative diagnosis of a vulnerability.<br />

5. Construct a proof-of-concept test that causes a safe command to be<br />

executed in a verifiable way, to conclusively prove that an exploitable<br />

code injection flaw exists.<br />

6. Exploit <strong>the</strong> vulnerability by leveraging <strong>the</strong> functionality of <strong>the</strong> target<br />

language and component to achieve your objectives.

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

Saved successfully!

Ooh no, something went wrong!