Cross-site scripting attacks are web application and web server exploits that occur because of a vulnerability in the server or application code. They’re particularly dangerous because it’s difficult for security or development teams to see an XSS vulnerability, and it’s also hard to see the effects of an attack until the ensuing breach is well underway. To prevent XSS attacks, your team needs to know what they look like and whether your systems are vulnerable to them.
How Does Cross-Site Scripting Work?
A cross-site scripting attack occurs when a threat actor injects malicious code, or script, into a web application’s page code. This typically happens on dynamic web pages, which frequently change or can be actively manipulated by users (for example, a search bar where users can type queries).
The original code of the web page is trusted. Typically, when a user navigates to the web page, their browser loads the web page as instructed. But if a threat actor has added new code to the web page, it might not load the way it was originally intended, and the user and browser are none the wiser. The new malicious code is designed to steal data — like cookies or credentials — from that web application.
Cross-site scripting attacks are dangerous because they’re challenging to detect. The vulnerability exists in the code, and security teams won’t be able to see that unless they know the programming language in which the page is written. Often, you’ll need to use application scanning software to find indicators of an XSS attack. Finding one manually requires too much manual work, and employees might miss it, especially if they don’t know the language.
If your web application falls victim to an XSS attack, it could be a stored, reflected, or document-object-model (DOM)-based attack. XSS attacks have multiple security and business risks, including credential theft and damaged company reputation. To learn whether you’re vulnerable, you should conduct testing on your web apps, stay alert for clear signs of an attack, and use software solutions to look for vulnerabilities in your code and apps.
3 Common Types of Cross-Site Scripting Attacks
Stored XSS, reflected XSS, and DOM-based XSS are the three most common types of cross-site scripting attacks. They differ in whether they affect the server or client side of the web application.
Stored XSS
In a stored XSS attack, the malicious script is written into the actual code of the web application, affecting both the client side and server side. It resides permanently in the code of that server or application until it’s eradicated by admins or an automated security solution. Stored XSS is a consistently severe XSS attack because the malicious code always exists in the application.
For example, if a threat actor writes a malicious script on a financial services company’s web server on a page where users input their financial data, the threat actor can steal that data every time someone uses the page. Because the malicious code is written in the web server, it affects each instance of the web application’s use. Users don’t know the code on the financial services web page is malicious because it looks legitimate, and they continue using it until it’s exposed.
Reflected XSS
Reflected XSS is named because an attacker injects malicious code into a URL or request parameters and the response from the web server reflects that injected code. Reflected XSS isn’t stored long-term in the back end of the application or server code. The attack is performed within the bounds of the user’s input, like the URL or request parameters. Reflected XSS can be severe if an attacker uses it to steal session cookies or user credentials.
An example of reflected XSS would be a threat actor intercepting a software engineer’s request parameters to access a popular engineering application. The threat actor changes the URL subtly, which means the user goes to a vulnerable web page instead of the legitimate one they expected. From there, the threat actor can take multiple actions to compromise the engineer’s work, like stealing the information they input on the page.
DOM-Based XSS
In a DOM-based XSS attack, the attacker manipulates the document object model (DOM) of the user’s browser. The actual code of the web application itself doesn’t change on the server side, but it executes maliciously on the user’s side. DOM-based XSS is particularly hard to detect because the changes occur on the client side within the document object model and may never touch the web server.
For example, if an attacker steals pieces of a URL and uses them in a JavaScript function that allows dynamic code execution, that attacker could manipulate the client-side code of a web app. If the attacker chooses to manipulate a customer relationship management (CRM) product’s main page, the actual HTTP response of the page won’t be different, but the client-facing code will be. The threat actor could launch an attack using the URL fragments.
Top 5 Risks Associated with XSS Attacks
Cross-site scripting attacks are notoriously challenging to find because they masquerade as legitimate web page behavior. They also enable threat actors to steal your web app credentials and session cookies, and they can cause general hiccups in standard business processes as well as damage your business’s reputation.
XSS Attacks Are Hard to Detect
Because XSS attacks manipulate perfectly legitimate web application processes, they’re challenging to detect. Also, XSS attacks often involve a specific type of code, commonly JavaScript. Even a security or dev admin may not know how to mitigate the attack if they don’t know the programming language in which the attack is written, and that’s assuming they realize an XSS attack happened in the first place.
Attackers Can Steal Your Credentials
In one of the worst-case XSS scenarios, a threat actor can steal credentials once the user inputs them into a web page they don’t realize has been hacked. First, the threat actor has to compromise a web page where users log into a service or application. Then they must successfully log in and steal the code that the user enters so they can reuse it to log into the app themselves, ideally without being noticed.
If the account is a high-privilege account, this is even more dangerous. It’s possible the attacker could escalate their privileges after stealing one set of credentials and then access more sensitive data.
Attackers Can Hijack Session Cookies
An attacker can inject a script into a website vulnerable to XSS and use files to steal session cookie information. If they set the script to steal the session data without the user noticing anything alarming, they won’t even tip off the user that an attack has happened.
When someone steals session cookies, they can repeat a web page session, which means they could potentially access that application’s sensitive data and make modifications to the web app. This attack is similar to a credential theft attack and could lead to a similar situation if the cookie has stored login information.
XSS Attacks Are Time-Consuming & Irritating
If an XSS attack brings a page down or causes it to redirect to the wrong window, this creates a headache for not only your business’s IT department but also for every other user who needs to use the page. This is particularly true for web applications that are essential to business operations and that employees frequently access. If the page isn’t working for a long time, that’s not only an irritation and interruption but also a threat to critical organizational processes.
Successful Attacks Can Damage Your Business
If a web page goes down or even if a threat actor falsifies the page’s content, the damage to your business could be severe. A web application behaving strangely affects that application’s reputation, as well as the reputation of the organization that runs it. If an attacker gains access to a privileged account, they could even compromise sensitive customer data. Falsified content would be a more rare type of attack, but it’s not impossible for a highly skilled threat actor.
If you’re concerned about the effects of a web application attack on your broader business network, read more about network security.
How to Tell if You’re Vulnerable to XSS Attacks
While it’s challenging to immediately know that you’ve been attacked, there are still steps your security and IT teams can take to educate themselves on cross-site scripting. To determine whether your business’s web servers and applications might be vulnerable to XSS, test them, watch for the more obvious signs, and continually assess security vulnerabilities.
Perform Testing or Hire a Pentester
If you have experienced security or IT personnel, you can certainly perform tests on your own code for web servers and web applications. Following guidelines from expert security bodies like OWASP is a good starting point for protecting your systems from XSS.
It’s also valuable to hire a penetration tester. Pentesters are specifically contracted to breach your systems and reveal vulnerabilities. If you contract one to focus on web applications and code vulnerabilities, you’ll be more likely to learn whether your web pages are vulnerable to XSS.
Read more about dynamic application security testing, a beneficial tool for uncovering vulnerabilities in web applications.
Watch for Obvious Attack Signs
Many XSS attacks won’t be evident, but keep an eye out for the more glaring signs that one’s happening. If your web pages are redirecting improperly or a seemingly authenticated user suddenly starts making odd changes within a privileged web app, that’s your cue to look more closely at the web page’s code. While few attacks will be obvious, watch carefully for those that are.
Regularly Scan for Vulnerabilities
Perform frequent vulnerability scans on all of your infrastructure, but to find XSS vulnerabilities, scan your web applications in particular. Vulnerability scanning tools take patterns into consideration, pinpointing issues that security teams don’t have time to locate manually. Some vulnerability scanning tools also pull information from databases or libraries that hold common threat signatures or indicators, helping you find them in your own systems and apps.
Read about our picks for the best web and application vulnerability scanners, as well as the criteria you should consider for a scanner.
Can You Prevent Cross-Site Scripting?
It’s possible for businesses to prevent cross-site scripting, but it’ll require your security and web application development teams to dedicate themselves to good security practices. They’ll need to:
- Regularly check application code for issues: Analyze code throughout the development lifecycle to determine whether your code has vulnerabilities.
- Encode output and validate input: Encode data as it’s written to a web app, and validate and sanitize user code input before sending it to the browser.
- Use advanced security tools: Web application security software is designed to protect web apps and is especially useful for preventing XSS.
- Teach good DevOps practices: All web developers should know about XSS attacks and how to reduce them by creating strong, secure code.
Read more about preventing XSS attacks, including real examples of attacks and tools that can help your business.
Frequently Asked Questions (FAQs)
What Is a Real-World Example of XSS?
In 2018, British Airways was attacked by a group of hackers that used an XSS vulnerability in a JavaScript library. The hackers sent customer data to a server that was attempting to impersonate British Airways’ domain name. Before anyone learned about the attack, the hackers skimmed credit card data from over 350,000 transactions. This is a good example of how long it can take to detect an XSS attack.
What Can Hackers Do with XSS?
While attackers can use XSS to steal data and cookies, they may have less damaging purposes, too. An attacker could use cross-site scripting to stall a competing website’s performance or to add inappropriate content to a legitimate page. Reputation damage is still harmful, however.
What Is the Root Cause of XSS Attacks?
Cross-site scripting attacks occur because the content of a web application request hasn’t been properly validated. While it’s difficult to tell whether your web code is vulnerable to XSS, there are ways that dev and security teams can tighten those security gaps, like by validating all inputs before sending a user request to the web browser.
Bottom Line: Cross-Site Scripting Endangers Data, Applications & Business Reputation
Cross-site scripting attacks put web applications and servers at risk and create challenges for security and web dev teams, who may not even know they’re vulnerable. But although humans’ ability to find vulnerabilities in code and spot breaches is limited, using automated security solutions — like vulnerability scanners and application security testing tools — helps.
You should test web application code and create secure development pipelines so vulnerabilities are less likely to crop up during the development process. Although preventing XSS vulnerabilities and attacks may seem overwhelming, taking care of your code and investing in automated security solutions will help protect your web applications in the long run.
If you’re interested in learning more about security for other applications, not just web apps, read about the different types of application security. These include security for cloud apps, mobile apps, and data and enterprise apps.
