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.

490 Chapter 12 n Attacking Users: Cross-Site Scripting<br />

extract whatever comes next, up until <strong>the</strong> end of <strong>the</strong> URL. This behavior can<br />

be exploited in two ways:<br />

n If <strong>the</strong> server’s validation logic is being applied on a per-parameter basis,<br />

ra<strong>the</strong>r than on <strong>the</strong> entire URL, <strong>the</strong> payload can be placed into an invented<br />

parameter appended after <strong>the</strong> vulnerable parameter. For example:<br />

http://mdsec.net/error/76/Error.ashx?message=Sorry%2c+an+error+occurr<br />

ed&foo=alert(1)<br />

Here, <strong>the</strong> server ignores <strong>the</strong> invented parameter, and so it is not subject to<br />

any filtering. However, because <strong>the</strong> client-side script searches <strong>the</strong> query<br />

string for message= and extracts everything following this, it includes your<br />

payload in <strong>the</strong> string it processes.<br />

n If <strong>the</strong> server’s validation logic is being applied to <strong>the</strong> entire URL, not<br />

just to <strong>the</strong> message parameter, it may still be possible to evade <strong>the</strong> filter<br />

by placing <strong>the</strong> payload to <strong>the</strong> right of <strong>the</strong> HTML fragment character (#):<br />

http://mdsec.net/error/82/Error.ashx?message=Sorry%2c+an+error+<br />

occurred#alert(1)<br />

Here, <strong>the</strong> fragment string is still part of <strong>the</strong> URL. Therefore, it is stored<br />

in <strong>the</strong> DOM and will be processed by <strong>the</strong> vulnerable client-side script.<br />

However, because browsers do not submit <strong>the</strong> fragment portion of <strong>the</strong><br />

URL to <strong>the</strong> server, <strong>the</strong> attack string is not even sent to <strong>the</strong> server and<br />

<strong>the</strong>refore cannot be blocked by any kind of server-side filter. Because <strong>the</strong><br />

client-side script extracts everything after message=, <strong>the</strong> payload is still<br />

copied into <strong>the</strong> HTML page source.<br />

TRY IT!<br />

http://mdsec.net/error/76/<br />

http://mdsec.net/error/82/<br />

COMMON MYTH<br />

“We check every user request for embedded script tags, so no XSS attacks are<br />

possible.”<br />

Aside from <strong>the</strong> question of whe<strong>the</strong>r any filter bypasses are possible, you<br />

have now seen three reasons why this claim can be incorrect:<br />

n In some XSS flaws, <strong>the</strong> attacker-controllable data is inserted directly into<br />

an existing JavaScript context, so <strong>the</strong>re is no need to use any script tags<br />

or o<strong>the</strong>r means of introducing script code. In o<strong>the</strong>r cases, you can inject<br />

an event handler containing JavaScript without using any script tags.

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

Saved successfully!

Ooh no, something went wrong!