CSP strict-dynamic bypass via shimmed Disqus embed code
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox146 | --- | wontfix |
| firefox147 | + | verified |
| firefox148 | + | verified |
People
(Reporter: masatokinugawa, Assigned: emz)
References
(Regression)
Details
(4 keywords, Whiteboard: [client-bounty-form][adv-main147.0.2+])
Attachments
(3 files)
Summary
This is a similar bug to Bug 1909241. When Firefox's Strict Enhanced Tracking Protection is enabled, certain tracking contents are shimmed.
Disqus embed code is one of them. When Firefox detects the Disqus embed code, loading is blocked until the user explicitly allows it. This unblocking process can be abused to bypass CSP strict-dynamic. It allows an attacker to execute arbitrary JavaScript even if the page has strict CSP rules.
Steps to reproduce
- Open https://vulnerabledoma.in/fx_csp_bypass_strict-dynamic_disqus.html with Strict Enhanced Tracking Protection enabled. This page contains strict CSP rules:
<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'nonce-random' 'strict-dynamic'; [...]">
- Click on the
Allow on vulnerabledoma.inbutton. - Click on the
Allow Disqustoggle button. An alert dialog will pop up.
Root cause
This querySelector call incorrectly selects a non-Disqus script:
https://searchfox.org/firefox-main/rev/2fd8beb47a8fd1a767e35a987dff4e0ec2536245/browser/extensions/webcompat/shims/disqus-embed.js#13-15
In the PoC case, <script src="data:,alert(document.domain)//.disqus.com/embed.js"></script> is retrieved wrongly.
After loading is allowed via the toggle button, the script is loaded via the following createElement(), bypassing strict-dynamic:
https://searchfox.org/firefox-main/rev/2fd8beb47a8fd1a767e35a987dff4e0ec2536245/browser/extensions/webcompat/lib/smartblock_embeds_helper.js#52-58
Updated•7 months ago
|
Comment 1•7 months ago
|
||
Set release status flags based on info from the regressing bug 1965307
:emz, since you are the author of the regressor, bug 1965307, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•7 months ago
|
| Assignee | ||
Updated•7 months ago
|
| Assignee | ||
Comment 2•7 months ago
|
||
I can reproduce. To address this we most likely want to properly inspect the src value using JS. We can parse it as a URL first and then do checks on it. We could make the query selector more strict, but that could be bypassed too.
Comment 3•7 months ago
•
|
||
We shouldn't even be looking at the wrong script URLs of course, but we could also think about injecting the scripts in a way that the page's CSP (and other policies like the Integrity-Policy) apply.
Edit: Actually this might be complicated for cases where the original script tag has a nonce.
| Assignee | ||
Comment 4•7 months ago
|
||
(In reply to Tom Schuster (MoCo) [PTO Dec 23 - Jan 4] from comment #3)
We shouldn't even be looking at the wrong script URLs of course, but we could also think about injecting the scripts in a way that the page's CSP (and other policies like the Integrity-Policy) apply.
Right, so I'm surprised that injecting the script like here: https://searchfox.org/firefox-main/rev/2fd8beb47a8fd1a767e35a987dff4e0ec2536245/browser/extensions/webcompat/lib/smartblock_embeds_helper.js#52-58 doesn't enforce CSP. It's possible that the comment about the principal is wrong.
Updated•7 months ago
|
| Assignee | ||
Comment 5•7 months ago
|
||
| Assignee | ||
Comment 6•7 months ago
|
||
I've attached a patch that is more strict about which script URIs it picks. We should also fix the CSP bypass issue itself, I'm still looking into that.
Updated•7 months ago
|
Comment 8•7 months ago
|
||
Updated•7 months ago
|
Comment 9•7 months ago
|
||
The patch landed in nightly and beta is affected.
:emz, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox147towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 10•7 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D277442
Updated•7 months ago
|
Comment 11•7 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined: Sites can trick Firefox into injecting custom scripts (via our shim embed logic) which bypasses strict-dynamic CSP.
- Code covered by automated testing: no
- Fix verified in Nightly: yes
- Needs manual QE test: yes
- Steps to reproduce for manual QE testing: See https://bugzilla.mozilla.org/show_bug.cgi?id=2007302#c0
- Risk associated with taking this patch: low
- Explanation of risk level: Fairly small code change. The updated code only runs when tracking protection is enabled and when the user visits a site with Disqus embeds.
- String changes made/needed: no
- Is Android affected?: yes
Updated•7 months ago
|
Updated•7 months ago
|
Comment 12•7 months ago
|
||
I've repro this issue with the STR from comment 0, on an affected Nightly build (2025-12-21).
The issue is verified as fixed on latest Nightly 148.0a1 under Win 11, macOS 26.1 and Ubuntu 24.04.
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Comment 13•6 months ago
|
||
| uplift | ||
Updated•6 months ago
|
Comment 14•6 months ago
|
||
This bug is also verified as fixed on Firefox 147.0.2 under Win 11, macOS 26 and Ubuntu 24.
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•2 months ago
|
Description
•