Your Guide to Cross-Site Scripting (xss) Cheat Sheet

It’s easy to think of the latest and most innovative threats as being the most dangerous, but there’s clear evidence that the old tricks still work and can still be as effective as the latest in cyberattacks.

Cross-site scripting (XSS) is a great example of this. First logged by Microsoft in 2000, these attacks have been around for decades and continue to be prevalent in the world of the web.

It’s worth making the extra effort to track these down and be at the forefront of best practices for preventing this security vulnerability. 

What Is A Cross-Site Scripting (XSS) Attack?

A cross-site scripting (XSS) attack is the act of exploiting a vulnerability within a web page to inject malicious code. This code can steal user-sensitive information and persist across multiple sessions to affect several users. XSS attacks can be used to capture and modify passwords, session authentication and cookies. 

A cross-site scripting attack is unique because these vulnerabilities don’t target the website or web app they exploit. They’re commonly implemented as attack vectors and are executed on a user’s machine through the user’s browser. As such, they’re referred to as client-side scripts. The vast majority of these attacks are coded in JavaScript or HTML. Though rare, there are other languages that can be used for client-side scripts.

XSS attacks fall into primary two categories. Reflected and stored attacks.

Reflected XSS Attack 

These quick, one-off attacks rely on server-side scripts not sanitizing requests to eliminate scripts or other embedded objects.

An attacker using a reflected XSS attack gets a user to click on a link, either through email, a malicious website, or elsewhere. The link contains a malicious script that a vulnerable website won’t strip away through sanitization, thus bouncing the script off the site and onto the user’s computer.

Stored XSS Attack

These are less common and are far more dangerous and destructive than reflected attacks. Unlike reflected attacks, stored attacks exploit a site in a way that saves the malicious script an attacker wants to run on targeted computers.

A stored XSS attack requires a website to store user information in a public place, such as a social media platform, online forum, third-party retail site, or similar site. More specifically, attackers require the website to allow un-sanitized HTML to be embedded in the site that visitors would be subjected to simply by viewing the page. 

As with a reflected attack, the script embedded in the infected content wouldn’t be visible, so no suspicion is raised and the user would have no indication that the attack is underway.

The most destructive part about stored attacks is that they don’t require any interaction from the user. Examples of stored attacks could include embedding an XSS in a username, a blog post, a product description, a forum post, or anywhere else unsanitized user-generated HTML content is allowed.

Is Cross-Site Scripting A Serious Threat?

XSS attacks are simple, straightforward and potentially devastating. An attacker needs a vulnerable website prone to XSS vulnerabilities and proper JavaScript and HTML knowledge to disrupt a person’s life and cause damage. The sheer persistence of XSS in cyberattacks should be enough to worry any development or security team.

XSS attacks are capable of stealing sensitive data from users. Session cookies are a great example and when stolen an attacker may duplicate a user’s active session, giving them access to anything the user is able to do on a website. Edit personal information, change passwords, steal credit card information, make bank transfers, buy products from an e-commerce site, and much more.

Examples Of Major Cross-Site Scripting Attacks

Learning from the mistakes of others is a great way to learn hard lessons and work to mitigate the risk of serious XSS vulnerabilities. Here are prominent examples of XSS attacks to provide context on the serious threat they represent.

Twitter’s 2010 redesign contained an XSS vulnerability that Sarah Brown, the wife of former British Prime Minister Gordon Brown, fell prey to and unknowingly shared with her +1,000,000 followers. The exploit used a mouseover to redirect users to a pornographic website.

eBay users have been dealing with potential XSS scripts embedded in item listings for years, and by early 2017 the issue still hadn’t been fixed. In this case, malicious sellers added scripts to legitimate product listings to redirect users to a spoofed login page that harvested credentials before redirecting users back to a legitimate eBay page.

Nearly 400,000 British Airways bookings were compromised by XSS which targeted the airline’s payment system on its website and in its mobile app. Potentially all of those transactions had their credit and debit card details stolen.

The Samy Worm that affected MySpace in 2005 added a line about the worm’s developer to everyone’s profile saying he was the victim’s hero. Regardless of its benign nature, the Samy Worm used XSS to infect over one million MySpace users in under 20 hours, making it the fastest spreading worm in internet history.

Yahoo faced a lot of security woes in the declining days of its email supremacy, one of which was an XSS phishing attack in 2013 that resulted in victims having their accounts stolen.

There are several other XSS examples that are often less publicized, but if major websites can be affected by cross-site scripting, you better believe it’s worth the effort to make sure you’re staying safe and actively developing software in a way that mitigates the risk of XSS vulnerabilities. A great place to start is by keeping sensitive data out of your script tag!

How Can Development Teams Protect Their Web Apps From Cross-Site Scripting Attacks?

In some cases preventing cross-site scripting vulnerabilities can be as simple as adding a couple of HTML tags to a website. While it isn’t always this simple, here are additional methods your teams can use to prevent XSS attacks.

What Is HTML Attribute Encoding?

This practice helps with XSS attack prevention by stripping user input of all code and forces web browsers to interpret that input only as data. There are several ways of encoding user input on either or both the server and client side. This method is effective, but not ideal if your web application uses rich data input other than text data.

HTML entity encoding isn’t fool proof, and may still lead to XSS exploits. If an attacker provides user input that links to an external site, they can often deliver malicious code without it being subject to encoding XSS filters. Aggressive HTML entity encoding may be an important first step for mitigating XSS vulnerabilities.

An attribute encoder will help with some malicious scripts, but it’s not the final step on our journey. As we move through the multiple layers of a web application, validation is an additional measure that helps mitigate this risk. 

What Is Validation? 

This method builds on encoding to help with XSS prevention, and it involves stripping out malicious code without eliminating all the code that may be present in user input. There are two types of validation to consider, classification and sanitization.

Classification is a method of specifying what kinds of HTML tags are allowed and which aren’t. This can be done by blacklisting or whitelisting certain commands. Whitelisting is considered to be the better method, as it minimizes what’s allowed and eliminates the potential for things to be left out of a more narrow blacklist.

Classification acts on user input as it comes in, classifying it as either acceptable or inappropriate. If input fails to meet the criteria of a whitelist or blacklist, it is simply not allowed.

Sanitization uses a validation engine to determine if specific parts of a user’s input are malicious. In the event the input is malicious the site then chooses either to reject the input or sanitize it of offending elements.

In cases where users need to rely on complex HTML, input sanitization can be the best option because it’ll allow most of a user’s code to run while blocking anything the engine deems as an offending element. An HTML sanitizer shouldn’t rely on blacklisting to identify invalid inputs, which can render sanitization ineffective. Instead, use sanitization libraries and frameworks for a thorough and more complete whitelisting approach to sanitization.

A third approach gaining traction is content security policy (CSP), which prevents any resources from executing if they aren’t from a trusted domain. Since injected scripts likely won’t be from trusted domains, they won’t be allowed to run, and the cross-site scripting attack is prevented. This helps prevent untrusted data from being submitted to your web application.

CSP shouldn’t be treated as a replacement for URL validation or URL encoding. Rather, CSP is best used as an additional layer of defense. It reduces the harm that a malicious injection can cause, but it’s not a replacement for careful input validation and output encoding.

Other approaches to XSS prevention include blocking scripts altogether, not placing sensitive data in a script tag, or in an SRC or HREF attribute, increasing cookie security to tie them to IP addresses, and forcing cookies to use the SameSite parameter in Chrome, Opera, and Firefox versions newer than November 2017.

Use GuardRails 

When in doubt, GuardRails is an option that keeps your development teams at  the forefront of cross-site scripting prevention. Whether you’re starting from scratch and implementing testing from the start, or looking to check over your current production codebase, GuardRails has the tools and just-in-time training you need to stay on track. There many ways to prevent XSS, and they’re often best combined to make the most of proper JavaScript use and reduce the chances that untrusted data be introduced into your web application.