A Step-by-Step Guide to Preventing XSS Attacks

In Q4 2020, Verizon Media blocked 1.5 billion cross-site scripting (XSS) attacks. Yes, we said billion.  

The worst part is, this statistic comes from only one technology company remediating a small portion of the attacks. The global figure would likely be impossible to calculate, especially as 80% of all hacking vectors target web apps.    

In 2017, cross-site scripting took 7th place on the OWASP Top 10 list and jumped up to third place in 2021 as part of the new Injection category. Web applications are at high risk because they have large attack vectors and are often riddled with source code vulnerabilities.

You might be tempted to think, “If XSS is such a common problem, surely I can ignore it?”, but bypassing prevention factors isn’t an option – not when user data and brand integrity are on the line. 

In this article, we’ll explain what XSS attacks are, why they’re dangerous, and what you can do to protect your business from falling victim.

What is Cross-Site Scripting (XSS)?

Cross-site scripting is a security exploit that involves injecting malicious scripts into legitimate web applications. When users click seemingly trustworthy links or pages, the malicious code executes inside the user’s browser to access their personal information and sensitive data. Everything from tokens to session cookies is at risk. 

It’s a problem that’s been hanging around since the ’90s, and nowadays 70% of all website vulnerabilities are related to XSS. This sneaky and subtle exploit has even effected major players in the tech industry like Google and Facebook.

Cross-Site Scripting vs Cross-Site Forgery

Although cross-site scripting attacks are often spoken about in the same breath as cross-site request forgery (CSRF), the two aren’t the same. Whereas an XSS attack allows the hacker to execute malicious code into the victim’s browser, CSRF involves using social engineering techniques like phishing to manipulate the victim into mistakenly executing an action. Hackers using CSRF might send a corrupted link that appears to be legitimate, such as asking the user to change their password. When the user clicks the link, the hacker gains access to their data, credentials, and privileges. 

How Do XSS Attacks Work?

XSS attacks happen when a bad actor submits malicious JavaScript code to a website via potential inject points like file uploads, form tags, and URL query strings. The victim’s browser can’t distinguish between the malicious unverifiable scripts and trustworthy sources, so it executes the script, and – boom, the attack is successful. 

This exploit doesn’t target the host webserver or the business that owns the site. Instead, it targets the users. One of the reasons why XSS attacks are so widespread is because developers neglect to properly validate and sanitize user input, meaning hackers can clearly see when a website is a prime target for XSS. There are a few different types of XSS attacks:

Reflected

A reflected XSS attack happens when the malicious code is injected into an HTTP response, which is returned in the form of an error message, pop-up window, email, or similar response. In this case, the cross-site scripting attack can be exploited as long as a reflected XSS vulnerability exists somewhere on the site and isn’t protected by a CSFR token. 

Persistent 

Also called stored XSS, persistent attacks occur when a web application stores user input and fails to validate it before embedding it into the webpage. Persistent attacks target sites that receive and store user content, such as social networks, comment sections, and CRM systems. There’s no social engineering involved – once a user visits the website, it’s game over. 

DOM-Based

DOM means document object model – in other words, the programming interface for accessing web documents. In a DOM-based attack, the malicious code is in the URL link, the HTML, or a similar source that’s controlled by the hacker in the DOM. When JavaScript runs the data, it executes the malicious code. 

What is Server vs. Client XSS?

Server XSS: The unsanitized script travels directly from the server to the webpage when it’s loaded in the browser.

Client XSS: JavaScript adds the unsanitized script to the webpage.

What Can XSS Be Used For?

Hackers who carry out a cross-site scripting attack might have multiple goals, but all of them have bad intentions. These could include:

• Accessing data such as session IDs
• Impersonating the victim to take over their account
• Stealing secrets, sensitive information, or login credentials
• Performing a Trojan horse attack
• Manipulating site behavior and modifying content
• Malicious redirects

On a bigger scale, the impact of an XSS attack on companies can be devastating. Users will believe that your website or brand is unsafe, illegitimate, or fraudulent, and they’ll stop doing business with you. Once that trust is broken, it’s extremely difficult to earn it back. You could lose visitors, clients, and integrity. 

Most recently, Microsoft Teams acknowledged and patched an XSS vulnerability that affected their sticker features. When a security researcher sent a sticker as a RichText/HTML message, the Teams platform converted it to an image, which enabled the researcher to add extra characters to the alt attribute.    

In 2020, a similar vulnerability affected one of the most famous buttons in the world: “Log in with Facebook”. A flawed implementation of the postMessage API meant JavaScript did not run URL validation, which created an opportunity for third-party plugins and hackers to run a DOM-based XSS attack. 

Are You Vulnerable to XSS?

There are two main dangers of an XSS attack. Firstly, it opens the door to further threats. Secondly, every web application is vulnerable and has a large attack vector. 

60% of all cyber attack attempts target web applications because they’re easy to hack and act as the gateway to other systems, networks, and users. Cross-site scripting attacks are most common in JavaScript, and unfortunately 98% of websites use this programming language. That leaves up to 1.8 billion applications in the spotlight.

XSS attacks are most likely to occur in web programs that incorporate unscreened user input into the outputs. Amateur (and lazy) developers skim over secure coding practices, leaving a trail of vulnerabilities that can lead to the pot of gold at the end: databases, decryption keys, servers, intranets… the list goes on. 

What’s the Best Way to Prevent XSS?

Cross-site scripting is a complex attack vector that is difficult to spot and remediate. You can protect your organization by following security best practices, and we’ll show you how in this list.

1. Sanitize Your Input 

You wouldn’t let anyone come into your house without knowing who they are first, and the same concept applies to web application security. Ensure that your website receives only trusted and authorized data by implementing strict filters for user-generated input, removing any input that’s used as part of HTML output, and taking a zero-trust approach. Validation and verification are crucial. 

2. Use Output Encoding

An attacker could modify data, meaning you should use output encoding to ensure data is displayed exactly as a user typed it. This prevents it from being interpreted as authenticated and active content and subsequently added to a webpage. The next challenge is to choose the right encoding method, whether that’s HTML, URLs, CSS, or a combination. 

3. Whitelisting vs Blacklisting

The OWASP recommends taking a whitelisting vs blacklisting validation approach to protect against XSS attacks. Whitelisting means only allowing specific addresses, applications, websites, or devices (that you’ve verified as “good”) to access your networks. It works by verifying whether data matches your predetermined “good” rules. Blacklisting validates the data by checking it for “known bad” content, acting in a similar way to antivirus software. 

4. Allowing “Safe” HTML Only

HTML sanitizing means applying HTML attribute encoding to change a hyperlink, add image alt-text, or hide an element, as per the OWASP’s recommendations. You can further prevent an XSS attack using this strategy by placing the variables in quotation marks, which makes the encoding easier to do. 

5. Use a Content Security Policy (CSP)

A content security policy HTTP response header restricts the scripts and images that a webpage can load. It works by whitelisting approved URLs and only allows JavaScript files that are loaded from a trusted, uncorrupted host. One thing worth noting is that a CSP doesn’t protect against all external domains and doesn’t prevent web applications from containing vulnerabilities, so it should be used as a second-degree measure. 

6. Use Proof of Source Authenticity (PoSA)

80% of users hesitate to click on company communications because they’re worried it might be a scam. As well as protecting against cross-site scripting attacks, you need to give your clients visible proof that your links, SMS, and webpages are legitimate. Memcyco’s PoSA creates personal digital watermarks and stores them in the user’s local protected storage, so the mark will appear on your website when a user visits it. Every digital watermark comprises four elements:

• Personalized passphrase
• Brand logo
• Help and personalization button
• Personalized 3D animation 

Adopting PoSA technology doesn’t just give your business an extra layer of authenticity. It also protects you and your clients from exploits like phishing, counterfeit sites, spoofing, and other impersonation attacks.

You can install Memcyco’s PoSA solution by inserting one line of JavaScript code to your site’s HTML file, then you’re good to go. 

A Paradigm Shift in Digital Authentication

Unfortunately, the fact that cross-site scripting attacks are so widespread doesn’t dilute their danger. Even one XSS attack can result in hackers gaining access to sensitive data, networks, and systems, causing losses for you and your clients. By following the best practices outlined in this blog, you can feel confident that you’re minimizing the risk of an attack. 

For further resources, we recommend OWASP’s Mutillidae 2 Project. If all the above info leaves you needing a stiff drink and some light entertainment, why not learn how to identify and mitigate XSS attacks in Google’s online game? 

At Memcyco, we share your vision to protect your business and clients from brand exploits, so you can transact and interact digitally with full confidence. To read more about our cutting-edge PoSA solution, take a look at our website. 

Eyal Katz

Eyal is head of demand generation at Memcyco