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.

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

Request Forgery<br />

This category of attack (also known as session riding) is closely related to session<br />

hijacking attacks, in which an attacker captures a user’s session token and<br />

<strong>the</strong>refore can use <strong>the</strong> <strong>application</strong> “as” that user. With request forgery, however,<br />

<strong>the</strong> attacker need never actually know <strong>the</strong> victim’s session token. Ra<strong>the</strong>r, <strong>the</strong><br />

attacker exploits <strong>the</strong> normal behavior of <strong>web</strong> browsers to hijack a user’s token,<br />

causing it to be used to make requests that <strong>the</strong> user does not intend to make.<br />

Request forgery vulnerabilities come in two flavors: on-site and cross-site.<br />

On-Site Request Forgery<br />

On-site request forgery (OSRF) is a familiar attack payload for exploiting stored<br />

XSS vulnerabilities. In <strong>the</strong> MySpace worm, described in <strong>the</strong> preceding chapter,<br />

a user named Samy placed a script in his profile that caused any user viewing<br />

<strong>the</strong> profile to perform various unwitting actions. What is often overlooked is<br />

that stored OSRF vulnerabilities can exist even in situations where XSS is not<br />

possible.<br />

Consider a message board <strong>application</strong> that lets users submit items that are<br />

viewed by o<strong>the</strong>r users. Messages are submitted using a request like <strong>the</strong> following:<br />

POST /submit.php<br />

Host: wahh-app.com<br />

Content-Length: 34<br />

type=question&name=daf&message=foo<br />

This request results in <strong>the</strong> following being added to <strong>the</strong> messages page:<br />

<br />

<br />

daf<br />

foo<br />

<br />

In this situation, you would, of course, test for XSS flaws. However, suppose<br />

that <strong>the</strong> <strong>application</strong> is properly HTML-encoding any “< and > characters it inserts<br />

into <strong>the</strong> page. When you are satisfied that this defense cannot be bypassed in<br />

any way, you might move on to <strong>the</strong> next test.<br />

But look again. You control part of <strong>the</strong> target of <strong>the</strong> tag. Although you<br />

cannot break out of <strong>the</strong> quoted string, you can modify <strong>the</strong> URL to cause any user<br />

who views your message to make an arbitrary on-site GET request. For example,<br />

submitting <strong>the</strong> following value in <strong>the</strong> type parameter causes anyone viewing<br />

your message to make a request that attempts to add a new administrative user:<br />

../admin/newUser.php?username=daf2&password=0wned&role=admin#

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

Saved successfully!

Ooh no, something went wrong!