Exploring Browser Permissions and Exploiting Permission Hijacking

Exploring Browser Permissions and Exploiting Permission Hijacking

Speakers: Alberto Fernandez-de-Retana (Researcher)

Conference: DefCamp

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

Overview

In this insightful DefCamp talk, Alberto Fernandez-de-Retana, also known as Boou in the CTF community, sheds light on the often-overlooked complexities and critical vulnerabilities within browser permission models. The presentation, titled "Exploring Browser Permissions and Exploiting Permission Hijacking," delves into how modern web applications manage access to sensitive user data and device capabilities, and, more importantly, how these mechanisms can be subverted. Fernandez-de-Retana, a researcher with a keen interest in web security, web privacy, and browser internals, exposes fundamental misconceptions and implementation flaws that lead to significant security risks, particularly when third-party content is embedded.

The core of the talk revolves around the concept of permission hijacking, a technique that allows an attacker to gain unauthorized access to powerful browser features like the camera, microphone, or screen sharing. This is achieved by exploiting weaknesses in how permissions are delegated and how Permissions Policy headers are implemented (or, more often, not implemented). Fernandez-de-Retana presents two primary attack models, demonstrating real-world vulnerabilities he discovered in popular chat widgets and a critical unpatched flaw affecting all Chromium-based browsers.

This research is highly significant for several reasons. First, it highlights the pervasive underutilization and misconfiguration of crucial security headers like Permissions Policy, leaving countless websites vulnerable. Second, it uncovers how seemingly minor input sanitization or architectural flaws in widely adopted third-party widgets can cascade into full-blown permission compromises. Finally, the revelation of a persistent Chromium vulnerability underscores the ongoing challenge of securing the browser's core permission model, urging both developers and browser vendors to revisit their security postures and implementations.

Background

▶ Watch: Introduction to browser permissions and security focus (0:00)

Modern web browsers manage a diverse array of permissions, granting websites access to various user resources and device capabilities. With approximately 80 permissions and a continuously expanding list (including recent additions related to AI in Chromium), understanding and securing this ecosystem is paramount. Common examples include location access for mapping services, camera and microphone for video conferencing, and screen sharing for collaboration tools.

Browser permissions possess two key characteristics:

• Powerful: These permissions require explicit user consent, typically presented through a prominent browser popup. Examples include access to the camera or microphone.
• Policy Control: This characteristic dictates whether a permission can be delegated from a top-level document to iframes embedded within it. Most permissions are policy-controlled, allowing for granular control over what embedded content can access. There's a default allow list, often restricting permissions to self (the top-level document) unless explicitly delegated. It's crucial to note that while many powerful permissions are also policy-controlled (like the camera), not all policy-controlled features are powerful, and vice-versa. Each permission is governed by its own individual specification, such as "Media Capture and Streams" for camera and microphone, which details its powerful and policy-control integration.

To restrict access to permissions, developers are provided with the Permissions Policy HTTP response header. Formerly known as Feature Policy and rebranded in 2021 with a syntax change, this header allows a website to declare which origins can use specific features. For instance, Permissions-Policy: camera=() would entirely restrict camera access on the page, while Permissions-Policy: clipboard-read=(self); clipboard-write=(self iframe.org) would allow the top-level document to read the clipboard and delegate clipboard writing to iframe.org.

Despite its importance, Fernandez-de-Retana's academic research, published at ACM IMC 2025, revealed alarming statistics. A crawl of the top 1 million websites showed that only around 10% actually declare the Permissions Policy header. Even among those that do, misconfigurations are rampant, such as misplaced commas or contradictory directives like self and * (wildcard), effectively rendering the policy useless.

This lack of proper implementation is compounded by several common misconceptions within the community:

1. Delegation vs. Same-Origin Policy: A crucial misunderstanding is that if a top-level document (food.bar) delegates a permission (e.g., camera) to an embedded iframe.org, iframe.org can then re-delegate that permission to another third-party, say notif.org, even if food.bar's original policy did not permit notif.org. The top-level restriction is effectively lost upon the initial delegation.
2. Misleading Prompt: When an embedded iframe (e.g., meet.example.org within fu.bar) requests a permission, the browser's permission prompt often only displays the top-level domain (fu.bar). This can easily trick users, especially non-technical ones, into granting sensitive permissions to a third-party they are unaware of.
3. No Reporting: After a permission is initially granted to the top-level document, there is no subsequent notification or report to the user if an embedded widget later utilizes that permission via delegation.

These factors create a fertile ground for permission hijacking, where attackers can leverage misconfigurations and browser behaviors to gain unauthorized access to sensitive user data.

Key Findings

▶ Watch: Research findings: chat widgets are prime targets (10:00)

Alberto Fernandez-de-Retana's research and practical exploitation efforts unveiled several critical findings regarding browser permissions and their security:

1. Low Adoption and Misconfiguration of Permissions Policy: A significant discovery from his academic paper (ACM IMC 2025) is that a mere 10% of the top 1 million websites properly implement the Permissions Policy header. Furthermore, many of these implementations are flawed with syntax errors (e.g., misplaced commas) or contradictory directives, rendering them ineffective. This widespread negligence leaves a vast number of web applications vulnerable by default.
2. Chat Widgets as a Primary Attack Vector: The research identified customer support and chat widgets as a particularly high-risk category. These widgets consistently delegate powerful permissions like camera, microphone, and display capture, often regardless of whether the functionality is actively used. Their ubiquitous presence across diverse websites, including banking platforms, makes them an attractive target for permission hijacking.
3. Real-World Vulnerabilities Leading to Permission Hijacking: Fernandez-de-Retana successfully identified and exploited vulnerabilities in two widely used chat widget platforms: Glasses (used by 100-2,000 websites) and Live Chat (used by 38,000 to 500,000 websites). These exploits demonstrated how an attacker could inject malicious code, achieve Cross-Site Scripting (XSS), escalate privileges (in the case of Live Chat), and ultimately force a second delegation of powerful permissions to an attacker-controlled domain.
4. Chromium-Specific Permissions Policy Bypass via Local Schemes: A critical, unpatched vulnerability was discovered in all Chromium-based browsers. This flaw allows an attacker to bypass a correctly configured Permissions Policy (even one set to self) by using local scheme documents (like data: or javascript: URLs) as an intermediary. Local scheme documents, due to their unique nature of having no request/response, do not inherit the Permissions Policy from their parent frame, enabling unauthorized permission delegation.
5. The Severity of Misconceptions: The talk underscored that the community's misconceptions regarding permission delegation, misleading prompts, and lack of reporting are not merely theoretical. They are actively exploited as crucial components in sophisticated permission hijacking attacks, allowing attackers to trick both developers and end-users.

These findings collectively paint a picture of a browser permission model that, while designed for security, is often undermined by implementation complexities, developer oversight, and fundamental browser-level vulnerabilities.

Technical Deep Dive

▶ Watch: Live Chat exploit: Markdown vulnerabilities, XSS, and account takeover (22:00)

The technical core of Fernandez-de-Retana's talk explored two distinct, yet interconnected, attack models for browser permission hijacking.

Attack Model 1: Hacking Embedded Documents with Delegation

This model focuses on exploiting vulnerabilities in popular third-party widgets that are frequently embedded across numerous websites and consistently delegate powerful permissions.

Case Study 1: Glasses Chat Widget

The first target was Glasses, a chat widget found on hundreds to thousands of websites. Fernandez-de-Retana discovered a vulnerability related to how Glasses handles attachments in its chat interface.

1. Iframe Injection: By manipulating an attachment parameter's type attribute, specifically setting it to 8, an attacker could inject an arbitrary iframe into the chat interface. This iframe would appear on both the attacker's and the worker's (customer support agent's) chat view.
2. Local Scheme Documents: To inject arbitrary HTML and JavaScript into this iframe, the attacker leveraged local scheme documents (e.g., data: or javascript: URLs). These schemes are unique because they do not involve a network request or response, meaning they don't carry HTTP headers like Content-Security-Policy (CSP). This allows them to execute arbitrary code within their context, bypassing many traditional web security controls.
3. CSP Bypass for XSS: Glasses implemented a Content-Security-Policy (CSP), which typically prevents arbitrary script execution. However, Fernandez-de-Retana utilized a common CSP bypass technique. Using a tool like CSP bypass, he analyzed Glasses's CSP header and found that it broadly allowed scripts from the recaptcha endpoint. By loading a specific JavaScript payload from this allowed recaptcha path, he could then use an event handler (similar to those found in frameworks like Angular) to execute arbitrary JavaScript on the worker's end. This achieved Cross-Site Scripting (XSS) on the support agent's console.
4. Payload Delivery and Second Delegation: The next step involved injecting the permission hijacking payload. Assuming the worker had sufficient privileges (e.g., admin access or the ability to modify the widget configuration), the XSS payload would leverage Glasses's administrative panel. This panel included a feature for "embedded apps," essentially allowing an iframe to be inserted within the chat widget's own iframe. Using another local scheme document, the attacker could insert their malicious iframe with the delegation logic into the company's widget.
5. Permission Hijacking: When a user then visited a website embedding the compromised Glasses widget, the malicious iframe would be loaded. Due to the earlier delegation by the top-level document, and the re-delegation capability of the compromised widget, the attacker's iframe could request powerful permissions (camera, microphone). Crucially, the browser's permission prompt would misleadingly display the top-level domain, not the attacker's origin, tricking the user into granting permission. A small Proof-of-Concept (PoC) test confirmed the XSS part of the attack, with the attacker receiving a ping from a remote IP. The vulnerability was reported on May 14th and fixed rapidly by May 17th.

Case Study 2: Live Chat Widget

The second target was Live Chat, a significantly more popular widget used by hundreds of thousands of websites. This case was more complex due to Live Chat's architecture.

1. Two-Iframe Architecture: Live Chat employs a two-iframe structure: a same-origin iframe for the initial corner icon, and a separate, cross-origin iframe (from livechat.com's domain) that handles the actual chat and where permission delegation occurs.
2. Marketplace Vulnerabilities: Fernandez-de-Retana focused on the Live Chat admin panel, specifically its marketplace for plugins. The comment section within this marketplace used Markdown rendered by the markdown-to-jsx library. Despite no security mentions in the library's readme, he discovered several vulnerabilities:

• Denial of Service (DoS): Using the contenteditable attribute in Markdown could crash the plugin page, making it inaccessible.
• Meta Redirect: An attacker could inject meta redirect tags, causing users visiting the plugin page to be redirected to an arbitrary attacker-controlled URL, potentially for phishing.
• Style Injection: CSS injection was possible, allowing manipulation of page styles. While not directly leading to data exfiltration in this context, it could be used for UI defacement or other deceptive purposes.
• One-Click XSS: The most critical finding was the ability to inject a button with a malicious form action attribute. If an admin clicked anywhere on the page (even an invisible button covering the screen), it would execute JavaScript.

1. Privilege Escalation: The XSS occurred within the marketplace iframe, which was on a different domain than the main admin panel. However, a critical design flaw meant that the access token used by the marketplace had the same privilege level as the main admin panel's token. This allowed the attacker, through the one-click XSS, to perform an account takeover or other administrative actions.
2. Payload Delivery and Second Delegation (Injection): With admin privileges, the attacker could modify the company's Live Chat widget. While most parameters were sanitized, one specific parameter allowed for HTML injection into the first (same-origin) iframe. This was a crucial distinction, as it enabled an XSS or HTML injection on the top-level document's context, making the subsequent permission delegation easier. The attacker could then insert their malicious iframe, leading to permission hijacking via the misleading prompt as before. This vulnerability was reported on November 29th and fixed within nine days.

Attack Model 2: Bypassing Permissions Policy with Local Schemes (Chromium Flaw)

This second model highlights a fundamental vulnerability in Chromium-based browsers that bypasses even correctly implemented Permissions Policy headers.

1. Scenario: Consider a website (e.g., a video conferencing platform) that uses a powerful permission (like camera) and might even have a strong CSP. If this site doesn't declare a Permissions Policy header, an HTML injection vulnerability could still allow an attacker to embed an iframe and perform a second delegation.
2. The Permissions Policy Bypass: The intended solution is for websites to declare Permissions-Policy: camera=(self) to restrict permission usage to the top-level document. However, Fernandez-de-Retana discovered that local scheme documents (e.g., data:, javascript:) do not inherit the Permissions Policy from their parent frame in Chromium-based browsers.
3. The Attack: An attacker can craft a local scheme iframe that acts as a middleman. Even if the parent document has Permissions-Policy: camera=(self), this local scheme iframe, due to the flaw, can then delegate the camera permission to attacker.com. This effectively bypasses the Permissions Policy entirely. This vulnerability was reported last year (prior to the talk) and, as of the DefCamp presentation, still works in all Chromium-based browsers, posing a significant, unpatched risk.

These detailed technical breakdowns showcase how a combination of application-level vulnerabilities (XSS, input sanitization flaws), architectural weaknesses (privilege model in Live Chat), and browser-level flaws (Chromium's local scheme handling) can be chained together to achieve sophisticated permission hijacking.

Demo / Proof of Concept

▶ Watch: Second threat model: Hacking sites without Permissions Policy (28:00)

While the talk did not feature live, end-to-end demonstrations during the presentation, Alberto Fernandez-de-Retana provided clear evidence and confirmation of the vulnerabilities he discovered.

For the Glasses chat widget, a small-scale proof-of-concept test was conducted for the initial XSS phase. The speaker confirmed that he successfully sent a message containing the malicious payload and received a "ping" (likely an HTTP request from the XSS-controlled browser) from an IP address outside his country. This validated the ability to execute arbitrary JavaScript on the worker's machine. The subsequent steps of injecting the final payload into the widget's configuration were described as feasible given the confirmed XSS and assumed admin privileges, leading to the second delegation and permission hijacking. The rapid fix by Glasses (reported May 14th, fixed May 17th) further attests to the severity and exploitability of the reported issue.

Regarding the Live Chat widget, the speaker detailed the sequence of vulnerabilities, including the Markdown parsing flaws leading to one-click XSS and the critical privilege escalation due to shared access tokens. Although a live demo of the full chain wasn't shown, the successful account takeover and the ability to inject code into the first (same-origin) iframe were confirmed through the research. The prompt fix by Live Chat (reported November 29th, fixed nine days later) again underscores the validity and impact of the findings.

Finally, for the Chromium Permissions Policy bypass via local schemes, Fernandez-de-Retana explicitly stated that this vulnerability was reported prior to the talk and remains unpatched in all Chromium-based browsers. This implies that the proof-of-concept for this browser-level flaw is readily demonstrable and effective, allowing an attacker to delegate permissions even when a Permissions Policy is ostensibly in place. While a live demonstration of this specific flaw wasn't part of the presentation, its continued existence highlights a critical, known vulnerability.

Defensive Implications

▶ Watch: Q&A: Challenges and common bypasses for Content Security Policy (34:00)

The vulnerabilities and attack techniques presented by Alberto Fernandez-de-Retana carry significant defensive implications for developers, website administrators, and even end-users.

For Web Developers and Administrators:

• Implement and Audit Permissions Policy: The most critical takeaway is the urgent need to implement the Permissions Policy HTTP header correctly and comprehensively.
• Default to self: For most powerful permissions (e.g., camera, microphone, geolocation), set the policy to (self) to ensure only the top-level document can request them.
• Empty for Sensitive Features: For highly sensitive or rarely used features, consider () to completely disable them.
• Avoid Wildcards: Be extremely cautious with * (wildcard) as it negates much of the policy's protective value.
• Regular Audits: Regularly audit your Permissions Policy header for syntax errors (like misplaced commas) or contradictory directives, which can silently disable the policy.
• Exercise Extreme Caution with Third-Party Widgets: Any embedded third-party content, especially chat widgets, analytics scripts, or social media plugins, should be treated as a potential attack vector.
• Strict Policies: Apply the strictest possible Permissions Policy to iframes that embed third-party content. Do not delegate powerful permissions unless absolutely necessary for the widget's core functionality.
• Vendor Security: Evaluate the security posture of third-party widget vendors. Prioritize those with a strong security track record and transparent vulnerability disclosure processes.
• Robust Input Sanitization: Implement thorough input sanitization for all user-supplied data, regardless of where it's entered (e.g., chat messages, comment sections, admin panels). Markdown parsers and other content rendering engines are common sources of XSS and injection flaws.
• Principle of Least Privilege for Access Tokens: Ensure that different components of your application (e.g., marketplace plugins vs. core admin panel) operate with distinct access tokens that have granular, minimum necessary privileges. Sharing high-privilege tokens across potentially less secure modules (as seen in Live Chat) creates a critical escalation path.
• Fortify Content Security Policy (CSP): While Permissions Policy is for browser features, CSP is crucial for preventing XSS.
• Avoid Broad Directives: Do not use overly broad script-src directives (e.g., allowing entire domains like recaptcha.com/*) if specific paths or nonces/hashes can be used. Broad allowances create avenues for attackers to load malicious scripts from otherwise trusted origins.
• Use Nonces/Hashes: Employ script-src nonces or hashes to ensure only explicitly authorized scripts can execute.
• Stay Informed on Browser Vulnerabilities: Keep abreast of browser-level vulnerabilities, especially those affecting core security features like Permissions Policy (e.g., the Chromium local scheme bypass).

For Browser Vendors:

• Address Core Vulnerabilities: Prioritize fixing fundamental browser flaws, such as the Permissions Policy inheritance issue with local scheme documents in Chromium. These vulnerabilities undermine developer efforts to secure their applications.
• Improve Permission Prompt Clarity: Enhance the user interface of permission prompts to clearly indicate the origin (top-level domain AND embedded iframe's origin) that is requesting the permission, mitigating the "misleading prompt" misconception.
• Implement Permission Reporting: Consider adding mechanisms to notify users or developers when delegated permissions are actively being used by embedded content, post-initial grant.

For End-Users:

• Be Skeptical of Permission Prompts: Always scrutinize browser permission prompts. Understand which website is asking for access to your camera, microphone, or screen, and consider if that access is truly necessary for the task at hand.
• Limit Permission Grants: Grant sensitive permissions only when absolutely required and revoke them when no longer needed.

By addressing these defensive implications, the web ecosystem can significantly reduce its exposure to permission hijacking and other related browser-based attacks.

Key Takeaways

• Browser Permissions are a Complex Attack Surface: Despite their critical role in web security, browser permissions are often misunderstood, leading to widespread vulnerabilities. The sheer number of permissions (~80 and growing) and their intricate interactions with delegation models create significant complexity.
• Permissions Policy is Underutilized and Misconfigured: A staggering 90% of top websites fail to implement Permissions Policy, and many of those that do suffer from critical misconfigurations. This leaves a vast segment of the internet vulnerable to unauthorized access to powerful browser features.
• Third-Party Widgets are High-Risk Vectors: Ubiquitous embedded components, particularly chat widgets, are prime targets. Their tendency to broadly delegate powerful permissions, combined with potential application-level vulnerabilities (XSS, input injection), creates a direct path for attackers to hijack sensitive user data.
• Local Scheme Documents Enable Policy Bypass: The unique behavior of local scheme documents (data:, javascript:)—specifically their failure to inherit Permissions Policy from parent frames in Chromium-based browsers—represents a critical, unpatched browser-level flaw that can circumvent carefully crafted security policies.
• Chaining Minor Flaws Leads to Major Compromise: Seemingly minor vulnerabilities, such as a Markdown parsing flaw in a comment section or an overly broad CSP directive, can be chained together with architectural weaknesses (e.g., shared access tokens) to achieve full account takeover and subsequent permission hijacking.
• User Deception is a Key Attack Component: The "misleading prompt" where only the top-level domain is shown when an embedded iframe requests permission, is a crucial social engineering element that exploits user trust and allows attackers to gain consent for sensitive operations without explicit user awareness.

About the Speaker(s)

Alberto Fernandez-de-Retana, professionally known as Boou in the Capture The Flag (CTF) community, is a dedicated researcher specializing in web security, web privacy, and browser-related technologies. He actively participates in CTF competitions, being part of a hacker crew that reached the finals of the devan competition mentioned in his talk. Fernandez-de-Retana is also an invited member of the W3C Security Interest Group, indicating his involvement in shaping web standards and security best practices. His work includes academic research, such as the paper presented at ACM IMC 2025, focusing on browser permission usage and misconfigurations, demonstrating his commitment to advancing the understanding and security of the web.