Cross-site scripting vulnerabilities are the biggest website security problem today. Studies have found they’re shockingly common – 55% of websites contained XSS vulnerabilities in 2011, according to White Hat Security’s latest report, released in June 2012. While most people have heard of computer viruses and other such problems, XSS vulnerabilities remain unknown to the average person.

A cross-site scripting vulnerability allows an attacker to execute arbitrary JavaScript code (from another site) on a web page. The code executes on the web page in the user’s browser.

An Example – The Twitter StalkDaily Worm

Let’s take a look at an XSS attack that occurred in the past with Twitter. In 2009, the StalkDaily worm proliferated throughout Twitter. When a Twitter user visited an infected user’s profile page, their profile page also became infected, spreading the worm. The worm also sent out tweets from each infected account.

So, how exactly did the StalkDaily worm work? Did someone hack Twitter’s web servers? Not quite – although it was a sort of hack.

Each Twitter user can set a short bio on their profile page. Users enter text in a profile box and, once they save the profile, the text appears on their profile page. Someone realized that Twitter didn’t properly sanitize the text input from the bio box (we’ll get to this later) – it just placed the text users entered directly into the web page’s source code. This allowed a user to enter an HTML <script> tag that loads a JavaScript file from a third-party web server.

When another Twitter user visited the infected profile page, their browser loaded the script. The script had full access to everything the official Twitter code used on the page – so the script was able to ask for the user’s Twitter cookie (which stores the user’s login state) and username from the browser. The script then sent this information back to the third-party web server. With these details, the third-party web server could authenticate as the Twitter user, modify the user’s bio to spread the worm, and send tweets from the user’s account.

How Developers Can Prevent XSS Attacks

One simple rule allows web developers to prevent cross-site scripting attacks: Don’t trust any input that comes from users. For example, in Twitter’s case, they shouldn’t have trusted the text users entered into their bio boxes. Twitter should have taken the text and “sanitized” or “escaped” it – for example, <script> should be changed into &lt;script&gt; – it will appear as <script> on the page, but won’t run as HTML code.

Similarly, an online shopping website like Amazon shouldn’t trust user-submitted reviews – it should sanitize all review text to ensure it’s safe.

There are other methods developers can use to mitigate against XSS attacks, as well – for example, the W3C Content Security Policy specification allows web developers to restrict a web application to only load scripts from specific URLs. Developers can also set HttpOnly for their cookies, which prevents scripts from accessing them.

XSS Plus Other Vulnerabilities

XSS attacks can be extra dangerous when coupled with other vulnerabilities. For example, an XSS attack can load a script that exploits a security vulnerability in a web browser or plug-in such as Flash or Java. If an attacker compromised a product review page on an online store’s website, the attacker could load code that exploits the vulnerability, and compromise every unpatched computer that views the product page. This makes it particularly important for developers to secure their websites against XSS attacks.

How You Can Prevent XSS Attacks

If you’ve gotten to this point, you’re probably wondering just what you – as a user – can do to prevent XSS attacks. The bad news is that, for the most part, web developers are the ones that need to get this right. However, there are still some things you can do:

• Keep Your Browser and Plug-ins Updated – Not only will the latest security fixes help mitigate XSS attacks that rely on these vulnerabilities to break out of your browser, newer browsers have more protection against XSS attacks than older ones. Newer browsers include support for web features like Content Security Policy (mentioned above) that allow developers to better secure their websites. They also include anti-XSS measures – for example, Chrome and other WebKit-based browsers like Safari include XSS Auditor, which attempts to identify and block XSS attacks. Internet Explorer even includes its own countermeasure, dubbed as XSS Filter.

• Disable JavaScript Entirely – While we don’t particularly like NoScript here at MakeUseOf, disabling JavaScript entirely does eliminate XSS attacks. Unfortunately, disabling JavaScript also eliminates a lot of other things that we like about the modern web and a lot of websites won’t work properly without JavaScript enabled.

Have you had any experience with XSS attacks? Leave a comment and share your experience – if you have any questions about XSS vulnerabilities, we’d be happy to answer those, too.

Image Credit: 3D Communication Concept via Shutterstock