Mozilla decides Trusted Types is a worthy security feature
- Reference: 1703156591
- News link: https://www.theregister.co.uk/2023/12/21/mozilla_decides_trusted_types_is/
- Source link:
By so doing, the browser biz will help reduce a longstanding form of web attack that relies on injected code.
"We at Mozilla have done a thorough spec review and intend to change our standards position to positive," [1]declared Frederik Braun, Firefox security engineer, in a post to a discussion of Mozilla's views about proposed browser technologies. "We are convinced of the track record that Trusted Types has in terms of preventing DOM-based XSS on popular websites."
[2]
Mozilla won't implement Trusted Types in Firefox immediately – there are still some technical issues to sort out. But the org's decision is a win for web security, which has been looking up since May 2020 when Trusted Types shipped in [3]Chrome 83 and Edge 83. Opera (based on the open source Chromium project, like Edge) added support in June 2020.
[4]
[5]
[6]Trusted Types addresses [7]DOM-XSS , or document object model cross-site scripting – considered to be both rather dangerous and fairly common. Ranked first among the [8]OWASP Top Ten Web Application Security Risks in 2017 – under the category "Injection" – XSS attacks slipped to the third most common vulnerability by 2021. And XSS attacks should become less common as more websites revise their code to take advantage of Trusted Types.
"Trusted Types offers an (optional) mechanism for web sites to protect themselves against XSS (cross-site scripting) attacks," explained Daniel Vogelheim, a Google software engineer, in a Blink developer mailing list [9]post back in 2018, when the feature was about to be tested.
[10]Google, Amazon, Microsoft make the Mozilla naughty list for Christmas shopping
[11]Firefox slow to load YouTube? Just another front in Google's war on ad blockers
[12]Google pencils in limited third-party cookie purge for January
[13]Mozilla tells extension developers to get ready to finally go mobile
"Those types of attacks stem from implementation oversights that allow user-controlled (and therefore attacker-controlled) string data to slip through into parts of the DOM where they are interpreted as JavaScript (or script-equivalent)."
Or, as Vogelheim continued, they are made possible when developers fail to [14]sanitize their app's inputs .
[15]
For example, the .innerHTML property, which gets or sets the text for the associated element, can be used to execute code (in this case an alert popup): const name = "";
el.innerHTML = name; // shows the alert
With Trusted Types enabled, the browser expects a [16]TrustedHTML object instead of a text snippet.
Trusted Types addresses the risk of unsafe input by limiting the attack surface via Content Security Policy and a content filtering mechanism. And since the capability first showed up three years ago, DOM-XSS attacks have become less common in the Chromium ecosystem.
In an October [17]post to the GitHub repo discussing Mozilla's positions on various technologies, Vogelheim notes that Google expects to effectively eliminate DOM-XSS risk as it deploys Trusted Types across all of Google's websites.
"XSS used to be a significant problem at Google, making up 30 percent of overall VRP [Vulnerability Rewards Program] rewards in 2018," he noted. "In 2023, they account for only 4.1 percent, all for bugs reported against properties that have not migrated to Trusted Types yet. In the past three years, we have not received a single XSS (in VRP; in the wild; or through [our] own research) for a Trusted Types-enabled Google property."
[18]
In a 2021 [19]report [PDF] on Trusted Types, Krzysztof Kotowicz, an information security engineer at Google, wrote, "To date, we have observed zero DOM-XSS in Google applications migrated to Trusted Types."
Bartosz Niemczura, software engineer at Meta, echoed Google's enthusiasm in the Mozilla standards discussion thread, [20]stating , "At Meta, we see Trusted Types as a useful security mechanism as well. I believe that broader support across browsers and broader deployment across websites would be beneficial to the web platform overall."
Toward that end, Niemczura pointed to a [21]post he made in May urging Apple's WebKit team to consider adopting Trusted Types based on successful deployment by Google, Meta, and [22]Microsoft across various websites. Currently, Trusted Types is present or enforced in [23]about ten percent of Chrome web page loads.
Bruce Perens, a veteran programmer and one of the founders of the Open Source movement, expressed enthusiasm for the technology after deploying it.
"I've implemented Trusted Types on a web app, and I felt they were really helpful in identifying lots of 'injection sites' where a cross-site scripting attack could happen, and requiring me to provide a filter or some other way of securing user input that got there," he wrote in an email to The Register .
Perens said that while Trusted Types are only enforced in some browsers, developers should adapt their web app code to support the XSS defense because he believes Firefox, Safari, and other browsers will eventually include the technology.
"The web obviously evolved through a whole bunch of pieces being stacked on previous work as an afterthought, manipulation of the DOM, the document object model, by Javascript being the biggest addition to the simple HTML of the early web," Perens said. "The addition of Trusted Types helps to close security holes that were created by that early work. But a competent programmer is required to take advantage of this – cross-site scripting will still be possible if a website doesn't use Trusted Types." ®
Get our [24]Tech Resources
[1] https://github.com/mozilla/standards-positions/issues/20#issuecomment-1853427823
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZYRvPGT@GgReI3ybYSYvjwAAAU0&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2020/04/17/chrome_83_beta/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZYRvPGT@GgReI3ybYSYvjwAAAU0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZYRvPGT@GgReI3ybYSYvjwAAAU0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://web.dev/articles/trusted-types
[7] https://owasp.org/www-community/attacks/DOM_Based_XSS
[8] https://owasp.org/www-project-top-ten/
[9] https://groups.google.com/a/chromium.org/g/blink-dev/c/Il-wfnw9TAw/m/n3BUe4MgBgAJ
[10] https://www.theregister.com/2023/11/15/google_amazon_microsoft_mozilla/
[11] https://www.theregister.com/2023/11/21/ad_block_google/
[12] https://www.theregister.com/2023/12/14/google_schedules_limited_thirdparty_cookie/
[13] https://www.theregister.com/2023/11/03/mozilla_android_extensions/
[14] https://xkcd.com/327/
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZYRvPGT@GgReI3ybYSYvjwAAAU0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[16] https://developer.mozilla.org/en-US/docs/Web/API/TrustedHTML
[17] https://github.com/mozilla/standards-positions/issues/20#issuecomment-1783279722
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZYRvPGT@GgReI3ybYSYvjwAAAU0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[19] https://storage.googleapis.com/pub-tools-public-publication-data/pdf/2cbfffc0943dabf34c499f786080ffa2cda9cb4c.pdf
[20] https://github.com/mozilla/standards-positions/issues/20#issuecomment-1828287934
[21] https://github.com/WebKit/standards-positions/issues/186
[22] https://microsoftedge.github.io/edgevr/posts/eliminating-xss-with-trusted-types/#takeaways
[23] https://mitigation.supply/
[24] https://whitepapers.theregister.com/
Re: An even worthier security feature
Scripting has its place, static HTML is long gone, especially if it is decently sandboxed and doesn't have blatant bullshit like "how much charge is in your battery" (correct response: none of your business, piss off)...
...but we really need to get away from the idea of a site pulling in a couple of megabytes of crap from other sites, which themselves could pull in loads of other things like a giant house of cards.
Re: An even worthier security feature
House of cards??? I always visualise it as plugging into an open sewer.
Re: An even worthier security feature
" Scripting has its place, static HTML is long gone "
Please explain this assertion with concrete examples that justfy where scripting is essential rather than just nice to have. I suspect that will be a small minority of cases, but please tell. Otherwise it sounds like a circular argument.
Re: An even worthier security feature
"Scripting has its place"
Ehrrr ... no, in the very long run I think it probably does not -- at least not in the way you mean.
I think a much restricted form of scripting directed solely at controlling content layout might be OK. But scripting today is synonymous with Javascript. And Javascript as it stands now looks to be far too capable to be compatible with computing security. If you let third party material that loads Javascript code into your computing ecosystem, I doubt any amount of protective superstructure can reliably keep the bad guys out of your machinery. And they only need to get in once to leave you with an incredible mess that will be very time consuming and very costly to fix. If it can be fixed at all.
I fear that in the very long run, we have have two choices -- secure computer intercommunication with the outside world or scripting. Pick one.
Strong Typing
When a new opportunity for programming/scripting arises, they are often done with "dynamic" typing because that is easier to use and is thought to be more powerful.
Several years later and that new programming area starts to mature, and programmers in the area (and users!) start to realize the inherent weakness of that sort of stuff. Protections are added as things mature. Humans are fallible - as projects in a given area get more and more complex, fallible humans more and more often create subtle security holes which bad guys can exploit for money.
A couple of examples:
C playing free and loose with pointers and arrays ... C++ helps ... stronger typing and array/pointer protections come about in new languages, and those languages get adopted more and more. E.g. Rust, dlang.
Javascipt => Typescript
And now we have web scripting abominations being tackled.
Good!
I'm ready to bathe in the upcoming flames.
Re: Strong Typing
This isn't really about strong typing as such. It's about a data structure (the DOM) being manipulated as if it were a string. More specifically, when you insert a string into the DOM, that string can itself be parsed as part of the XML structure; you can insert nodes, which might be benign like "b" or "i", or dangerous like "script".
This is in the same class of problems as SQL injection, as witnessed by [1]Bobby Tables .
The solution is to escape data properly so that text is only interpreted as text, and cannot be interpreted as a higher-level structure. And that's effectively what this "typing" is doing: not allowing you to accidentally insert text unless you've explicitly sanitized it or escaped it.
(Note that El Reg comments don't do this properly: if I type <b> then it ought to render as "b" inside angle-brackets)
[1] https://xkcd.com/327/
An even worthier security feature
would be to scrap this ridiculous dependence on scripting. It's the primary vector for the huge majority of browser-based attacks, and it's mostly entirely unnecessary for delivery of content. The assumption that it's sensible to allow totally unverified code from completely unknown sources to run silently on your computer is difficult to justify, particularly as corporate user policies almost always state that voluntary downloading of unverified code is prohibited.
Until the web dev community wakes up, a real improvement from Mozilla would therefore be to incorporate fine grained "default deny" script controls directly into the browser for all users, so to be safe they wouldn't have to be knowledgeable enough to install independent controls.