Trusted Types: A world without XSS

This presentation was given on 9 June 2022, at the Balasys API Meetup. You can re-watch Gábor’s presentation (in Hungarian) here.

XSS? Trusted Types?

It is essential to look at Trusted Types and Cross Site Scripting (XSS) when taking stock of ongoing developments in the IT world. XSS is a relatively popular term. During XSS attacks, malicious scripts are injected into otherwise benign and trusted websites. According to the HackerOne security platform and hacker program, 23% of all vulnerabilities transmitted through bug bounty platforms are XSSs. In one of his speeches in 2018, Mario Heinrich, CEO of Cure53, declared that “XSS is dead. We just don't get it.” This means that though the tools needed to mitigate XSS are available, developers lack the intention to implement them. However, he acknowledged that it is not necessarily possible to cover every single XSS with the available tools, so there are XSSs that are still out there and do need to be taken care of.

A typical trend in the development of web technologies is the increasing preference for the client side, which has meant that server-side templating has been overshadowed. Developers are trying to make sure that the logic for single-page applications runs on the browser side, which means that the browser is the one to solve the problems. Another observable phenomenon is the growth of the JavaScript code base. This means that Document Object Model (DOM)-based XSS will also grow as the medium available for it. The essence of an XSS attack, as the name implies, is to achieve scripting across sites. This creates an opportunity for users to be redirected from one page to another or to steal data with malicious intent. It is well known that there are excellent solutions for server-side-based templating, such as CSP and nonce-based CSP, but the question remains of what options the DOM API offers. The API provides roughly 60 DOM sinks that make it possible to override traditional behavior when assigning values. If they become controllable in any way for an attacker, it will result in a DOM XSS.

Trusted Types

During a six-year research period, Google introduced Safe Types in its core services. As a result, they noticed a drastic reduction in DOM XSS – in fact, the company has now managed to eliminate it completely. The experiment was considered ready to be opened to the public. As a result, Trusted Types was born, though the standard is still officially a work in progress. According to Trusted Types, not only string assignment is possible, but an object can also be specified as a value. And if you can specify an object as a value, you can also define trusted objects. This contribution enables the DOM API to accept solely and exclusively trusted values. Defining a policy to create a trusted object is essential, which means that the Trusted Types policy receives a string as input and returns an object that has already been sanitized by it. Policy-based correction is enforced by the browser, so there is no option to specify exceptions.

Why is this beneficial?

Each value assignment that is placed in the DOM is validated, as only trusted objects can be placed into it. Moreover, it drastically simplifies code review. It is no longer necessary to manually review the code, since items and security measures that are centralized in the policy and deemed safe in advance have already been reviewed. In simple terms, if the policy file is okay, everything will be fine.

Trusted Types case study: Avatao

Gábor and his team at Avatao tested how Trusted Types is able to function within a relatively large code base. In their case, research and implementation took roughly 32 hours. Trusted Types were warmly received in Chromium-based browsers, while other types of browsers had to be experimented with with polyfills. For non-Chromium-based browsers, Avatao claims the technology is still a bit immature, but the DOM API and DOM library are expected to be supplemented with the parameters needed for successful implementation in the foreseeable future.