Business
Browser security briefing: Google and Mozilla lay the groundwork for a ‘post-XSS world’
Published
4 years agoon
By
GFiuui45fgANALYSIS New browser security features offer the tantalizing promise of killing – or at least significantly reducing – many of the classic web security attack vectors.
Minimizing the potency of classic attack vectors such as cross-site scripting (XSS) and cross-site request forgery (CSRF) promises to herald what some are calling the ‘post-XSS world’.
The improvements represented a culmination of several years of work by many people in the industry, realized in specifications and implementations in Google Chrome 83 and Mozilla Firefox 79.
Security improvement roster
A blog post by Google back in July describes a set of security mechanisms to protect its applications from common web vulnerabilities.
These mechanisms include Trusted Types, Content Security Policy based on script nonces, Fetch Metadata Request Headers, and the Cross-Origin Opener Policy that collectively protect applications.
These features offer protection against injection attacks, alongside improved isolation capabilities.
For example, the script nonce attribute, set to an unpredictable token for every page load, “acts as a guarantee that a given script is under the control of the application”.
According to Google, even if part of the page is injected by an attacker, “the browser will refuse to execute any injected script which doesn’t identify itself with the correct nonce”.
This mitigates the impact of any server-side injection vulnerabilities including reflected XSS and stored XSS.
Content Security Policy refinements
Google has implemented these improvements through refinements in its Content Security Policy (CSP).
“CSP has mitigated the exploitation of over 30 high-risk XSS flaws across Google in the past two years,” the tech giant said.
“Nonce-based CSP is supported in Chrome, Firefox, Microsoft Edge, and other Chromium-based browsers. Partial support for this variant of CSP is also available in Safari.”
Elsewhere, Fetch Metadata request headers, which the browser attaches to outgoing HTTP requests, offer applications with trustworthy information about the provenance of requests sent to the server.
The mechanism offers a defense against cross-site request forgery (CSRF) and a new family of web-based privacy-leaking techniques known as XS-leaks.
Cross-Origin Opener Policy (COOP) allows developers to lock down their web applications to restrict interactions with browser windows belonging to other applications, a feature that can result in information leak vulnerabilities.
COOP debuted in Chrome 83 and Firefox 79.
A blog post by Mozilla web security expert Anne van Kesteren offers a technical background on the non-profit’s implementation of COOP, placing it in the wider context of efforts to improve browser security and memory management.
“With Chrome’s Site Isolation and Firefox’s Project Fission, browsers will isolate each site into its own process,” van Kesteren writes. “This is possible due to the web platform’s retrofitted same-origin policy.”
Project Fission: New Firefox security features
Project Fission was central in Mozilla’s effort to improve browser security last year, a Mozilla spokesperson told The Daily Swig:
In 2020, Mozilla has worked hard to make the internet safer for all users. The Firefox security team played a major role in making this happen. A primary focus for this group has been Project Fission, Mozilla’s implementation of Site Isolation in Firefox, which can currently be tested in the Nightly version of the browser.
Along with Cross-Origin Opener and Embedder Policy, it is part of Mozilla’s mitigations against Spectre-style attacks.
Additional work includes prototyping and helping design Fetch Metadata request headers and the HTML Sanitizer API. These will likely be rolled out in Firefox once they are standardized.
As part of our privacy efforts we’ve also worked on network partitioning, ensuring websites do not share network state. This also happens to address a class of security attacks known as XS-Leaks. It can be tested in Nightly now and will soon make it to release.
Start your engines
Support for these security mitigations is first added to browser engines that underpin today’s search experience. Chrome and all Chromium-based browsers inherit everything the Blink rendering engine and V8 JavaScript engine have to offer. Browsers like Firefox and Tor Browser are powered by Gecko.
Finally, Apple Safari and a handful of gaming console browsers (including the PS4 and Nintendo Switch) inherit their security improvements via the proprietary WebKit engine.
All browsers on iOS must run with WebKit under the hood.
Google is positioning all of these security features as building blocks in the development of a more secure web ecosystem.
The Daily Swig spoke to Santiago Diaz, an information security engineer at Google, about the latest wave of browser enhancements.
The security pro explained that the problem can be divided into two buckets – injection vulnerabilities and isolation issues.
“The solution is a number of mitigations to address each bucket. On the injection side of things, we have Trusted Types and CSP3.
“On the isolation side of things, we have Resource Isolation, Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), and Origin Isolation,” he added.
‘Battle-tested mitigations’ for DOM-based XSS
According to Diaz, on the injection side, CSP3 and Trusted Types are “battle-tested mitigations that make the vast majority of DOM-based XSS unexploitable when used correctly”.
“Only Chrome supports both,” he explained. “Firefox supports CSP3 and is working towards Trusted Types, and unfortunately Safari, the renegade browser, supports neither Trusted Types nor CSP3.
“CSP3 (nonce-based policies) is a pivotal part of the puzzle that Safari seems to completely neglect.”
Browser red team exercises
The Daily Swig asked Diaz if Google has carried out analysis on the browser security features from the perspective of an attacker.
“Defects have been found through research on how security mitigations can enable attacks,” he said.
“I can’t provide details on the research and unfortunately much of this is still undisclosed, but @shhnjk [Jun Kokatsu] from Microsoft has published their attacks. Rest assured, there’s been research on both bypasses and unintended side effects caused by new features.”
Many of the enhanced security features are being deployed by default, but this varies between browser engine developers.
For Google, SameSite cookies, Trusted Types enforcement (when a policy is present), CORB, resource isolation headers, and site isolation are enabled by default in Chrome.
Diaz said: “Firefox is working on Project Fission to enable some of these, but it hasn’t been released to production yet. Safari has released Intelligent Tracking Prevention, a mitigation somewhat similar to SameSite cookies.”
And finally, are there any plans to change the behavior of features such as document.write (the source of a lot of XSS holes and performance issues)?
Diaz responded: “While changing this behavior would generally break backward compatibility, we hope direct string assignments will be highly discouraged in the future.
“document.domain is one of the APIs that is still a major blocker to do this. Trusted Types is one way in which we’re trying to achieve a future of a web that uses types and not strings.”