19.09.2017 Views

the-web-application-hackers-handbook

Create successful ePaper yourself

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

Chapter 13 n Attacking Users: O<strong>the</strong>r Techniques 549<br />

Within <strong>the</strong> inbox, several links are displayed next to each message to perform<br />

actions such as delete, forward, and reply. For example, <strong>the</strong> link to reply to message<br />

number 12 is as follows:<br />

reply<br />

Several parameters within <strong>the</strong>se links are being copied from parameters in<br />

<strong>the</strong> inbox URL. Even if <strong>the</strong> <strong>application</strong> defends robustly against XSS attacks, it<br />

may still be possible for an attacker to construct a URL that displays <strong>the</strong> inbox<br />

with different values echoed within <strong>the</strong>se links. For example, <strong>the</strong> attacker can<br />

supply a parameter like this:<br />

start=1%26action=delete<br />

This contains a URL-encoded & character that <strong>the</strong> <strong>application</strong> server will<br />

automatically decode. The value of <strong>the</strong> start parameter that is passed to <strong>the</strong><br />

<strong>application</strong> is as follows:<br />

1&action=delete<br />

If <strong>the</strong> <strong>application</strong> accepts this invalid value and still displays <strong>the</strong> inbox, and<br />

if it echoes <strong>the</strong> value without modification, <strong>the</strong> link to reply to message number<br />

12 becomes this:<br />

reply<br />

This link now contains two action parameters—one specifying delete, and<br />

one specifying reply. As with standard HTTP parameter pollution, <strong>the</strong> <strong>application</strong>’s<br />

behavior when <strong>the</strong> user clicks <strong>the</strong> “reply” link depends on how it handles<br />

<strong>the</strong> duplicated parameter. In many cases, <strong>the</strong> first value is used, so <strong>the</strong> user is<br />

unwittingly induced to delete any messages he tries to reply to.<br />

In this example, note that <strong>the</strong> links to perform actions contain an rnd parameter,<br />

which is in fact an anti-CSRF token, preventing an attacker from easily<br />

inducing <strong>the</strong>se actions via a standard CSRF attack. Since <strong>the</strong> client-side HPP<br />

attack injects into existing links constructed by <strong>the</strong> <strong>application</strong>, <strong>the</strong> anti-CSRF<br />

tokens are handled in <strong>the</strong> normal way and do not prevent <strong>the</strong> attack.<br />

In most real-world <strong>web</strong> mail <strong>application</strong>s, it is likely that many more actions<br />

exist that can be exploited, including deleting all messages, forwarding individual<br />

messages, and creating general mail forwarding rules. Depending on<br />

how <strong>the</strong>se actions are implemented, it may be possible to inject several required<br />

parameters into links, and even exploit on-site redirection functions, to induce<br />

<strong>the</strong> user to perform complex actions that normally are protected by anti-CSRF<br />

defenses. Fur<strong>the</strong>rmore, it may be possible to use multiple levels of URL encoding<br />

to inject several attacks into a single URL. That way, for example, one action

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

Saved successfully!

Ooh no, something went wrong!