Internal deployment has nullified elusive, complex threat since 2019
Google has revealed how a set of internally developed browser APIs and policies can simplify the prevention of DOM-based cross-site scripting (XSS) vulnerabilities.
According to a report penned by Google infosec engineer Krzysztof Kotowicz, the tech giant has been using ‘Trusted Types’ since 2019 and observed “zero DOM XSS in Google applications migrated" to them.
This suggests Trusted Types can become a powerful tool in addressing one of the thorniest security issues affecting web applications.
What is DOM XSS?
DOM XSS attacks exploit unsecure, client-side JavaScript code, executing malicious actions through ‘injection sinks’ – functions that parse user input strings into the DOM tree. DOM XSS attacks can’t be stopped with server-side security tools, and catching them in browser code is especially tricky.
“DOM XSS are difficult to find because of the large number of sources and sinks that can lead to these issues,” security researcher Michał Bentkowski told The Daily Swig. “For instance, you need to check for innerHTML, outerHTML, location, location.href, eval-like functions etc. It is easy to miss at least one vector of DOM XSS.”
YOU MIGHT ALSO LIKE ‘LEXSS’ injection: How to bypass lexical parsers by abusing HTML parsing logic
With web applications increasingly dependent on client-side code, the complexity and threat posed by DOM XSS vulnerabilities are growing.
“There's a lot of client-side dynamic DOM manipulation in modern web applications, and since multiple Web APIs can cause DOM XSS, the consequences are dire,” Kotowicz told The Daily Swig. “DOM XSS is on the rise. In our applications, we're now seeing 50-60% percent of XSSes introduced in client-side JS.”
Trusted Types – ‘A whole lot easier’
Trusted Types provide HTML header directives and policies that warn or prevent the use of unsafe DOM manipulation code. It also provides a set of JavaScript functions and types to sanitize dynamic DOM content.
For example, a web application with a Trusted Types policy would flag the following code as insecure, because without sanitization, location.href could contain a malicious JavaScript payload embedded in the query string: anElement.innerHTML = location.href;
Instead, the policy requires developers to use a HTML sanitizer library such as DOMPurify or functions that generate one of several Trusted Types constructs, such as TrustedHTML, TrustedScript, and TrustedScriptURL, which undergo sanitization during their construction.
Trusted Types simplify code reviews because developers only need to check code that generates Trusted Types instead of verifying every single injection sink.
“With Trusted Types, auditing an application for potential DOM XSS is basically just checking the policy. So it makes the process a whole lot easier,” Bentkowski said.
Read more of the latest secure software development news and analysis
Trusted Types also complement other web security tools and practices such as static analysis, security code reviews, and content security policies.
“Trusted Types is ‘just’ another addition to the toolkit, but one that we feel really complements those existing countermeasures,” Kotowicz said. “Trusted Types not only address the gaps, but help lift the other security controls. For example, they detect vulnerable patterns that the static analysis might miss (our data shows that's over 60% of DOM XSS!).”
Meanwhile, Bentkowski warns that Trusted Types are not a silver bullet that will eradicate all DOM XSS vulnerabilities. “The policy might still contain a mistake, or the policy might use an HTML sanitizer with a bypass,” he said. “But it still adds a huge benefit for applications and makes auditing so much easier.”
Secure development
In the past two years, Google has applied Trusted Types to more than 130 services built on its main application framework, including Google Photos, Google Contacts, and Google My Activity, according to Kotowicz’s report.
Although security engineers have subsequently found no DOM XSS in those applications, Kotowicz says the project’s biggest practical benefit is in driving developers away from using risky patterns and toward writing inherently secure code.
“The moonshot end state is that there just is no DOM XSS to worry about, as the browser validates that the dangerous APIs are simply never used,” Kotowicz said.
Work in progress
Google has simplified the API and facilitated the migration of legacy code to the new policies since Trusted Types’ 2019 inception. The tools have already shipped in Chromium-based browsers and tools such as Visual Studio Code, and Google is working on an API proposal within the W3C Web Application Security Working Group.
However, Trusted Types is still a work in progress and there remain several unresolved problems. In a thread on GitHub, for instance, engineers at Mozilla have expressed concern that the “inherent complexity” of Trusted Types will make it “difficult to adopt by the long tail of websites”.
Said Kotowicz: “The API can and will likely change as we encounter new issues, or migration challenges. That said, the biggest focus for now is to drive the adoption through the support in the libraries and the frameworks.”
RECOMMENDED Filesec.io project catalogs malicious file extensions being used by attackers
