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.

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

provided by <strong>the</strong> attacker. The attacker’s interface contains content to entice <strong>the</strong><br />

user and induce him to perform actions such as clicking <strong>the</strong> mouse in a particular<br />

region of <strong>the</strong> page. When <strong>the</strong> user performs <strong>the</strong>se actions, although it<br />

appears that he is clicking <strong>the</strong> buttons and o<strong>the</strong>r UI elements that are visible in<br />

<strong>the</strong> attacker’s interface, he is unwittingly interacting with <strong>the</strong> interface of <strong>the</strong><br />

<strong>application</strong> that is being targeted.<br />

For example, suppose a banking function to make a payment transfer involves<br />

two steps. In <strong>the</strong> first step, <strong>the</strong> user submits <strong>the</strong> details of <strong>the</strong> transfer. The response<br />

to this request displays <strong>the</strong>se details, and also a button to confirm <strong>the</strong> action<br />

and make <strong>the</strong> payment. Fur<strong>the</strong>rmore, in an attempt to prevent CSRF attacks,<br />

<strong>the</strong> form in <strong>the</strong> response includes a hidden field containing an unpredictable<br />

token. This token is submitted when <strong>the</strong> user clicks <strong>the</strong> confirm button, and <strong>the</strong><br />

<strong>application</strong> verifies its value before transferring <strong>the</strong> funds.<br />

In <strong>the</strong> UI redress attack, <strong>the</strong> attacker’s page submits <strong>the</strong> first request in this<br />

process using conventional CSRF. This is done in an iframe within <strong>the</strong> attacker’s<br />

page. As it does normally, <strong>the</strong> <strong>application</strong> responds with <strong>the</strong> details of <strong>the</strong> user<br />

to be added and a button to confirm <strong>the</strong> action. This response is “displayed”<br />

within <strong>the</strong> attacker’s iframe, which is overlaid with <strong>the</strong> attacker’s interface<br />

designed to induce <strong>the</strong> victim to click <strong>the</strong> region containing <strong>the</strong> confirm button.<br />

When <strong>the</strong> user clicks in this region, he is unwittingly clicking <strong>the</strong> confirm<br />

button in <strong>the</strong> target <strong>application</strong>, so <strong>the</strong> new user gets created. This basic attack<br />

is illustrated in Figure 13-1.<br />

Figure 13-1: A basic UI redress attack<br />

The reason this attack succeeds, where a pure CSRF attack would fail, is<br />

that <strong>the</strong> anti-CSRF token used by <strong>the</strong> <strong>application</strong> is processed in <strong>the</strong> normal<br />

way. Although <strong>the</strong> attacker’s page cannot read <strong>the</strong> value of this token due to<br />

<strong>the</strong> same-origin policy, <strong>the</strong> form in <strong>the</strong> attacker’s iframe includes <strong>the</strong> token

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

Saved successfully!

Ooh no, something went wrong!