- The four common measures to protect against XSS
- Code-reuse attack on modern web applications via script gadgets
- What are Script Gadgets?
- How does the attack work?
- Properties of the malicious code
- The attack pattern
- Solving the problem of cross-site scripting with Script Gadgets
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.
Most of these techniques focus on script tags and event handlers. The protection measures are based on the following three strategies:
- 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.
- Response sanitization: Detects malicious code in responses and removes it. HTML Sanitizer is an example of this.
Code-reuse attack on modern web applications via script gadgets
What are Script Gadgets?
var button = getElementById(„button-Ok“);
button.innerHTML = button.getAttribute(„data-text“);
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 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:
- 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.
- The injected content is examined by the defenses and is not modified because it is valid HTML markup.
- The attacker’s script is executed, resulting in a cross-site scripting attack.
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.