Closed Bug 1773976 Opened 2 years ago Closed 2 months ago

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)

Product:
Core
Component:
DOM: Security
Version:
Firefox 101
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
132 Branch
Tracking Flags:
Tracking Status
firefox130 --- wontfix
firefox131 --- wontfix
firefox132 --- fixed

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)

Bug 1773976 - Add a new nsContentPolicyType TYPE_INTERNAL_EXTERNAL_RESOURCE. r?emilio!,#necko-reviewers!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1773976 - Treat SVG <use> and CSS filter as img-src in CSP. r?freddyb
48 bytes, text/x-phabricator-request
Details | Review
Bug 1773976 - Add tentative WPT for SVG/CSS-filter img-src. r?freddyb
48 bytes, text/x-phabricator-request
Details | Review

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.

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

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.

Component: Untriaged → DOM: Security
Product: Firefox → Core

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)

Blocks: csp-w3c-3
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

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.

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.

Type: defect → task
See Also: → https://github.com/w3c/webappsec-csp/issues/199, 1303364
Summary: default-src is triggered despite all other CSP fetch directives being specified → network loads triggered by SVG <use href=> are only controlled by default-src. Need spec to explicitly define the directive to use.
Duplicate of this bug: 1872603
Summary: network loads triggered by SVG <use href=> are only controlled by default-src. Need spec to explicitly define the directive to use. → CSP: Network loads triggered by SVG <use href=> are only controlled by default-src. Need spec to explicitly define the directive to use.

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.

Priority: P3 → P2

This is maybe not the best name, because we also use this for e.g. SVGs
used as CSS paths.

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.

Assignee: nobody → tschuster
Status: NEW → ASSIGNED

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");

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.

Attachment #9421752 - Attachment is obsolete: true
Attachment #9413192 - Attachment description: WIP: Bug 1773976 - Add a new nsContentPolicyType TYPE_INTERNAL_SVG_USE → Bug 1773976 - Add a new nsContentPolicyType TYPE_INTERNAL_EXTERNAL_RESOURCE. r?emilio!,#necko-reviewers!
Attachment #9413193 - Attachment description: WIP: Bug 1773976 - Treat SVG <use> as img-src in CSP → Bug 1773976 - Treat SVG <use> and CSS filter as img-src in CSP. r?freddyb
Keywords: leave-open
Keywords: dev-doc-needed

After this lands, https://github.com/mdn/content/pull/34592 should probably be mostly reverted.

See Also: → 1624471
See Also: → https://github.com/whatwg/fetch/issues/1012
Blocks: 1917574
Pushed by tschuster@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/04bbd28955f8 Add a new nsContentPolicyType TYPE_INTERNAL_EXTERNAL_RESOURCE. r=emilio https://hg.mozilla.org/integration/autoland/rev/57561bb6a5d2 Treat SVG <use> and CSS filter as img-src in CSP. r=freddyb https://hg.mozilla.org/integration/autoland/rev/f4a754ad50ce Add tentative WPT for SVG/CSS-filter img-src. r=freddyb
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/48042 for changes under testing/web-platform/tests
Whiteboard: [domsecurity-backlog1] → [domsecurity-backlog1], [wptsync upstream]
Upstream PR merged by moz-wptsync-bot
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
status-firefox130: --- → wontfix
status-firefox131: --- → wontfix
status-firefox132: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 132 Branch
Blocks: 1918039
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: