Many people have heard the term “cross-site scripting,” often referred to as XSS, but it’s been my experience that not many people are aware of just how it works or how it can affect them.  While XSS isn’t by any means a new tactic it has certainly grown in popularity over the past few years and I’ve found that much more of my day is devoted to resolving these kinds of issues.  Let’s look at a simple fictional example:

rOOfu5 the attacker spends his Saturday morning scanning some websites for known XSS vulnerabilities.  He happens to scan www.fictionaldomain.net and, while following some links, he discovers a file called myNewInput.cgi.  He passes a snippet of code to this .cgi, something like “<PLAINTEXT>” and suddenly he’s onto something.  He may be able to use this .cgi, and he’s pleased his “<PLAINTEXT>” snippet worked because he knows that it’s an older tag which is considered deprecated which seems to indicate that this page might not often be maintained.  rOOfu5 then proceeds to compose his exploit payload which will be spammed to a couple thousand users in the hopes of executing his code on the client machines.  He puts together a link that looks something like this:

<A HREF=http://www.fictionaldomain.net/myNewInput.cgi?updateNew=<SCRIPT>NASTY PAYLOAD HERE</SCRIPT>>You've received a holiday greeting!</A>

While checking her mail, Mabel Smith (fictional character), receives an email from a domain she’s never heard of which indicates she has a holiday e-card.  Mabel has received many e-cards this time of year from her friends and family and can’t wait to see who has sent her these tidings and good wishes.  When Mabel clicks the link a request is made to www.fictionaldomain.net/myNewInput.cgi which passes the malicious payload rOOfu5 designed back through Mabel’s browser.  The malicious code is executed and rOOfu5 adds another machine to his botnet.

Although this situation is completely fictional, this very simple form of XSS exploit is going on all the time.  There are other more complicated forms of XSS and there are certainly a near-infinite number of possible payloads, but this should be enough to illustrate this for you.

On the server side of things you can try to reduce the chance that your site is vulnerable by making sure anything you program yourself sanitizes as values are passed to it and, if you use someone else’s software, be sure to routinely check updates and security notices.  On the client’s end be sure to use a secure browser like Firefox and browser plugins like NoScript to prevent your machine from being taken over.  You may also want to run something like rubotted on Windows which will notify you if your PC has been added to a botnet.

Hopefully you’re better armed against those who would do you harm.