Why XSS is still an XXL issue in 2021

Cross-site scripting (XSS) attacks take advantage of coding flaws in the way websites or web applications generate input from users. Despite their longstanding reputation as a significant infosec problem, XSS attacks have remained a constant of the OWASP Top 10 Web Application Security Risks year after year and still make headlines.

In fact, earlier this year researchers uncovered a severe XSS vulnerability in the WordPress search plugin called Ivory Search. This now-patched bug left 60,000 websites open to malicious code injection. As you can see, XSS attacks are still a major concern for organizations and individuals alike, so let’s explore how they work and best practices for addressing them.

How XSS attacks work

Many of today’s websites and applications dynamically gather and display data from each individual visitor. Think of a comment section on a blog or a review section on an e-commerce website where anyone can add content that gets displayed to other visitors. If the web application developer hasn’t added some form of sanitization to the visitor’s input before displaying it on the page, anyone could add to it more than just plain text. A bad actor could abuse these input mechanisms to inject and run malicious JavaScript that would be hidden to users and appear as part of the legitimate site or application to browsers.

This allows attackers to access anything on the website or application that the user could. For instance, if an attacker found an XSS flaw on Amazon.com, they could leverage it to access all your personal Amazon data, including things like your profile data, but also technical elements like your authentication session cookie, which they could then use to log in as you. In essence, the attacker could do and access anything on Amazon as if they were you, all without your knowledge that the script was running.

There are two primary types of XSS vulnerabilities:

• Persistent XSS vulnerabilities: Attackers use these flaws to “store” or “add” a malicious script to a page of your site or application forever (i.e., until a developer finds and removes it). Anyone visiting that “infected” page runs the malicious script. Persistent XSS flaws are the most severe, as they can affect every visitor and may require no interaction other than visiting a malicious page.
• Reflected XSS vulnerabilities: These flaws only affect one user at a time and require the user to click a specially crafted link. Malicious scripts for reflected XSS attacks don’t exist on your web application or site forever. Instead, attackers use embedded links with which victims must interact, and then only run in that user’s browser. They can have the exact same impact as a persistent XSS flaw but are less severe since the script isn’t embedded in your web application and requires actual user interaction to succeed.

Years ago, XSS vulnerabilities were mostly present in web application “surface” inputs, such as in the type of form fields where sites may ask visitors to enter their names, email addresses, credit card info, or ZIP code. Now that web developers better understand XSS attacks, they generally do a pretty good job of sanitizing those obvious input mechanisms. However, there are many subtle website input mechanisms that developers may not think of as “user-controllable.” For example, when you upload a picture, a web application may parse that picture file for its metadata.

Technically, all that metadata is an “input mechanism” to the web application that developers may not think to sanitize. But clever attackers can edit the metadata to include their malicious script. In short, many web applications have become much better at protecting obvious input mechanisms, but many others are easy to overlook and thus represent enticing targets for sophisticated attackers.

The impact of remote work

The rapid increase in the remote workforce brings with it many new security challenges, but XSS risks haven’t changed dramatically as a result. Though XSS vulnerabilities directly impact the visitor of a web application, they reside in the web application (the website) itself. That said, as organizations had to quickly shift to enabling remote work, many chose to expose previously internal web applications to the internet or sign up for new cloud services.

Adversaries took note of this increase in attack surface. We’ve tracked a steady increase in network attacks like XSS exploits targeting web apps and other exposed resources since the start of the pandemic in our Q4 2020 Internet Security Report, and the gradual reopening of offices hasn’t stopped that growth.

XSS detection

The onus for detecting and addressing XSS vulnerabilities is ultimately on the website or application owner(s). The best technical solution for detecting XSS attacks against your website or application is a web application firewall (WAF).

WAFs are differ from typical network firewalls and they can monitor all the specific input parameters of your web application. They learn the types of inputs your web application is supposed to collect (a ZIP code should always be five numerals, or five numerals with a dash and four subsequent numerals, etc.). If they detect any unusual input into a parameter that doesn’t match, they can either flag or prevent it.

XSS prevention

The best XSS prevention tip is to use secure code on your websites and applications. This is simple and complex at the same time, but in general involves two steps. Step one is to ensure whatever web code frameworks you’re using are up to date. You probably didn’t design all the code on your webpage yourself and are using various web frameworks. Unfortunately, web framework creators can and do make secure coding mistakes, and their code can introduce XSS flaws, so you must vet the ones you use regularly and always use the latest updates to resolve potential vulnerabilities.

Second, even if you are using existing web frameworks, you likely have a lot of custom code on your site or web application. That means you and your web developers need to follow secure web coding practices to ensure your code doesn’t introduce these vulnerabilities. Secure web coding is a deep subject, but your developers should use the many resources available from OWASP and others.

It’s also important to note that many web applications expose web APIs and that attackers are actively pursuing vulnerabilities there as well. For example, the recent Exchange Server Hafnium attacks technically started with an attack against the server’s API. As such, you can’t afford to overlook API security.

OWASP has an entire project dedicated to API security as well, so consider checking out their guides or leveraging modern security controls that combine web application and API security together (WAAP – web application & API protection).

Avoid crossing paths with XSS attacks in 2021

The list of XSS vulnerabilities is long, and there’s no sign these attacks will disappear any time soon. Use the above tips and best practices to avoid an XSS-caused incident in 2021 and remember that while technical defenses such as WAFs can help mitigate your exposure and protect your visitors and customers, strong coding hygiene is your first and best line of defense.