Beyond the Limits of Site Isolation

Beyond the Limits of Site Isolation

Speakers: Ivan Fratric, Security Researcher, Google Project Zero

Conference: OffensiveCon

YouTube: https://www.youtube.com/watch?v=d3nfJL86jrc

Overview

In this talk, Ivan Fratric, a seasoned security researcher and Tech Lead at Google Project Zero, delves into the often-misunderstood boundaries of Site Isolation, a critical security mitigation in modern web browsers. Fratric presents a deep dive into a long-standing, high-severity vulnerability in Chrome, which he discovered during an internal hackathon in 2019, that allowed for the leakage of sensitive redirect URLs containing data like OAuth codes. Despite being marked as "fixed" in late 2022, Fratric reveals that the core issue, particularly concerning sub-resource loading, largely persists due to the fundamental architectural challenges of web browser engines.

The presentation challenges the conventional understanding of Site Isolation's protective scope, highlighting how corner cases and the intricate interplay between the renderer process and web standards can create unexpected security vulnerabilities. Fratric not only demonstrates the practical exploitability of this flaw against a real-world scenario involving GitHub and Google OAuth but also explores how other browsers, like Firefox and WebKitGTK (Safari), handle similar situations, revealing both their unique defenses and their own distinct logic bugs. This talk is essential for browser developers, security architects, and anyone interested in the complex landscape of web security, offering critical insights into the real-world limitations of even the most robust security features.

Background

▶ Watch: Introduction to Site Isolation and its purpose (0:00)

Site Isolation is a fundamental security mechanism implemented in modern web browsers like Chrome and Firefox, designed to protect sensitive user data from compromised renderer processes. Introduced in Chrome around 2018, its core principle is to ensure that content from different "sites" is handled by separate operating system processes, even if displayed within the same browser tab. For instance, a news portal displaying advertisements from various domains would render each ad in its own dedicated process, distinct from the main page and other ads. This process separation aims to contain the impact of a successful exploit, preventing an attacker who compromises a renderer process for a site they control from accessing secrets (like cookies, XSRF tokens, or sensitive text) belonging to other sites. It also serves as a critical defense against side-channel attacks that might otherwise read the entire memory of a single renderer process.

Despite its robustness, Site Isolation has always had documented limitations. Firstly, the definition of a "site" for isolation purposes is not as granular as an "origin" under the Same-Origin Policy (SOP). For example, foo.example.com and bar.example.com are distinct origins but considered the same site under Site Isolation, meaning they might share a renderer process. Secondly, the protection of web page content relies on web servers correctly serving content with appropriate Content-Type headers; misconfigurations can lead to cross-site content being processed in unexpected ways. Lastly, Site Isolation is not universally available across all platforms or browser configurations.

The specific vulnerability discussed by Fratric emerged from an internal Google hackathon in June 2019, where Project Zero and other teams were tasked with finding flaws in the then-evolving Site Isolation feature. At that time, Site Isolation was not yet considered a full security boundary. Fratric initially filed two bugs, one of which was quickly fixed. The second, however, proved exceptionally difficult to remediate. Later in 2019, when Site Isolation officially became a supported security boundary, this lingering bug was upgraded to high severity. It remained unfixed for an extended period, eventually becoming the oldest high-severity bug in Chrome's bug tracker, a testament to the architectural complexity involved in its resolution. Fratric notes that it was initially filed directly with the vendor without Project Zero's standard 90-day disclosure policy because it wasn't initially deemed "tracker worthy" given Site Isolation's immature security status at the time.

Key Findings

▶ Watch: Documented limitations of Site Isolation explained (3:00)

The central finding of Fratric's research is that Site Isolation, despite its intent, does not adequately protect redirect URLs from being exposed to a compromised renderer process. These redirect URLs can, under specific circumstances, contain highly sensitive information, such as OAuth codes used in various authentication flows.

Specifically, the Chrome vulnerability (which, notably, does not have a public CVE mentioned in the talk, reinforcing its "untracker worthy" origins and internal handling) stems from the fact that the renderer process receives the final URL after an HTTP redirect, even for cross-origin sub-resource loads. In the context of OAuth flows, an attacker controlling a renderer process on an arbitrary site can initiate a request that triggers an OAuth redirect. The resulting redirect URL, intended for the legitimate OAuth client, often contains a temporary authorization code. Because the compromised renderer can read this URL, the attacker can extract the code and impersonate the victim.

Fratric highlights the architectural challenge in fixing this: the renderer process often legitimately needs the final URL of a resource after redirects to correctly resolve relative URLs within that resource (e.g., an @import rule in a CSS stylesheet). This fundamental requirement complicates efforts to simply withhold redirect URLs from the renderer. Consequently, while some aspects of redirect handling (specifically during navigation) have been addressed, the core issue for sub-resource loading, as exploited in the demonstration, largely persists. Fratric now views this as a fundamental "limitation" of Site Isolation rather than a traditional "bug" due to its inherent difficulty.

In contrast, Fratric found that Firefox, while similarly exposing redirect URLs to its renderer process, is not vulnerable to this specific OAuth attack in its default configuration. This is due to Firefox's default blocking of third-party cookies, which prevents the necessary authentication for the cross-origin sub-resource load to occur, thus ensuring the redirect URL does not contain sensitive, authenticated information.

Finally, Fratric also uncovered a separate, "normal" logic bug (meaning it was fixable via conventional means) in WebKitGTK (the engine used by Safari) that allowed for a partial leakage of redirect URLs to JavaScript. This bug exploited a combination of being able to call insertRule on a cross-origin stylesheet and a flaw in cross-origin checks when the stylesheet was detached from the DOM, allowing an attacker to read the host and path (but not the query string) of a redirected URL. This demonstrates that even without a compromised renderer, logic flaws can expose sensitive URL components.

Technical Deep Dive

▶ Watch: Internal hackathon: The origin story of the bug (4:00)

The core of the Chrome vulnerability presented by Ivan Fratric lies in the browser's handling of HTTP redirects within the renderer process. When a resource request results in an HTTP redirect, the function ResourceFetcher::DidReceiveRedirect (or a similar internal mechanism) is invoked within the renderer process. Crucially, this function receives the new URL (the URL after the redirect) as one of its arguments.

The issue arises because redirect URLs are not always benign. In the context of OAuth 2.0 flows, a common pattern involves an initial request to an identity provider (e.g., Google) which then redirects back to a client application (e.g., GitHub) with an authorization code embedded in the URL's query string (e.g., https://github.com/callback?code=YOUR_AUTH_CODE). This authorization code is a single-use token that the client application exchanges for an access token. If a compromised renderer process can intercept this redirect URL, it can steal the authorization code.

The difficulty in fixing this in Chrome stems from a fundamental design requirement: the renderer process often needs the final, redirected URL. A primary example is the resolution of relative URLs within sub-resources. Consider a CSS stylesheet loaded from https://example.com/style.css. If style.css contains an @import rule like @import "common.css";, the browser must resolve common.css relative to the final URL of style.css. If style.css itself was loaded after a redirect, say from https://old-domain.com/style.css to https://new-domain.com/style.css, then common.css must be resolved relative to https://new-domain.com/style.css. Without the final URL in the renderer process, this resolution would be impossible. This architectural dependency means simply preventing the renderer process from ever seeing redirect URLs would break significant portions of web functionality. The speaker suggests that moving this URL resolution logic entirely to the browser process would be a complex and potentially performance-intensive undertaking, requiring a proxy URL class and significant refactoring.

Regarding Firefox, Fratric explains that while its renderer process also receives redirect URLs via functions like nsDocShell::DidReceiveRedirect or nsContentUtils::DidReceiveRedirect, the practical exploitability of the OAuth attack is mitigated by Firefox's default configuration. Firefox, by default, blocks third-party cookies. In an OAuth flow, if the initial request to the identity provider is made from a third-party context (i.e., from the attacker's controlled domain, which is different from the identity provider's domain), Firefox's third-party cookie blocking prevents the request from being authenticated. Without authentication, the identity provider will not issue a sensitive OAuth code in the redirect URL, rendering the attack unexploitable by default.

The WebKitGTK (Safari) vulnerability, in contrast, was a JavaScript-level logic bug. It involved two distinct flaws:

1. Cross-origin insertRule: WebKitGTK allowed JavaScript to call the insertRule method on a cross-origin stylesheet object. This is generally disallowed by the Same-Origin Policy to prevent modification of external stylesheets.
2. Bypassed Cross-Origin Check: When the stylesheet object was detached from the DOM (e.g., by removing its corresponding <link> element), the internal check for whether it was a cross-origin stylesheet failed. This meant that after detaching, an attacker could then read the rules of the cross-origin stylesheet.

By combining these, an attacker could:

1. Load a stylesheet pointing to a URL that would redirect (e.g., an OAuth redirect URL).
2. Get a reference to the stylesheet object.
3. Call insertRule on this cross-origin stylesheet, inserting an @import rule with a relative URL (e.g., @import "foo"). This relative URL would be resolved against the final, redirected URL of the stylesheet.
4. Detach the stylesheet from the DOM.
5. Read the inserted rule, which would then expose the resolved URL of foo. By constructing the relative URL carefully, the attacker could leak the host and path of the original redirect URL, although not the query string, as the query part was overridden by the relative URL resolution logic. This made it a "partial" URL leak. Fratric notes that this bug was more broadly useful for reading the content of cross-origin stylesheets or any content the browser would parse as CSS. This bug has since been fixed through normal patching processes.

Demo / Proof of Concept

▶ Watch: The bug revealed: Leaking sensitive redirect URLs (8:30)

Ivan Fratric presented two distinct demonstrations, one for the Chrome vulnerability and another for the WebKitGTK logic bug.

Chrome Compromised Renderer Demo (OAuth Code Leak)

This demonstration showcased the primary vulnerability: leakage of an OAuth code via a compromised Chrome renderer process.

Setup:

1. A custom Chromium build was used, patched to simulate a compromised renderer. This represented the victim's web browser.
2. The victim was logged into GitHub using Google OAuth in one tab of this compromised browser.
3. An incognito window, representing the attacker's web browser, was used to initiate the attack.

Attack Steps:

1. Attacker Initiates Login: In their incognito browser, the attacker navigated to GitHub and started the "Sign in with Google" flow.
2. Attacker Captures OAuth URL: The attacker opened the network inspection dialog in their browser and copied the initial Google OAuth authentication URL that GitHub redirects to. This URL, when loaded, would eventually redirect back to GitHub with an OAuth code.
3. Attacker Injects URL into Compromised Renderer: The attacker then pasted this copied Google OAuth URL into the tab of the victim's compromised browser. A parameter in the URL that sometimes forces an account selection dialog was removed to streamline the process.
4. Redirect Occurs, Code Leaked: When the compromised renderer loaded this URL, it initiated the Google OAuth flow. Google authenticated the victim (since the victim was logged in via Google OAuth in that browser) and then issued an HTTP redirect back to GitHub. Crucially, this redirect URL contained the sensitive OAuth code in its query string.
5. Compromised Renderer Extracts Code: Because the renderer process was compromised, it had access to this final redirect URL. The demo showed the URL being read out, clearly displaying the OAuth access token (code).
6. Attacker Impersonates Victim: The attacker copied this extracted redirect URL (containing the OAuth code) from the compromised renderer's output. When the attacker then opened this URL in their own browser (the incognito window), they were immediately logged into GitHub as the victim.

This demonstration vividly illustrated how a successful renderer compromise, even on an attacker-controlled site, could bypass Site Isolation to steal sensitive data from cross-site interactions like OAuth flows, effectively enabling account takeover. Fratric noted that this specific exploit path, involving sub-resource loading, should still work as of the talk, despite the bug being "marked as fixed" for other scenarios.

WebKitGTK Partial URL Leak Demo

This demonstration showcased a separate logic bug in WebKitGTK (the engine used by Safari) that allowed a partial leak of a redirect URL to JavaScript.

Setup:

1. A build of WebKitGTK on a Linux machine was used (as Safari itself was not available). This simulated a standard browser environment without a compromised renderer.

Attack Steps:

1. Load Cross-Origin Stylesheet: The attacker's JavaScript loaded a <link rel="stylesheet"> element, pointing it to a URL known to result in an HTTP redirect.
2. Abuse insertRule: The JavaScript obtained a reference to the stylesheet object. The first part of the bug allowed the attacker to call stylesheet.insertRule() on this cross-origin stylesheet, which should normally be disallowed by SOP. The attacker inserted an @import rule with a relative URL, e.g., @import "relative_path". This relative path would be resolved against the final, redirected URL of the stylesheet.
3. Bypass Cross-Origin Read Check: Initially, trying to read the inserted rule (e.g., stylesheet.rules[0].cssText) would fail due to cross-origin restrictions. However, the second part of the bug was that if the stylesheet was detached from the document (e.g., by removing its <link> element from the DOM), the cross-origin check for reading its rules no longer functioned correctly.
4. Leak Partial URL: After detaching, the attacker could successfully read the rule. The href attribute of the @import rule would then contain the resolved URL of "relative_path", which included the host and path of the original redirect URL (e.g., https://example.com/redirected/path/relative_path). This demonstrated a partial URL leak, as the query part of the original redirect URL was overwritten by the relative path.

This demo highlighted how even without a full renderer compromise, specific logic bugs in browser engines could expose parts of sensitive URLs to attacker-controlled JavaScript.

Defensive Implications

▶ Watch: Real-world impact: OAuth codes leaked via redirect URLs (9:30)

The findings presented by Ivan Fratric carry significant defensive implications for both end-users and browser developers.

For end-users and organizations, the most direct and effective mitigation against the demonstrated OAuth code leakage attack (and similar attacks relying on third-party cookies) is to disable third-party cookies in their web browsers. As highlighted by Firefox's default behavior, blocking third-party cookies prevents the necessary authentication for cross-site sub-resource loads that might lead to sensitive data (like OAuth codes) being embedded in redirect URLs. Many browsers offer this option, and it's increasingly becoming a default in privacy-focused configurations. While this might occasionally break some legitimate functionalities that rely on third-party cookies, its security benefits, especially in preventing tracking and certain types of cross-site data leakage, are substantial.

For browser developers, the talk underscores a fundamental architectural challenge within Site Isolation. The fact that the renderer process often legitimately requires the final URL of a resource after redirects (e.g., for resolving relative URLs in stylesheets) makes a complete fix exceptionally difficult. Developers must continue to carefully re-evaluate which pieces of information are truly indispensable within the renderer process and explore alternative architectures. Possible, albeit complex, solutions could involve:

• Proxying URL Resolution: Implementing a mechanism where the renderer process requests the browser process to resolve relative URLs, rather than performing the resolution itself. This would mean the renderer never directly sees the sensitive base URL. Fratric acknowledged this as a potential, though non-trivial and potentially performance-impacting, solution during the Q&A.
• Granular Data Sanitization: More aggressively sanitizing or redacting sensitive components of URLs (like query strings containing tokens) before they are exposed to the renderer process, even if the base URL is necessary. However, this is challenging without breaking legitimate uses.
• Rethinking Site Isolation Boundaries: The talk suggests that the boundaries of Site Isolation might not be as clear-cut as initially intended, particularly in "corner cases" that involve complex interactions between web standards, HTTP redirects, and the browser's internal architecture. Continuous research and auditing of these interactions are crucial.

The WebKitGTK bug also serves as a reminder that even "normal" logic bugs that expose URL components to JavaScript can have significant security implications, independent of a full renderer compromise. Browser developers must maintain vigilance in adhering to the Same-Origin Policy and other security principles when handling cross-origin resources and DOM manipulation, ensuring that sensitive data is not inadvertently exposed.

Ultimately, Fratric's perspective that the Chrome bug represents a "limitation" rather than a "bug" highlights that some security challenges are deeply embedded in existing architectural decisions and web standards. This calls for a long-term strategy of incremental improvements, careful risk assessment, and potentially a re-imagining of how security boundaries are enforced in highly complex software like web browsers.

Key Takeaways

• Site Isolation has Limitations: Despite being a crucial security mitigation, Site Isolation does not perfectly protect against all forms of data leakage, particularly concerning redirect URLs in specific architectural corner cases.
• Redirect URLs Can Leak Sensitive Data: HTTP redirect URLs can contain highly sensitive information, such as OAuth codes in authentication flows, which, if exposed, can lead to account takeover.
• Chrome Vulnerability (Sub-resource Loading): A long-standing, high-severity bug in Chrome allows a compromised renderer process to read OAuth codes from redirect URLs during cross-origin sub-resource loading, despite the bug being "marked as fixed" for navigation.
• Architectural Challenges: The Chrome vulnerability is difficult to fix because the renderer process legitimately needs the final URL after redirects to resolve relative URLs in loaded resources (e.g., CSS @import rules), making a simple fix impractical without breaking web functionality.
• Firefox's Default Protection: Firefox is not vulnerable to this specific OAuth attack by default due to its proactive blocking of third-party cookies, which prevents the necessary authentication for cross-origin sub-resource loads.
• Other Browser Logic Bugs: Separate logic bugs, like the one found in WebKitGTK/Safari, can also lead to partial leakage of redirect URLs to JavaScript, even without a compromised renderer, highlighting the need for rigorous adherence to the Same-Origin Policy.
• Defensive Action: Disabling third-party cookies is a practical and effective mitigation for end-users and organizations worried about this specific OAuth-related attack and other forms of cross-site data leakage.

About the Speaker(s)

Ivan Fratric is a distinguished Security Researcher and Tech Lead at Google Project Zero. With an "unreasonable amount of time" dedicated to security research, he has established himself as a prominent figure in the field. Fratric is known for his deep technical expertise in identifying and analyzing complex vulnerabilities, particularly within web browsers and other critical software. He is also the author of multiple open-source tools designed to aid security research. His work often involves participating in internal hackathons, where he has a track record of discovering significant bugs, some of which have led to talks at prestigious conferences like OffensiveCon. His experience in uncovering and tracking long-standing, challenging vulnerabilities like the one presented underscores his profound understanding of browser security architectures and their inherent complexities.