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.

314 Chapter 9 n Attacking Data Stores<br />

So far, so good. However, suppose that <strong>the</strong> <strong>application</strong> also implements a<br />

password change function. This function is reachable only by au<strong>the</strong>nticated<br />

users, but for extra protection, <strong>the</strong> <strong>application</strong> requires users to submit <strong>the</strong>ir<br />

old password. It <strong>the</strong>n verifies that this is correct by retrieving <strong>the</strong> user’s current<br />

password from <strong>the</strong> database and comparing <strong>the</strong> two strings. To do this, it<br />

first retrieves <strong>the</strong> user’s username from <strong>the</strong> database and <strong>the</strong>n constructs <strong>the</strong><br />

following query:<br />

SELECT password FROM users WHERE username = ‘foo’’<br />

Because <strong>the</strong> username stored in <strong>the</strong> database is <strong>the</strong> literal string foo’, this<br />

is <strong>the</strong> value that <strong>the</strong> database returns when this value is queried. The doubledup<br />

escape sequence is used only at <strong>the</strong> point where strings are passed into <strong>the</strong><br />

database. Therefore, when <strong>the</strong> <strong>application</strong> reuses this string and embeds it into<br />

a second query, a SQL injection flaw arises, and <strong>the</strong> user’s original bad input is<br />

embedded directly into <strong>the</strong> query. When <strong>the</strong> user attempts to change <strong>the</strong> password,<br />

<strong>the</strong> <strong>application</strong> returns <strong>the</strong> following message, which reveals <strong>the</strong> flaw:<br />

Unclosed quotation mark before <strong>the</strong> character string ‘foo<br />

To exploit this vulnerability, an attacker can simply register a username<br />

containing his crafted input, and <strong>the</strong>n attempt to change his password. For<br />

example, if <strong>the</strong> following username is registered:<br />

‘ or 1 in (select password from users where username=’admin’)--<br />

<strong>the</strong> registration step itself will be handled securely. When <strong>the</strong> attacker tries to<br />

change his password, his injected query will be executed, resulting in <strong>the</strong> following<br />

message, which discloses <strong>the</strong> admin user’s password:<br />

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’<br />

[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting<br />

<strong>the</strong> varchar value ‘fme69’ to a column of data type int.<br />

The attacker has successfully bypassed <strong>the</strong> input validation that was designed<br />

to block SQL injection attacks. Now he has a way to execute arbitrary queries<br />

within <strong>the</strong> database and retrieve <strong>the</strong> results.<br />

TRY IT!<br />

http://mdsec.net/addressbook/107/<br />

Advanced Exploitation<br />

All <strong>the</strong> attacks described so far have had a ready means of retrieving any useful<br />

data that was extracted from <strong>the</strong> database, such as by performing a UNION<br />

attack or returning data in an error message. As awareness of SQL injection

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

Saved successfully!

Ooh no, something went wrong!