Cross-site scripting attacks — also known as XSS attacks — are one of the most pervasive cybersecurity threats that websites and web apps face today. Most types of XSS attacks are relatively easy to execute, and they can have devastating consequences for affected users — not to mention for businesses whose applications or websites serve as vectors for XSS risks.
That's the bad news. The good news is that, as this article explains, it's possible to protect your website or app against XSS attacks, provided you understand how XSS attacks occur and which mitigation methods are available to stop them.
What Are Cross-Site Scripting Attacks?
Cross-site scripting attacks are a type of attack in which threat actors inject malicious scripts into websites. From there, the scripts are executed within the browsers of affected users. Because XSS attacks make it possible to plant malicious code on websites that are otherwise trustworthy, it can be easy for users to fall victim to this type of risk.
There are three main types of XSS attacks:
- Non-persistent or reflected XSS attacks: In this type of XSS attack, threat actors "trick" users into running malicious code by convincing them to click a specially formatted URL. The URL typically points to a trustworthy site, but it contains malicious code that, if undetected, will be executed inside the user's browser. The malicious code is often obfuscated within the URL, making detection of this type of XSS breach more difficult.
- Persistent or stored attacks: This type of XSS attack happens when malicious actors find a way to inject code into a third-party website or web application. For example, they may take advantage of a known vulnerability within a content management system (CMS) or forum hosting platform that allows them to upload JavaScript through a publicly accessible form. From there, the malicious code is served to users who visit the compromised site and run inside the users' browsers.
- DOM-based XSS attacks: This type of XSS attack, which is the hardest to execute but also the hardest to detect, modifies the Document Object Model (DOM) of a web page in order to inject malicious code.
What Is the Impact of Cross-Site Scripting Attacks?
Although each type of XSS attack relies on a different attack technique, all XSS attacks can have a wide set of negative impacts on users, such as:
- Data theft: Malicious scripts that run inside users' browsers could steal sensitive user data that is stored in the browsers.
- User impersonation: In some cases, XSS attacks can be used to steal cookies from active web sessions. In turn, attackers can impersonate users and gain access to any personal data that the users store in websites or web apps. Attackers could also potentially modify or delete users' data.
- Website redirects: Injected scripts could redirect users to malicious sites. If users don't realize that they've been redirected, they may be tricked into entering sensitive information into the malicious site because they think it's the trustworthy site they intended to visit.
- Defacing websites: Attackers occasionally use XSS attacks to modify the appearance of websites by running scripts that change what the user sees when the site loads. In this way, XSS attacks can be used to deface websites and harm the brand of affected businesses.
Thus, it's not just individual users who can be harmed by XSS attacks. Businesses, too, have a lot to lose if users of their websites or web apps are harmed by XSS attacks.
Myths About XSS Attacks
It can be easy to assume that XSS attacks won't affect your website or web app because of myths such as the following:
- XSS attacks are not that common.
- XSS attacks only target small websites.
- XSS attacks aren't serious.
- XSS attacks are difficult to execute.
Some teams fall victim to these myths because they believe that, since XSS attacks only involve malicious code running on individual devices that contain limited amounts of user data, they're not as severe as breaches that compromise servers that store vast amounts of sensitive information. Or they may believe that XSS attacks are very easy to detect, so attackers only target websites owned by small companies that lack serious cybersecurity defenses.
The reality, though, is that XSS attacks are a pervasive threat. Hundreds of known XSS attacks occur each year (and those are only the attacks that are publicly disclosed), and their frequency has been steadily rising for the past half-decade. Even companies that invest as heavily in cybersecurity as Google and Microsoft have fallen victim to XSS vulnerabilities inside their applications.
So, if you think XSS attacks can't affect you or your business's software, think again.
Common Methods for Protecting Against XSS Attacks
There are four main layers of defense that developers and admins can use to protect against XSS attacks: writing secure code, scanning apps for XSS risks, hardening environments against the chances of successful XSS attacks, and mitigating XSS risks at the network level.
Secure coding to prevent XSS attacks
First and foremost, engineers should endeavor to write websites and web applications that are free from the types of risks that allow XSS attacks to happen.
This means, above all, ensuring that any input that a site accepts is properly filtered and validated. Unrecognized strings, code, or scripts within the input should be ignored. It's better to return an error message to the user because input couldn't be interpreted properly than it is to accept the input and run the risk that it contains malicious code.
Writing applications so that they encode any data that they generate in response to user input can also help prevent XSS risks. Encoding means translating the data from HTML or JavaScript into an entity that can't be executed. That way, if the output contains malicious code, the browser won't actually run it.
Application scanning to detect XSS risks
After writing applications, developers should deploy scanners that can identify XSS risks. There are several free XSS scanners available on GitHub, and some commercial software composition analysis (SCA) tools provide XSS scanning features as well.
Remember, too, that it's not just in code you write yourself that XSS risks can appear. They can also be imported through third-party modules or dependencies that you build into your application. For that reason, it's important to create an inventory of your application's dependencies and ensure that they are not subject to known XSS risks. SCA tools can help with this task, too.
Environment hardening against XSS
Environment hardening means designing application hosting environments — and, to the extent possible, end-user environments — in such a way that XSS attacks will be difficult to execute successfully.
On the server side, you can do this by ensuring that web applications and server software are continuously updated. Updates help protect against software vulnerabilities that attackers could exploit to launch XSS attacks — especially persistent XSS attacks, which usually exploit vulnerabilities within server-side software to inject malicious code.
On the client side, web browsers should be kept up-to-date. This is important because modern browsers are designed to intercept and block malicious code before they run it. Keeping browsers up-to-date ensures that users have the latest XSS-detection software available to them.
Of course, it's not always possible to control which browsers users run. If you develop a public website or app, your users may use a variety of browsers, and you have no real ability to force them to keep their browsers updated. But in an internal business environment, IT organizations can usually require certain browser configurations on employees' devices in order to reduce the risk of XSS attacks.
Network-level XSS protection
At the network level, Web Application Firewall (WAF) platforms can be used to detect some types of XSS attacks. To do this, you must configure your WAF to inspect traffic and block data that contains common XSS attack signatures, such as URL requests that include obfuscated code.
Network-level XSS protections are useful because they can protect both servers and clients from XSS risks in many cases. However, it's important to keep in mind that XSS attacks that don't leverage common attack techniques will typically evade network defenses because WAFs won't recognize them.
What to Do if Your Site Is Vulnerable to XSS
What if you discover that your website or app is vulnerable to XSS attacks, and that the attacks have possibly already been occurring?
Obviously, the most important thing to do is to make sure you determine the root cause of the XSS vulnerability and work to resolve it. But you should also take steps to mitigate the impact of the risk:
- Change user passwords: Since XSS attacks could be used to steal user credentials, requiring password changes is one way to reduce the impact of an XSS vulnerability after it's discovered.
- Notify users: You should also notify users who may have been affected by the attack. The attack could have led to the loss of sensitive information associated with outside websites, not just your site, so requiring users to change the passwords just for your site is not enough.
- Monitor for unusual activity: Scan your network and your server-side environment for activity that could be the sign of a breach or continuing attack. If threat actors managed to inject scripts into one part of your site, there is a decent chance they have compromised other parts of the site, too, so you'll want to understand and address the full scope of the breach before you can consider the XSS attack to be contained.
Conclusion
Cross-site scripting attacks are a major risk to any business that develops websites or web apps today. To protect against XSS, teams should deploy a multilayered defense that starts with avoiding coding flaws that enable XSS attacks to happen in the first place, and that extends to protections within application runtime environments and the network to defend against XSS.
About the author
Christopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” was published by MIT Press.
