XSS: The Definitive Guide to Cross-Site Scripting Prevention

As old as web browsers themselves, cross-site scripting (XSS) has been an ongoing issue in the security world. Its’ consistent appearance on the OWASP Top 10 and in news reports of cross-site scripting attacks has kept the security issue in the spotlight over the years. Yet after two decades the security issue remains one of the most common attacks on web applications, with consistent reports of over 70% of sites at risk.

 

So, what is Cross-Site Scripting and how do we change our habits as users, developers and security professionals so we can prevent attacks once and for all? 

 

What Is XSS & Why Should I Care?

 Hacker

At its core, cross-site scripting is a vulnerability potentially found in dynamic applications that allow user input and don’t have control over output. An XSS attack is a hacking technique that preys on an application’s weak code, allowing an attacker to send malicious content and receive data from the victim in return, unsolicited and often without their knowledge. The true purpose of an XSS attack is to trick the victim into never knowing their activity has been intercepted, causing the victim to continue being compromised. Unlike attacks like SQL Injection, whose end goal is to hack an applications back end, XSS attacks go after the user – though they can be just as damaging to the organization.

 

Cross-site scripting attacks can occur on any site in any place that accepts user input by incorrectly or without validating it. Cross-site scripting is an attack method of having a legitimate website echo malicious, executable code, which is then loaded into a user’s browser. Malicious sites can load a legitimate site into a window or frame and then, primarily using JavaScript, read and modify the data from the legitimate site.

 

E-Commerce and banking sites are some of the most targeted with XSS because the ability to read and modify the information sent by the victim (bank account number, credit card details, etc.) makes those types of sites perfect for a higher ROI. But, in essence, any site with dynamic content is a potential victim of XSS and because it affects the user as well as the company’s reputation, cross-site scripting is not to be ignored.

 

What’s the History of Cross-Site Scripting?

 

XSS attacks are basically as old as web browsers themselves. In 1995, with the launching of one of the first browsers, Netscape, the world was introduced to a brand new scripting language, LiveScript, later renamed JavaScript. The new language offered fancy, dynamic features for developers to add, like the pop-ups we’ve all come to know and love/hate, as well as features for image and mouse rollover.

 

But the new features also led hackers to realize that when surfing the web, they were able to use JavaScript to, in essence, cross boundaries between two sites, scripting a malicious site within a fully legitimate one, allowing the hacker to see what was going on with the real site.

 

A decade after Netscape’s arrival on the scene we saw the first major cross-site scripting attack with the Samy Worm. When a technically advanced 17 year old named Samy discovered an XSS vulnerability on MySpace, which at the time was the biggest social platform, he wanted to see how far the worm would go. The resulting chaos definitely surprised Samy, along with MySpace, the FBI and the security world: 1 million profiles were infected before MySpace fixed the issue, each showing the phrase “Samy is my hero” and adding Samy as a friend. For a good read, Samy’s write-up of the attack is actually still up online.

 

Since that first attack a decade ago, Cross Site Scripting has held steady in top spots on the OWASP Top 10 in the 2007, 2010 and 2013 reports. XSS vulnerabilities have been found on government, Fortune 500 and the biggest tech companies’ sites – in short, nobody is truly safe from cross-site scripting, especially since vulnerabilities are so easy to re-introduce during development. For a disheartening look at how many sites are still affected by these vulnerabilities today, take a look at this XSSposed.org list.

 

What kinds of Cross-Site Scripting are there?

 

There are three types of cross-site scripting attacks: Reflected, Stored, and DOM-based, but because attackers use a mix to achieve different malicious effects, they can overlap with each other.

 

  1. In Reflected cross-site scripting, also called non-persistent XSS attacks,  the hacker finds a website with a vulnerable input field (login and search fields are perfect for these types of attacks) and creates a specially crafted URL that appears to come from the site. Because the attack isn’t actually stored, hackers using this technique spread the legitimate-looking URL through email, message boards, and on social networks, targeting victims separately.
  2. Stored cross-site scripting attacks, AKA persistent XSS, occur when a site stores malicious user input on the server, serving it back to the next users without having validated it first. In persistent attacks, the victim doesn’t even need to click a link to be a target – simply visiting the malicious website is enough to do the trick. In persistent cross-site scripting attacks, the attacker’s goal is usually to steal victim’s cookies and data.  Because stored XSS vulnerabilities are harder to find, reflected attacks are the most prevalent cross-site scripting attacks.
  3. DOM-based cross-site scripting occurs when the attack payload is executed by modifying the DOM (Document Object Model), which allows API access to a page’s HTML and XML content. In DOM-based cross-site scripting attacks, different from the first two attacks, the client-side script is responsible for not properly sanitizing the input, as opposed to the server.

While SQL injection exploits often get a reputation for being the most prevalent vulnerability in web apps and takes top place in the OWASP Top 10, XSS actually takes the cake for being the most widespread security issue today.

 

How can XSS affect your apps?

 

Companies and individuals developing client-server applications should always assume untrusted clients might be controlled by hackers and take steps to bridge any gaps there may be that would allow for untrusted inputs. Cross-site scripting vulnerabilities take the following shapes:

 

-Stealing browser and cookie data (the most common purpose)
-Stealing client data
-Stealing user data, including Personally Identifying Information (PII) like credit card numbers, usernames and passwords, and more
-Redirecting victim to the attacker’s site, which could still look like a legitimate subdomain of the original website
-Performing actions on the victim’s browser, acting as the legitimate site
-Installing an XSS proxy, allowing hacker to see and redirect user behavior
-Account Hijacking
-Keylogging
-Undermining CSRF defenses
-Rewriting/defacing portions of the page (though this is more of a nuisance than attack)

 

XSS: 11 Fast Facts 

 

  1. XSS attacks can also occur through third-party widgets and add-ons, including ads, pop-ups, and even through RSS feeds.
  2. The popularity of exploiting cross site-scripting attacks exploded particularly after the introduction of Web 2.0, with its masses of new input fields in the forms of forums and other social platforms.
  3. Between 10 and 25 new Cross-Site Scripting errors are discovered and reported on each month – with many more likely discovered and NOT reported.
  4. The victim in XSS attacks is the user, not the application (as opposed to SQL injections, which are aimed at the application).
  5. Studies have found that between 70 to 82% of sites are vulnerable to cross-site scripting.
  6. XSS security issues have the ability to help spread major DDoS attacks by enabling a botnet to infect countless users.
  7. Over 70% of Web Application Firewall (WAF) rules already in place can be bypassed through cross-site scripting obfuscation methods.
  8. Because cross-site scripting attacks can attain the same effects as an SQL injection, hackers are known to rely more on these low and medium risk vulnerabilities.
  9. Company website subdomains are one of the biggest targets of cross-site scripting attacks because they don’t have the same level of security as the sites’ main pages.
  10. Over 90% of cross-site scripting vulnerabilities can go unnoticed by IT personnel and advanced users.
  11. Hackers also use cross-site scripting to defeat CSRF defenses, allowing for more serious attacks relying on forged authentication.

 

XSS Prevention Steps: The Do’s and Don’ts of Cross-Site Scripting

 

The Dos & Donts of XSS Prevention1 (2)
XSS Prevention Do’s and Don’ts: Click to view downloadable PDF

download

 

Further Cross-Site Scripting Reading and Resources

  • For a good video of what XSS attacks look like, check out this Computerphile clip.
  • Google recently launched an XSS game especially designed to teach developers how to look for and fix Cross-Site Scripting issues. The Google Security Team regularly pays out bug bounties for finders of XSS issues (with a max cap of $7,500 per vulnerability), so it can pay to play!
  • Play Game of Hacks, Checkmarx’s online AppSec game designed to test your application hacking skills. Questions are based on the OWASP Top 10 list, with plenty of XSS queries to seek out.
  • The Web Hacking Incident Database has a comprehensive list of reported XSS attacks due to improper output handling – organized in pretty cards by date of attack.
  • The WebGoat Project is OWASP’s vulnerable web application and offers a lesson on cross-site scripting. And finally, here are the OWASP XSS Prevention Cheat Sheets for Reflected and Stored XSS and for DOM-based XSS.
The following two tabs change content below.
Sarah is in charge of social media and an editor and writer for the content team at Checkmarx. Her team sheds light on lesser-known AppSec issues and strives to launch content that will inspire, excite and teach security professionals about staying ahead of the hackers in an increasingly insecure world.

Latest posts by Sarah Vonnegut (see all)

Jump to Category