Skip to content

Protect Your Applications from Cross-Site Scripting (XSS) Attacks

Implement robust security measures to safeguard your application's integrity

Mockup XSS Demo

What is Cross-Site Scripting?

"Cross-site scripting" originally referred to loading the attacked, third-party web application from an unrelated attack-site, executing JavaScript in the security context of the targeted domain where cross-site data theft was the focus. The definition of Cross-site scripting now includes other modes of injecting malicious code within trusted websites.

How Contrast Helps

  • Understand  how an XSS attack can occur
  • The importance of early detection in the development lifecycle
  • Using real-time feedback and runtime application self-protection features
Watch demo video

How is Cross-Site Scripting executed?

Attackers compromise user interactions by inserting malicious scripts designed to hijack vulnerable applications. An XSS attack targets the scripts running behind a webpage which are being executed on the client-side (in the user’s web browser). Because the unsuspecting browser has no way of knowing that a script should not be trusted, it will go ahead and execute the XSS script, which can access cookies, session tokens, and other sensitive information retained by the browser and used with that site. In short, cross-site scripting (XSS) allows the attacker to “commandeer” HTML pages, deceive users, and steal sensitive data as it assumes control, redirects links, and rewrites content on that site.

Types of Cross-Site Scripting attacks

There are three main types of attacks that typically target an XSS security vulnerability:
  1. Non-persistent XSS reflected XSS, where the malicious script comes from the current HTTP request.
  2. Persistent XSS stored XSS, where the malicious script comes from the website's database.
  3. DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code

Reflected XSS attacks, also known as non-persistent attacks, occur when a malicious script is reflected off of a web application to the victim's browser. The script is activated through a link, which sends a request to a website with a security vulnerability that enables execution of malicious scripts.

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping.

DOM-based XSS is a kind of XSS occurring entirely on the client-side. A DOM-based XSS attack is possible if the web application writes data to the Document Object Model without proper sanitization. The attacker can manipulate this data to include XSS content on the webpage, for example, malicious JavaScript code. The attacker embeds a malicious script in the URL; the browser finds the JavaScript code in the HTML body and executes it. JavaScript sources are functions or DOM properties that can be influenced by the user, but vulnerable JavaScript sources can be exploited for a DOM-based attack.

JavaScript is designed as an open scripting language. It is not intended to replace proper security measures, and should never be used in place of proper encryption. JavaScript has its own security model, but this is not designed to protect the website owner or the data passed between the browser and the server.

How does Cross-Site Scripting work?

The cross-site scripting attack is made possible by an XSS security vulnerability brought about by inherent security weaknesses in client-side scripting languages such as JavaScript and HTML. By injecting a malicious client-side script into an otherwise trusted website, scripting XSS cross-site tricks an application into sending malicious code through the browser, which believes the script is coming from the trusted source. It then deceives users by manipulating scripts so that they execute in the manner desired by the attacker.

Cross-site scripting vulnerabilities typically allow an attacker to masquerade as a victim user in order to carry out any actions that the user is able to perform and access any of the user's data; capture the user’s login credentials; perform virtual defacement of the website, changing its messaging, look and feel; inject trojan functionality into the website, creating a backdoor that gives malicious users access to the user’s system.

The XSS attack works by manipulating a website vulnerability such that it returns malicious JavaScript code to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise the user’s interaction with the application. If the victim user has privileged access within the application, the attacker might be able to gain full control over all of the application's functionality and data – a “worst case” application security scenario.

How Contrast Helps

  • Understand how an XSS attack can occur
  • The importance of early detection in the development lifecycle
  • Using real-time feedback and runtime application self-protection features
Watch demo of XSS attack protection

How prevalent are Cross-Site Scripting attacks?

Many research reports indicate that XSS vulnerabilities are very prevalent, affecting the vast majority of applications. Contrast Security research finds that 80% of applications have at least one XSS vulnerability. That's a stunning result for a problem that’s been on the OWASP Top 10 list for over a decade. 

Supporting this same cautionary note, Contrast Labs' November 2019 analysis of real-world application security data reported that:

The most prevalent serious vulnerabilities across the applications observed were Cross-Site Scripting (XSS), Arbitrary Server Side Forwards, and Cross-Site Request Forgery.
The most common attack types were SQL Injection, Cross-Site Scripting (XSS), and Path Traversal for the third month in a row.

How serious can Cross-Site Scripting attacks be?

XSS vulnerabilities are common enough to have affected application security at companies as large as Facebook, Google, and PayPal - as an internet search would show. XSS vulnerabilities are especially dangerous because an attacker exploiting an HTML or JavaScript vulnerability can gain the ability to do whatever the user can do, and to see whatever the user can see – including passwords, payments, sensitive financial information, and more. What makes the XSS attack even worse is the fact that victims, both the user and the vulnerable application, often won’t be aware they’re being attacked.

  • Serious impact: Attacker gains access to an application holding sensitive data, such as banking transactions, emails, or healthcare records.
  • Critical impact: The compromised user has elevated privileges within the application, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

Finding XSS vulnerabilities

To prevent XSS attacks, the first step is to spot common XSS vulnerabilities. Cross-site scripting (XSS) is really pretty simple. Any time untrusted data ends up on an HTML page without proper validation and escaping, you have a problem. So when a developer takes JavaScript or an HTTP request parameter and it finds its way through the code into an HTML page, the result is XSS – unless the data is properly validated and escaped.

Cross Site Scripting prevention and XSS security

As explained above, XSS attacks occur when data enters a web application through an untrusted source, most frequently a web request. XSS can also occur when data is included in dynamic content that is sent to a web user without being validated for malicious content.

OWASP has published a cheat sheet that can be used to prevent XSS attacks. These XSS security guidelines focus on three prevention strategies – escaping, validating input, and sanitizing.

In general, cross-site scripting prevention is likely to involve a combination of the following four XSS security measures:

  1. Filter input on arrival: At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
  2. Encode data on output: At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
  3. Use appropriate response headers: To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
  4. Use Content Security Policy: As a last line of defense against attackers, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
And most importantly, never accept actual JavaScript code from an untrusted source and then run it.

Content Security Policy

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking, and other code injection attacks resulting from execution of malicious content in the trusted webpage context. It is a Candidate Recommendation of the W3C working group on Web Application Security, widely supported by modern web browsers. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website.

Finding XSS problems

Spotting most XSS vulnerabilities is simple. You just have to find the input that flows from an untrusted source into an HTML page. Many times, the path from the request to the HTML page isn't very complicated, for example when the same call gets the data and puts it in the HTML page.

But, other XSS vulnerabilities are less common and can be devilishly complex. Imagine an application that has millions of lines of code involved in getting data, transforming it, validating it, storing it, combining it, escaping it, decoding it, persisting it, retrieving it, and finally rendering it. How can one know if there is a path through all that code that creates an XSS vulnerability?

The number of possible paths and patterns is infinite, and that's why traditional tools struggle to find XSS without flagging a lot of false alarms.

Traditional approaches

Spotting most XSS vulnerabilities is simple. You just have to find input that flows from an untrusted source into an HTML page. Many times, the path from the request to the HTML page isn't very complicated, for example when the same call gets the data and puts it in the HTML page.

But other XSS vulnerabilities are less common and can be devilishly complex. Imagine an application that has millions of lines of code involved in getting data, transforming it, validating it, storing it, combining it, escaping it, decoding it, persisting it, retrieving it, and finally rendering it. How can one know if there is a path through all that code that creates an XSS vulnerability?

The number of possible paths and patterns is infinite, and that's why traditional tools struggle to find XSS without flagging a lot of false alarms.

The Contrast Security self-protecting approach to XSS security

Contrast offers a platform-level, instrumented security approach that addresses the three main shortfalls of traditional application security solutions:

  1. removes security bottlenecks from application development,
  2. reduces the noise of false positives generally caused through traditional scanning tools, and
  3. scales security wherever an application exists across its life span without specialized security training and staff.

    Because security is instrumented within the application, through the Contrast Assess solution, it also provides runtime observability of application code in production to protect both known and unknown vulnerabilities from being exploited - including XXS attacks.

Any time untrusted data ends up on an HTML page without proper validation and escaping, that fits the definition of cross-site scripting. Contrast takes the innovative approach of simply tagging and tracking untrusted data wherever it goes within the application. Contrast also tracks all the validation and escaping that happen to that data along the way. Then anytime data gets written to an HTML page, you know if it's an XSS problem, because Contrast reports the vulnerability along with all the details.

How is Contrast solution different to a WAF solution: Contrary to a WAF solution, Contrast pinpoints application attacks down to the exact line of code. A WAF can’t tell you the line of code that is being attacked, but Contrast can. Unlike WAFs or external scanners, Contrast analyzes and protects applications from within by integrating security safeguards into the running application making it self-protecting.

That same Contrast Agent used to instrument the application, is also used to protect it in runtime through Contrast Protect - our RASP solution. Contrast Protect immediately block any exploits, whether known or zero-day, and virtually patch newly discovered vulnerabilities.

Therefore, the Contrast platform-level approach becomes an essential part of any  application security program - making application security nimble and quick, shrinking the time from “vulnerable” to “protected” even for zero-day attacks.

How Contrast Helps

  • Understand how an XSS attack can occur
  • The importance of early detection in the development lifecycle
  • Using real-time feedback and runtime application self-protection features
See how Contrast protects against XSS attacks

Moving to Next-Gen Security

Most of the tools available to secure software applications (SAST, DAST, and WAF) were invented over a decade ago, and as such, their legacy underlying core technology prevents them from evolving to keep up with modern software movements like Agile and DevOps. What the enterprise needs in this new era is software which is self-protecting, that is powered by both Interactive Application Security Testing (IAST) and Runtime Application Self-Protection (RASP).

Gartner defines RASP as “a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.”

RASP provides a level of visibility and accuracy that network security solutions simply cannot achieve. Instead of monitoring the application for potentially malicious inputs, RASP only processes inputs that could change the behavior or operation of the application. This approach has the potential to increase accuracy without significantly impacting app performance.

Because RASP solutions incorporate security into the running application wherever it resides on a server, it is able to detect, block, and mitigate attacks immediately, protecting applications as they run in real-time by analyzing both application behavior and context. By using the app to continuously monitor its own behavior, RASP has the ability to protect an application from malicious inputs and behavior such as XSS and injection – without human intervention.

Contrast Security is the world’s leading provider of security technology that enables software applications to protect themselves against cyberattacks, heralding the new era of self-protecting software. Contrast's patented deep security instrumentation is the breakthrough technology that enables highly accurate assessment and always-on protection of an entire application portfolio, without disruptive scanning or expensive security experts. Only Contrast has sensors that work actively inside applications to uncover vulnerabilities, prevent data breaches, and secure the entire enterprise from development, to operations, to production.

Contrast is the clear customers’ choice

Contrast is named a Customers’ Choice in the 2021 Gartner Peer Insights “Voice of the Customer”: Application Security Testing report. With the highest percentage of 5-star ratings, this is the third consecutive year Contrast has received this powerful endorsement from customers.

gartner-peer-insight-2021

Built for Developers. Trusted by Security.

Infosys
ring-central-logo
bmw-logo-2020-grey-1
backbase-logo
intuit
credit-suisse

Learn Secure Code

Cross Site Scripting (XSS)

Cross Site Scripting (XSS)

Learn about Cross site scripting (XSS) and how it affects your Java source code

SQL Injection - Java-1

SQL Injection

Learn about SWL injection and how it affects your Java source code

Client Side Injection

Client Side Injection

Learn about client-side injection and how it can affect your source code