CSP: Network loads triggered by SVG <use href=> are only controlled by default-src. Need spec to explicitly define the directive to use.
Categories
(Core :: DOM: Security, task, P2)
Tracking
()
People
(Reporter: S_K_Tiger, Assigned: tschuster)
References
(Blocks 3 open bugs)
Details
(Keywords: dev-doc-needed, Whiteboard: [domsecurity-backlog1], [wptsync upstream])
Attachments
(3 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Steps to reproduce:
Using XAMPP a php file containing the following was loaded:
// Headers
header("Content-Security-Policy-Report-Only: report-uri php/report.php; default-src 'none'; child-src 'none'; connect-src 'none'; font-src 'none'; frame-src 'none'; img-src 'self'; manifest-src 'none'; media-src 'none'; object-src 'none'; prefetch-src 'none'; script-src 'none'; script-src-elem 'none'; script-src-attr 'none'; style-src 'none'; style-src-elem 'none'; style-src-attr 'none'; worker-src 'none'");
// Getting the head.
echo '<!DOCTYPE html><html lang=nl><head><meta charset=UTF-8><meta name=robots content=none,noindex,nofollow><title>test</title></head>';
// Getting the content.
echo '<body><svg><use xlink:href="./assets/star.svg#svg-star"></use></svg></body>';```
Actual results:
The page was loaded and a CSP report generated.
Report:
```{"csp-report":{"blocked-uri":"http://localhost/CatWeb/assets/star.svg","document-uri":"http://localhost/CatWeb/testpage.php","original-policy":"report-uri http://localhost/CatWeb/php/report.php; default-src 'none'; child-src 'none'; connect-src 'none'; font-src 'none'; frame-src 'none'; img-src 'self'; manifest-src 'none'; media-src 'none'; object-src 'none'; script-src 'none'; style-src 'none'; worker-src 'none'","referrer":"","violated-directive":"default-src"}}```
Expected results:
A different violated directive should've been specified instead of the fallback directive.
Reporter | ||
Comment 1•2 years ago
|
||
In hindsight this could also happen if I missed a fetch directive.
I used all the fetch directives listed here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/default-src
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•2 years ago
|
||
I suspect this should have been frame-src or child-src instead, but maybe we haven't tagged SVG <use> loads as the correct type. (Freddy thinks it might just be a reporting issue)
Assignee | ||
Comment 4•2 years ago
|
||
It seems like Chrome uses image-src
for <use>. We might want to ask on GitHub what the preferred directive is. Internally the load is currently tagged as nsIContentPolicy::TYPE_OTHER
. It looks like we also end up in this method for other kinds of SVG loads, but the name of the method is very generic so maybe this is also used for something else.
Comment 5•2 years ago
|
||
Anything tagged TYPE_OTHER will definitely only be blocked by default-src. Unless it's something internal it's either a mistake or a sign that something hasn't been specified yet. See the note at
https://searchfox.org/mozilla-central/rev/196b6aa0427f38058fd43ac90ee94fcf2f436fb6/dom/base/nsIContentPolicy.idl#34-38
The CSP directive that should govern <use>
is not standardized in the big table in the Fetch spec (which is self-proclaimed to be incomplete), nor does the DOM spec specify this. There are arguments in issues in both the CSP and SVG repos; I've added CSP issue #199 to the See Also above. As JWatt notes in bug 1303364 comment 4 the <use> feature doesn't act like an image or a frame so it's really unclear either of those are appropriate choices.
This is really a dupe of bug 1303364, but that was marked INVALID. It is a real problem that this is not specified and that as a result Chrome and Firefox behavior differs. It may not valid as a "Firefox bug", but it does represent something that needs to be resolved and then ultimately updated in Firefox.
Comment 6•2 years ago
|
||
There's a whole lot of TYPE_OTHER
https://searchfox.org/mozilla-central/search?q=%5B%5E_%5DTYPE_OTHER&path=&case=true®exp=true
Updated•2 years ago
|
Assignee | ||
Updated•11 months ago
|
Comment 8•5 months ago
|
||
Just commenting here for additional visibility. We are aware that this bug prevents people from enforcing a CSP that starts with a very strict default-src
and makes users of Firefox and/or the MDN HTTP Observatory unhappy.
While this is technically a bug in the specification that ought to be resolved more broadly, we will take a look what we can do in the meantime to fix the immediate compat problems.
Updated•5 months ago
|
Assignee | ||
Comment 9•5 months ago
|
||
This is maybe not the best name, because we also use this for e.g. SVGs
used as CSS paths.
Assignee | ||
Comment 10•5 months ago
|
||
Assignee | ||
Comment 11•3 months ago
|
||
We want to give a new nsContentPolicyType to SVG <use> requests, so we
need to tag them correctly at the source.
To be honest, I don't quite know what SVGObserverUtils.cpp is actually
doing.
Updated•3 months ago
|
Comment 12•3 months ago
|
||
SVGObserverUtils looks for changes to the DOM or any other changes e.g. it makes sure that an element has references to another element and those references change then the element updates more concretely it's making this sort of thing work...
<circle id="bar" cx="5" cy="5" r="4" stroke="blue" />
<use href="#myCircle"/>
document.getElementById("bar").setAttribute("id", "myCircle");
Assignee | ||
Comment 13•3 months ago
|
||
Thank you Robert. If I am understanding this example correct, this just seems like a sort of implicit <use> load as well. On the patch Emilio mentioned that we also use it for SVG filters.
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Assignee | ||
Comment 14•3 months ago
|
||
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Comment 15•3 months ago
|
||
After this lands, https://github.com/mdn/content/pull/34592 should probably be mostly reverted.
Assignee | ||
Updated•3 months ago
|
Comment 16•3 months ago
|
||
Comment 18•3 months ago
|
||
bugherder |
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Updated•3 months ago
|
Description
•