Cross-site scripting with Script Gadgets

Cross-site scripting (XSS) is one of the major problems of the World Wide Web. From the first public documentation in 2000 until today, XSS is one of the most common vulnerabilities of websites. In an XSS attack, the hacker inserts HTML and/or JavaScript code into the website, which is then executed and can cause damage. Learn more about protective measures – and why many of them are no longer enough.

The four common measures to protect against XSS

Despite awareness and even though web developers are already addressing the issues in the source code, the number of undiscovered XSS risks remains large.

Therefore, as a second line of defense, there are four measures to prevent vulnerabilities from being exploited:

• HTML Sanitizer: Libraries used by web developers convert untrusted HTML to secure HTML. Examples include DOMPurify and Google Closure.
• Browser-based XSS filters: The filters are part of the browser navigation and display. The Chrome, Edge, and Internet Explorer browsers include such filters, and the NoScript addon is available for Firefox. The filters are designed to detect and block XSS attacks.
• Web Application Firewalls: this software runs on the server and is supposed to block malicious requests. ModSecurity is an example of an open-source web application firewall.
• Content Security Policy (CSP): This browser feature can be configured by the web developer to specify which JavaScript code belongs to the application and is executed by the browser.

Most of these techniques focus on script tags and event handlers. The protection measures are based on the following three strategies:

1. Filter requests: HTTP requests are blocked before they reach the application. Filters such as NoScript work at the browser level, while filters such as Web Application Firewalls (WAFs) work at the network or application level.
2. Response sanitization: Detects malicious code in responses and removes it. HTML Sanitizer is an example of this.
3. Code filters: Detect malicious JavaScript directly before execution. Examples are CSP and Chrome’s XSS filter.

Code-reuse attack on modern web applications via script gadgets

The attack on a web application described below can bypass the means previously used to defend against XSS. To do this, the attacker misuses so-called script gadgets to execute JavaScript.

Background: JavaScript, HTML and the DOM

JavaScript is used to interact with the DOM (Document Object Model) and makes HTML pages more interactive. To do this, JavaScript reads the DOM in the browser in different ways. Functions like “document.getElementsByClassName” are based on DOM selectors, which can be used to examine the DOM for specific elements. DOM selectors are the basis of modern JavaScript frameworks, elements can be accessed by specifying the tag, ID, class or attribute.

What are Script Gadgets?

Script gadgets play the main role in the presented attack method. They are legitimate JavaScript fragments within the valid application code executed by valid HTML markup. Script gadgets do not need to be smuggled in by the attacker, they are already included in the web developer’s code or in JavaScript libraries used. Most often, these gadgets use DOM selectors to interact with elements on the web page. For example, a web application can assign a value to an element that comes from the DOM:

var button = getElementById(„button-Ok“);

button.innerHTML = button.getAttribute(„data-text“);

A Script Gadget is a JavaScript code that responds to a specific DOM.

How does the attack work?

Existing XSS defenses are based on the assumption that the website is directly infected with malicious code. In the gadget-based attack, harmless-seeming HTML markup is inserted into the website. HTML content without scripts is considered valid and remains untouched. Since the added code does not directly contain executable script code, previously used XSS defenses ignore it. During the runtime of the web application, script gadgets access the inserted content and involuntarily convert it into executable code.

Properties of the malicious code

The attacker’s inserted code meets two criteria:

• The hacker’s JavaScript is included in non-executable form in the valid HTML code.
• The HTML is designed to drive a script gadget in the web document. The added HTML thus triggers a so-called code-reuse attack.

The attack pattern

The described attack follows this pattern:

1. The attacker infects the DOM with code that triggers Script Gadgets. The attacker’s code contains valid HTML markup and matches the DOM selectors of the web application.
2. The injected content is examined by the defenses and is not modified because it is valid HTML markup.
3. The JavaScript gadget, using DOM selectors, takes the inserted code from the DOM and transforms it into JavaScript commands.
4. The attacker’s script is executed, resulting in a cross-site scripting attack.

The Script Gadget accesses the added DOM content, which results in the execution of the malicious codes. The problem is that these script gadgets are in use in almost all modern JavaSript frameworks. As a result, the researchers believe that most techniques used to defend against cross-site scripting on websites can be circumvented using modern JavaScript libraries. The researchers analyzed the top 5,000 websites and were able to detect security vulnerabilities caused by script gadgets in 19.88 percent of the cases.

Solving the problem of cross-site scripting with Script Gadgets

Due to the numerous frameworks and libraries, it is difficult to address all Script Gadgets appropriately. For example, the HTML cleaners can filter the class or data id attributes to avoid the execution of malicious code. On the other hand, developers of the libraries and frameworks can eliminate corresponding gadgets to better protect users. Because of the difficulties, the researchers recommend techniques for isolation and prevention. They list isolated scripts, sandboxed iframes and suborigins as promising approaches that security experts should pay more attention to.