Closed
Bug 1457100
(CVE-2020-12391)
Opened 7 years ago
Closed 5 years ago
CSP: embedding resource's policy does not affect data: URL documents loaded via OBJECT elements
Categories
(Core :: DOM: Security, defect, P2)
Core
DOM: Security
Tracking
()
VERIFIED
FIXED
mozilla76
People
(Reporter: ma1, Assigned: ckerschb)
References
(Blocks 2 open bugs)
Details
(Keywords: sec-moderate, Whiteboard: [domsecurity-active][post-critsmash-triage][adv-main76+])
Attachments
(2 files)
Step to reproduce:
1. Navigate the following data URL (or create a HTML document with the same content and navigate it):
data:text/html,<meta http-equiv="Content-security-policy" content="script-src none;"/><script>alert(location)</script><object data="data:text/html,object<script>alert('object')</script>"></object><iframe src="data:text/html,iframe<script>alert('frame')</script>"></iframe>
Expected result: no JavaScript gets executed (no alert is shown)
Actual result: one alert saying "object" is shown
This demonstrates that the iframe's document inherits parent's CSP, but the object's document doesn't. According to https://www.w3.org/TR/CSP2/#which-policy-applies they should behave the same way, i.e. being governed by "the policy of the embedding resource".
This can be also used to bypass WebExtensions relying on CSP to block scripts: even though the embedded document has null origin, it could deliver a self-contained exploit.
|
||
Updated•7 years ago
|
Group: core-security → dom-core-security
Keywords: sec-moderate
|
|
||
Comment 1•7 years ago
|
||
This should be easier to fix when we move CSP to the loadinfo (bug 965637)
Priority: -- → P3
Whiteboard: [domsecurity-backlog2]
|
|
||
Comment 3•5 years ago
|
||
Did this actually get fixed by bug 965637 as predicted?
Flags: needinfo?(ckerschb)
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 5•5 years ago
|
||
I am clearing old ni?s at the moment and I realized bug 965637 did not fix the problem described here, though it made it easier to fix the problem described here. Assigning to myself.
Assignee: nobody → ckerschb
Status: NEW → ASSIGNED
Flags: needinfo?(ckerschb)
Priority: P3 → P2
|
|
Assignee | |
Updated•5 years ago
|
Whiteboard: [domsecurity-backlog2] → [domsecurity-active]
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
||
Comment 7•5 years ago
|
||
https://hg.mozilla.org/integration/autoland/rev/ec542d9a0338166e2442a77b8f052c3b054a7fd7
https://hg.mozilla.org/mozilla-central/rev/ec542d9a0338
Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox76:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
|
|
||
Updated•5 years ago
|
status-firefox74:
--- → wontfix
status-firefox75:
--- → wontfix
status-firefox-esr68:
--- → wontfix
Depends on: 965637
Flags: in-testsuite+
|
||
Updated•5 years ago
|
Flags: qe-verify+
Whiteboard: [domsecurity-active] → [domsecurity-active][post-critsmash-triage]
|
||
Comment 8•5 years ago
|
||
This issue is verified as fixed in our latest Nightly build 76.0a1 (2020-04-01) on Windows 10, Mac os 10.13 and Ubuntu 16.04.
|
||
Updated•5 years ago
|
Whiteboard: [domsecurity-active][post-critsmash-triage] → [domsecurity-active][post-critsmash-triage][adv-main76+]
|
|
||
Comment 9•5 years ago
|
||
|
|
||
Updated•5 years ago
|
Alias: CVE-2020-12391
|
|
||
Updated•4 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•