CSP3: Consider adding a 'clone-src' directive

jwatt commented 7 years ago

SVG has a element which is supposed to reference some other markup and have the document act as if the was replaced by that markup. In Firefox, is implemented by cloning the referenced content into the , whereas in other UAs I believe they redirect rendering off to the original content (with some on-the-fly restyling to inherit style in from the ) without cloning. The 'img-src' and 'frame-src' directives are not appropriate (at least in the case of Firefox) since the linked content will end up inline in the referencing document.

annevk commented 7 years ago

If the difference between implementation techniques is actually observable, this is something SVG needs to fix first.

mikewest commented 7 years ago

I don't actually understand the request. :) Is there an example I could look at?

mozfreddyb commented 7 years ago

This is a spin-off of https://bugzilla.mozilla.org/show_bug.cgi?id=1303364 in which the example is <svg><use xlink:href="foo.svg"></svg>.

Firefox governs this via default-src, because it's not really an image load

michaelficarra commented 7 years ago

There should be nothing governed by default-src which wouldn't otherwise be governed by a more specific directive. default-src has no enforcement of its own. Many other directives just delegate to it. Something is certainly wrong with Firefox.

mozfreddyb commented 7 years ago

Yeah. That's why there's a bug. And this issue.

michaelficarra commented 7 years ago

:+1: got it

mikewest commented 7 years ago

What are the capabilities of <use>? Sorry, I'm woefully underinformed about SVG. If the code that's pulled in can run script, then I'd suggest we treat it as script-src. If it can't run script, and only affects the presentation of the SVG content, then treating it as img-src makes sense from a capabilities perspective. I'm not sure it's valuable to add more granular types for something so specific, unless it really presents new capabilities I'm unaware of.

craigfrancis commented 7 years ago

I'd have thought the <use xlink:href="foo.svg"> would be controlled by img-src if it pulls down a second SVG image.

If that second SVG contains JavaScript, that should be restricted by script-src.

This is how it works with <image xlink:href="foo.svg">.

https://www.w3.org/TR/SVG11/struct.html#UseElement

index.php

<?php

    header("Content-Security-Policy: default-src 'none'; img-src 'self';");

?>
<!DOCTYPE html>
<html lang="en-GB" xml:lang="en-GB" xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="UTF-8" />
    <title>SVG Use</title>
</head>
<body>

    <svg width="230" height="120" version="1.1">
        <image x="10" y="10" width="100px" height="100px" xlink:href="./rect.svg#myShape"><title>My image</title></image>
        <use x="120" y="10" width="100px" height="100px" xlink:href="./rect.svg#myShape"></use>
    </svg>

</body>
</html>

rect.svg

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <g id="myShape">
        <rect x="0" y="0" width="100" height="100" />
    </g>
</svg>

In Firefox 52 only the image rectangle is shown, the second rectangle results in a CSP error.

In Chrome 57, both rectangles are shown.

patrickdark commented 7 years ago

I ended up here after running into an SVG CSP issue in Firefox.

The use element creates a Shadow DOM (https://www.w3.org/TR/shadow-dom/) that works similar to an iframe element in that it may not necessarily import an image and maintains a separate DOM tree based on my reading of the SVG2 Candidate Recommendation spec: https://www.w3.org/TR/SVG2/struct.html#UseElement.

Unlike an iframe, however, it can reference subsections of both the same document and external documents (as opposed to whole documents) and is restricted to same-origin requests.

SVG 2 seems to have dropped the SVG 1.1 restriction on the referenced element being an enumerated list of potential SVG elements (implicitly indicating that it can potentially reference any element in any namespace given browser support) and specifically allows the indirect reference of HTML audio, canvas, iframe, and video elements at https://www.w3.org/TR/SVG2/embedded.html#HTMLElements, which seems to cut against relying on img-src.

child-src seems to be the closest match.

Also, use has some magical behaviors like allowing its subtree to inherit styles from its use element. Firefox's implementation does seem to literally "inline" the copied element since CSS selectors like use rect can select the rect element in craigfrancis's code example even though the SVG specs indicate that this shouldn't be possible. (SVG 2 makes this possible with use::shadow rect via CSS1 Scoping though: https://www.w3.org/TR/css-scoping-1/#shadow-pseudoelement.)

M3kH commented 4 years ago

This issue is kind of important if we want move forward with SVG sprites and seems that at 3 years of his creation there isn't done any progress, is there something we can help with?

Does Firefox needs to change the CSP validation or does the Spec needs to be change? The only discussion that seems going a bit forward is the SVG spec that seems to have a draft to accept crossorigin attributes. Does that help?

Thanks for your work.

cudail commented 1 year ago

I have discovered this problem for myself today and I must say it's frustrating to find five year old discussions of an issue and no progress on it.

la-magra commented 1 year ago

Yeah, definitely surprising, specially because the mozilla observatory now recommends setting the CSP default-src as 'none' and it ends up breaking sites that use svg-sprites (on firefox)...

evilpie commented 3 months ago

Linking the Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1773976.

w3c / webappsec-csp

CSP3: Consider adding a 'clone-src' directive #199