What you need to know about Cross-Site Scripting

Alice created a new social network for snowboarders to promote her company’s new line of boards. Now, a member of the social network can read reviews from other satisfied customers and click a link that brings them right to a shopping cart feature so they can make an easy purchase.

Happy with the way things look, and with the thought of all the potential sales, her boss gives her the OK for the site to go live.

Mallory visits the network and creates a review of her own. Noticing that she can enter a client-side script into her posting, she attaches a malicious payload to the script.

Bob hears about this site and anxiously signs up for an account. Looking through the reviews, he trusts this one from a girl named Mallory and clicks on the link adding the board she recommends to his cart and makes his purchase.

Unfortunately for Bob, the link he clicked on allowed Mallory to steal his session cookie. Now, Mallory can impersonate Bob, and any other unsuspecting user. Since everything is integrated, Mallory has access to account information, personal information, and anything else tied into their accounts.


This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy (no longer maintained) Zed Attack Proxy can be used to scan sites for possible vulnerabilities.


Cross site scripting gets its name from the fact that the attack is usually launched from a third party web application or web site. The attack happens cross sites. While there are many different approaches that attackers use in a cross-site scripting attack, they often fall under one of two categories, persistent (like the story above), and non-persistent. Non-persistent attacks are more common. In these attacks, a script that steals sensitive information from another open browser session is run in the browser. Because the session is open, the script can replicate a cookie received from the active connection to a server and use this to circumvent security that looks at cookies.


Many web developers are interested in creating dynamic web sites and great applications, not security. But as a developer it is important to have a basic understanding of how you can go about protecting your work from these vulnerabilities.

And just how does Alice help protect Bob and her other visitors from Mallory and her malicious attacks once they are found? When building sites developers should take two things into consideration from the beginning:

  • Validate input. If you allow a user to post anything to your website, make sure that you only accept the input you want. Does the field ask for the person’s name? Then only text should be allowed. Need an email address? Make sure the @ symbol is present. In both cases, any code should be filtered out.
  • Escape untrusted data. Most websites don’t require data, however for those that do, escaping data the right way will still allow it to be rendered in the browser properly. Escaping just lets the interpreter know that the data is not intended to be executed. When the data does not execute, the attack doesn’t work.

There is good news to all of this. XSS vulnerabilities can be patched. What is most promising is that White Hat also found that many of the sites that were clean had vulnerabilities in the past. Through diligence, they were able to rid their site of any bugs that could be exploited. Validation and Escaping data are two steps to take for existing vulnerabilities, and continually scanning your site for possible exploits is another. Most importantly, the developer and management need to be aware that this problem exists and it needs to be addressed.