Cross-Site Scripting

Cross-site scripting is also referred to as "XSS." XSS attackers compromise user interactions by inserting malicious scripts designed to hijack vulnerable applications. An XSS attack targets the scripts running behind a webpage that 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

The three main types of attacks that can target an XSS security vulnerability are:

• Non-persistent XSS reflected XSS, where the malicious script comes from the current HTTP request.
• Persistent XSS stored XSS, where the malicious script comes from the website's database.
• 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 as XSS security specifically nor 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 for either cross-site scripting prevention or to protect the website owner or any other 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 prevalent are cross-site scripting attacks?

Most studies show that XSS security vulnerabilities are very prevalent, affecting the vast majority of applications. Contrast Security work shows that 80% of applications have at least one XSS security vulnerability. That's a stunning result for a problem that’s been on the OWASP Top 10 list for over a decade.

Reinforcing this same cautionary note, Contrast Labs' November 2019 analysis of real-world application security data reports 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. 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 security 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 we mentioned, 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 for cross site scripting prevention. These XSS security guidelines focus on three cross site scripting 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:

• 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.
• 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.
• 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.
• 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, to prevent cross site scripting, 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 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

A web application firewall WAF is a network defense that filters, monitors, and blocks HTTP traffic to and from a web application. Unlike a regular firewall that serves as a safety gate between servers, a WAF is able to watch application-level traffic and decide to allow or disallow based on the data that is visible over the network.

Dynamic scanning DAST tools generate thousands of requests and bombard your application with them to see if they can get anything through. DAST tools can find issues that show up in webpages, but can't see anything internal to your application and don't exercise much of your code.

Static analysis SAST tools, on the other hand, try to model the entire application by guessing how all the source code, libraries, frameworks, and components fit together and will operate when run. But they make a lot of mistakes and typically don't even attempt to model the whole application.

Since both of these approaches are difficult to set up and don't get very good results, Contrast is leading the way with the next generation of application security tools known as IAST, or "Interactive Application Security Testing" tools.

The Contrast Security self-protecting approach to XSS security

Contrast Protect is a RASP solution that uses deep instrumentation to eliminate 99% of false positives, helping to secure software applications in a way far superior to legacy tools. Contrast operates from within the application and is fully aware as it moves and scales with the app, providing accurate attack visibility, monitoring, and protection.

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.

Pinpoint app attacks down to the exact line of code: A WAF can’t tell you the line of code that is being attacked, but Contrast Protect 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.

Immediately block known exploits and virtually patch newly discovered vulnerabilities: Contrast Protect becomes an essential part of the application, making application security nimble and quick, shrinking the time from “vulnerable” to “protected” even for zero day 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, such as 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.