Tabbed Out: Subverting the Android Custom Tab Security Model

Tabbed Out: Subverting the Android Custom Tab Security Model

Speakers: Philipp Beer; Marco Squarcina; Lorenzo Veronese; Martina Lindorfer

Conference: IEEE S&P

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

Overview

In the realm of Android application development, the choice of how to display web content within an app carries significant security implications. While the Android WebView component offers flexibility, its inherent security weaknesses have prompted developers to seek more robust alternatives. This talk, "Tabbed Out: Subverting the Android Custom Tab Security Model," presented by Philipp Beer and his co-authors Marco Squarcina, Lorenzo Veronese, and Martina Lindorfer at IEEE S&P, meticulously dissects the security landscape of Android Custom Tabs, a component widely recommended for displaying third-party web content.

The research unveiled six novel vulnerabilities within the Android Custom Tab component, leading to the assignment of three Common Vulnerabilities and Exposures (CVEs). Critically, the team identified a new class of attacks they term "cross-context leaks," which exploit the unique interaction model between the web content displayed in a Custom Tab and the launching application. This presentation provides a comprehensive overview of their methodology, detailed explanations of three prominent attack vectors—the State Inference attack, the Bottom Bar URL Leak, and the Bottom Bar Phishing attack—and proposes mitigation strategies, while also highlighting the challenges posed by current vendor responses.

The findings presented in this talk are crucial for both app developers and browser vendors. They expose the subtle yet profound ways in which a seemingly secure component can be subverted by a malicious or compromised application. The work challenges the conventional understanding of Custom Tab security, demonstrating that despite their improved isolation compared to WebViews, Custom Tabs still present significant attack surfaces that can lead to user de-anonymization, information leakage, and sophisticated phishing campaigns.

Background

▶ Watch: Introduction to "Tabbed Out" paper and talk overview (0:00)

Android applications frequently need to display web content, whether it's an article, a login page, or a product description. To facilitate this, Android provides "in-app browser" components. Historically, the most common of these has been the Android WebView component. While versatile, WebView suffers from several critical security limitations. An application embedding a WebView has substantial control over the displayed web content, enabling it to inject arbitrary JavaScript code or expose native application functions to the website. This poor isolation creates significant attack vectors: a malicious application could inject script to take full control of a benign website, or a malicious website could call sensitive functions within the embedding application. Furthermore, each WebView instance maintains its own separate cookie jar, preventing state sharing with the user's primary browser and complicating single sign-on (SSO) flows.

Recognizing these inherent security shortcomings, Google and other browser vendors began advocating for the use of Android Custom Tabs as a more secure alternative, particularly for displaying third-party websites. A Custom Tab is fundamentally an activity (a screen) of the user's default browser (e.g., Chrome, Firefox, Brave, Edge). Because it runs in a separate process from the launching application, Custom Tabs offer a clearer isolation boundary between the application and the web content. This design was intended to prevent the JavaScript injection and native function calls that plague WebViews.

Despite this enhanced isolation, Custom Tabs have unique characteristics that introduce new security considerations. They are designed to share state (such as cookies) with the underlying browser, which is beneficial for use cases like OAuth 2.0 SSO flows as recommended by RFCs. However, this shared state also means that a user's logged-in status or other browser-wide data can influence the Custom Tab's behavior. Additionally, Custom Tabs can report certain events or callbacks back to the launching application, indicating navigation status (started, finished, failed, aborted). Another key feature is the Bottom bar, a fully customizable section at the bottom of the Custom Tab, which an application can use to display additional information or actions. An application can declare an Android intent to be sent whenever the user interacts with this Bottom bar. While Firefox does not support these callbacks, the other major browsers on Android (Chrome, Brave, Edge) do, creating a complex security model that the presented research meticulously explores.

Key Findings

▶ Watch: Custom Tabs state sharing, callbacks, and Bottom Bar feature (3:00)

The research team identified a total of six new vulnerabilities within the Android Custom Tab component, three of which were assigned CVEs. These findings fundamentally challenge the perception of Custom Tabs as a universally secure solution for displaying third-party web content. The core contribution of this work is the identification and categorization of a novel class of attacks termed cross-context leaks. Unlike traditional cross-site leaks that exploit vulnerabilities within a single web context, cross-context leaks specifically target the information flow between the web content displayed in a Custom Tab (the "web context") and the application that launched it (the "application context"). The goal of these attacks is to enable a potentially unwanted application (PUA) to leak sensitive user information from a benign website.

The talk provides detailed insights into three specific attacks:

1. Cross-Context State Inference Attack: This attack leverages the Custom Tab's callback mechanism to infer sensitive user-specific state information about a website. By observing navigation events (started, finished, failed, aborted) and their timing, an attacker can deduce whether a user is logged in, their location, or other private data based on how a website responds. This can be done stealthily without visible user interaction.

1. Bottom Bar URL Leak: This vulnerability exploits the Custom Tab's Bottom bar feature. The Bottom bar, controllable by the launching application, can be made to display context-related information and trigger an intent containing the current Custom Tab URL upon user interaction. Crucially, this URL can contain user-dependent information, which can be exfiltrated to de-anonymize the user. The researchers found a specific bug in Chromium-based browsers that allows the Bottom bar to overflow and hide the main web content, making the attack highly deceptive.

1. Bottom Bar Phishing Attack: This attack demonstrates how the customizable Bottom bar can be weaponized for sophisticated phishing campaigns. By displaying a fraudulent message or call-to-action within the Bottom bar, an attacker can trick users into believing they are interacting with a legitimate part of the website, leading them to disclose credentials or other sensitive information. The shared state between the Custom Tab and the underlying browser (e.g., displaying the user's profile picture or posts) significantly enhances the illusion of legitimacy, making these phishing attempts particularly effective.

These findings underscore the complex interplay between browser-provided security features and application-level control, revealing that what appears to be a clear isolation boundary can still be subtly manipulated to compromise user privacy and security.

Technical Deep Dive

▶ Watch: Research methodology: documentation, source code, API testing (4:10)

The research methodology employed by Beer et al. was comprehensive, built on four pillars designed to uncover subtle security flaws in the Custom Tab component:

1. Official Documentation Review: The team first scrutinized the official Custom Tabs documentation to identify any general design flaws or ambiguous specifications.
2. Source Code Review (Chrome): This was a critical step, allowing the researchers to discover undocumented functionalities and discrepancies between documented behavior and actual implementation in Chrome, the most widely used Custom Tab provider.
3. Manual API Testing: The Custom Tab APIs were manually invoked with various parameters to test edge cases and validate assumptions about their underlying implementations. This hands-on approach helped uncover unexpected behaviors.
4. Cross-Checking with Web Standards: The observed behavior of Custom Tabs was cross-referenced against established web standards to identify grey areas or potential violations that could lead to vulnerabilities.

Whenever a potential vulnerability candidate was identified, proof-of-concept (PoC) applications were developed and further testing was conducted to measure the impact and capabilities of the attack. Validated vulnerabilities were then reported to the affected browser vendors, resulting in six vulnerability reports and the assignment of three CVEs.

The threat model assumed for all attacks is a potentially unwanted application (PUA) or an application embedding a malicious library or SDK. This application is assumed to be in active use by the user and opens a benign, target website in a Custom Tab.

Cross-Context State Inference Attack

This attack exploits the callbacks that Custom Tabs report back to the launching application. These callbacks include navigation started, navigation finished, navigation failed, and navigation aborted. The core insight is that the firing of these events, and their timing, can be dependent on the user state of a website (e.g., logged in or out).

The attack leverages four key metrics:

• Redirections: JavaScript-based or meta-tag-based redirections within a Custom Tab trigger additional navigation started and navigation finished events for each redirection. An application can count these events to infer if a redirection (e.g., from a login page to a dashboard) occurred.
• Status Codes: If a Custom Tab receives an HTTP status code in the 400 or 500 range with an empty response body, a navigation failed event is fired. This can indicate specific server-side errors or authentication failures tied to user state.
• Content Types: Certain content types, such as video, audio, or PDF files, trigger a navigation aborted event. An application can infer the presence or absence of such content based on user permissions or state.
• Timing: By measuring the time between navigation started and navigation finished events and comparing it to a baseline, an application can infer information. For instance, a logged-in user might experience faster loading times for cached content or slower times for dynamically generated, personalized content.

To make this attack stealthy, the PUA can launch the target website in a Custom Tab, then immediately launch another activity that overlays and hides the Custom Tab. Even though the Custom Tab is visually obscured, the callbacks continue to be reported to the underlying application. This can be done during routine app navigation, where the Custom Tab is opened and hidden between screen transitions, or even by overlaying the same activity, making the attack nearly imperceptible to the user, aside from a brief UI unresponsiveness during the Custom Tab launch.

Bottom Bar URL Leak

The Bottom bar feature allows applications to customize a persistent bar at the bottom of the Custom Tab. Crucially, this bar can be configured to send an Android intent back to the launching application when clicked. The content of this intent includes the URL of the website currently opened in the Custom Tab.

The vulnerability arises because many websites use automatic redirections to URLs that contain user-dependent information (e.g., session IDs, user IDs, or country codes that can be used for de-anonymization). The attack proceeds as follows:

1. Lure the User: The application needs to trick the user into clicking the Bottom bar. The researchers demonstrated this by masquerading the Bottom bar as a cookie banner (e.g., "Accept" or "Deny").
2. Hiding Technique: A critical bug was found in Chromium-based browsers (Chrome, Brave) where an application can pass an element to the Bottom bar that is larger than the bar itself. This oversized element overflows and completely overlays the web content, effectively hiding it. On Edge Custom Tabs, the researchers found that by adjusting the top bar color, they could also hide the URL displayed in the browser's top bar, making it impossible for the user to know which website they are on. While Chrome and Brave did not allow hiding the domain in the top bar, the overflow technique still concealed the main content.
3. Exploitation Flow: The PUA initiates a seemingly legitimate Custom Tab flow (e.g., clicking "more information" about a recipe). Instead of opening the expected recipe website, the application launches a target website (e.g., facebook.com) in a Custom Tab. This Custom Tab is immediately obscured by the overflowing Bottom bar, which displays the fake cookie banner. The user, being privacy-aware, clicks "Deny" (or "Accept") on the cookie banner. This action triggers the intent, sending the Facebook URL (potentially containing user-specific data from an automatic redirect) back to the PUA. Once the URL is exfiltrated, the PUA then opens the real recipe website, completely hiding the attack from the user.

Bottom Bar Phishing Attack

This attack leverages the Custom Tab's ability to display a legitimate-looking website (e.g., Instagram) alongside an attacker-controlled Bottom bar. The deception is potent due to two main reasons:

1. No Visible Distinction: There is no clear visual boundary separating the legitimate web content from the attacker-controlled Bottom bar. The two appear to be part of the same interface.
2. Shared State: Because Custom Tabs share state with the underlying browser, the legitimate website (e.g., Instagram.com) will display the user's actual profile picture, posts, and messages if they are logged in. This creates a powerful false sense of security.

An attacker can use the Bottom bar to display a message indicating suspicious activity (e.g., "Suspicious login detected on your Instagram account") and prompt the user to "Change Password." When the user clicks this button, they are redirected to a phishing page controlled by the PUA, which then harvests their credentials. The user is highly likely to fall for this, as all visual cues (the Instagram domain in the top bar, their profile picture, and the seemingly urgent message) reinforce the belief that they are interacting with Instagram itself.

Demo / Proof of Concept

▶ Watch: Defining cross-context leaks: leaking information across contexts (6:50)

While a live demonstration was not performed during the presentation, the speaker illustrated the attacks using screen captures and figures embedded in the slides, effectively serving as proof-of-concept demonstrations.

For the Cross-Context State Inference attack, a screen capture showed a user clicking an item, a Custom Tab briefly appearing and then immediately being hidden by another activity overlaying it. The speaker emphasized that there was "no clear visual indication that an attack has taken place," although the UI would be unresponsive during the brief Custom Tab launch. This demonstrated the stealthy nature of the information leakage.

For the Bottom Bar URL Leak, figures were presented to show the visual deception. One figure depicted a Facebook page where the Bottom bar was masquerading as a cookie banner, with "Accept" and "Deny" buttons. Another crucial figure illustrated the Chromium bug, showing how an oversized Bottom bar element could completely overflow and hide the web content, leaving only the fake cookie banner visible. The speaker also highlighted how on Edge, the top bar color could be adjusted to hide the URL, further enhancing the deception. The full attack flow was depicted, showing the user initiating a legitimate action, being redirected to a hidden malicious Custom Tab with a fake cookie banner, and ultimately having their URL leaked before the legitimate content was finally displayed.

For the Bottom Bar Phishing attack, a figure showed an Instagram post within a Custom Tab, with the Instagram domain and the user's profile picture visible. The Bottom bar, however, displayed an attacker-controlled message like "Suspicious behavior detected. Change password." This visually demonstrated how the lack of clear distinction between the web content and the Bottom bar, combined with the shared state, could create a convincing phishing scenario.

These visual proofs-of-concept were integral to validating the vulnerabilities and demonstrating the practical feasibility and stealth of the identified attack vectors.

Defensive Implications

▶ Watch: Cross-context state inference attack using custom tab callbacks (7:10)

The research sheds light on critical gaps in the Custom Tab security model and existing web security mitigations.

Limitations of Existing Web Security Measures:

• Framing Protections: Standard framing protections like the X-Frame-Options HTTP header and the Content Security Policy (CSP) frame-ancestors directive are ineffective against Custom Tab attacks. This is because a Custom Tab navigation represents a top-level navigation, not a framed content, making these protections irrelevant.
• SameSite=Strict Cookies: Until very recently, SameSite=Strict cookies were still sent on navigations within Custom Tabs. This was a significant security oversight, as these cookies are designed to prevent cross-site request forgery (CSRF) by restricting cookie sending to same-site requests. Fortunately, this issue has been fixed due to a bug report issued by the researchers and another unrelated third party, both identifying the same root cause. However, SameSite=Lax cookies are still sent on all major browsers, which could potentially be exploited in other attacks not detailed in this specific talk.
• Fetch Metadata Headers: Prior to recent fixes, fetch metadata headers (e.g., Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site) between a Custom Tab and the underlying browser were almost indistinguishable. This allowed Custom Tab attacks to bypass resource and navigation isolation policies that relied on these headers to differentiate trusted from untrusted requests. This issue was also fixed concurrently with the SameSite=Strict cookie problem.

Proposed Mitigations:

The researchers proposed two key mitigation strategies to enhance Custom Tab security:

1. Extend Fetch Metadata Headers:

• Currently, a server cannot reliably determine if a request originated within a Custom Tab. The proposal is to add a new webview directive to the Sec-Fetch-Dest header (e.g., Sec-Fetch-Dest: webview).
• With this information, servers hosting security or privacy-sensitive websites could opt out of being loaded in a Custom Tab. They could achieve this by responding with an HTTP redirection that sets an Android intent as the redirection location.
• This intent would then be handled by the user's default browser (not a Custom Tab), opening the website directly in the full browser and bypassing the Custom Tab's potentially vulnerable context. This redirection strategy already works on Chrome.

1. Restrict State Sharing:

• The current model allows Custom Tabs to share state (like cookies) with the underlying browser by default. This is a double-edged sword, convenient for SSO but also enabling attacks like the Bottom Bar Phishing that rely on a false sense of security.
• The proposal is to change the default behavior so that Custom Tabs do not share state with the underlying browser. State sharing would only be permitted if the user explicitly grants permission, perhaps on a per-application basis, similar to how other sensitive permissions are handled. This would provide users with more control over their privacy and mitigate attacks that exploit shared authentication state.

Vendor Response:

Crucially, the researchers noted that Google (the primary vendor for Chrome Custom Tabs) fixed some of the reported vulnerabilities, but their approach was primarily focused on implementation fixes rather than systematic mitigations addressing the underlying design flaws. More concerning is Google's stance on the State Inference attack and the Bottom Bar Phishing attack: Google will not fix these as they are considered to be "working as intended." This position implies that the demonstrated capabilities are considered part of the Custom Tab's intended functionality, leaving users vulnerable to sophisticated information leakage and phishing campaigns that exploit the design. This highlights a fundamental disagreement between the researchers' security perspective and the vendor's interpretation of the component's intended behavior, posing a significant challenge for widespread adoption of the proposed systematic mitigations.

Key Takeaways

• Android Custom Tabs are not universally secure: Despite being touted as a more secure alternative to WebViews, Custom Tabs introduce new attack surfaces that can be exploited by malicious applications.
• New class of attacks: Cross-Context Leaks: This research identifies a novel category of attacks where sensitive user information is leaked from the web context of a Custom Tab to the launching application context.
• Stealthy Information Inference: The State Inference attack allows applications to deduce user state (e.g., logged-in status, specific content access) by observing Custom Tab navigation callbacks and timing, often without visible user interaction.
• Deceptive Information Exfiltration: The Bottom Bar URL Leak can de-anonymize users by exploiting a Chromium bug to hide web content behind a fake Bottom bar, tricking users into clicking and leaking URLs containing sensitive identifiers.
• Sophisticated Phishing Vectors: The Bottom Bar Phishing attack leverages the lack of visual distinction between web content and the attacker-controlled Bottom bar, combined with shared browser state, to create highly convincing phishing scenarios.
• Vendor Response Challenges: While some implementation bugs were fixed, Google has stated that the State Inference and Bottom Bar Phishing attacks are "working as intended," indicating a divergence in security philosophy and leaving significant vulnerabilities unaddressed.

About the Speaker(s)

The talk "Tabbed Out: Subverting the Android Custom Tab Security Model" was presented by Philipp Beer, who is credited as the primary speaker. This was a joint research effort with Marco Squarcina, Lorenzo Veronese, and Martina Lindorfer. Based on the technical depth of the presentation and the detailed methodology, the speakers are researchers with expertise in mobile security, web security, and vulnerability discovery within complex software components like Android's in-app browsing solutions. Their work contributes significantly to understanding and improving the security posture of Android applications and browser components.