[CSP] Blocks the use of style attributes inside SVG without generating console errors

REOPENED
Unassigned

Status

()

P3
normal
REOPENED
3 years ago
11 days ago

People

(Reporter: April, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 ?, firefox65 affected)

Details

(Whiteboard: [domsecurity-backlog], URL)

Attachments

(5 attachments)

(Reporter)

Description

3 years ago
Created attachment 8739043 [details]
black-svg-due-to-csp-no-error-in-console.png

On my website (https://pokeinthe.io), I had an issue where SVG icons were frequently rendering in pure black, instead of with color.  They are generated by my design program (Affinity Designer) and look like this:

> <?xml version="1.0" standalone="no"?>
> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
> <svg width="100%" height="100%" viewBox="0 0 256 250" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:1.41421;">
>     <path d="..." style="fill:rgb(246,188,246);fill-rule:nonzero;"/>
> </svg>

In particular, they have something like these style attributes:

> style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:1.41421;"
> style="fill:rgb(246,188,246);fill-rule:nonzero;"

It took me a long time to figure out what was happening.  It turns out it was due to my site-wide CSP policy:

> Content-Security-Policy:
>   default-src 'none';
>   child-src https://air.mozilla.org;
>   font-src 'self' https://fonts.gstatic.com;
>   frame-ancestors 'none';
>   frame-src https://air.mozilla.org;
>   img-src 'self';
>   media-src 'self';
>   script-src 'self';
>   style-src 'self' https://fonts.googleapis.com

It turns out that Firefox was treating these SVG files as having 'unsafe-inline' and thus blocking the loading of those attributes.  Unfortunately, as you can see in the screenshots, there is no indication that this is happening in the console (black-svg-due-to-csp-no-error-in-console.png). It's in fact *doubly* confusing, because it looks perfectly fine in the network tab (confusing-network-tab.png). To be honest, it's actually *triply* confusing, because Chromium browsers have no problem with these SVG files at all, and so there were no leads in their dev tools either.

The only way I could fix it was enabling a custom CSP header just for SVG files (colored-svg-due-to-custom-csp-policy-for-svg.png).

> default-src 'none'; frame-ancestors 'none'; style-src 'self' 'unsafe-inline'

Inside nginx:

> add_header Content-Security-Policy "default-src 'none'; child-src https://air.mozilla.org; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; frame-src https://air.mozilla.org; img-src 'self'; media-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com";
> 
> location ~ \.svg$ {
>     add_header Content-Security-Policy "default-src 'none'; frame-ancestors 'none'; style-src 'self' 'unsafe-inline'";
> }

See: https://github.com/w3c/webappsec-csp/issues/45 for related discussion.
(Reporter)

Comment 1

3 years ago
Created attachment 8739045 [details]
colored-svg-due-to-custom-csp-policy-for-svg.png
(Reporter)

Comment 2

3 years ago
Created attachment 8739046 [details]
confusing-network-tab.png
Whiteboard: [domsecurity-backlog]
Blocks: 1242016
Duplicate of this bug: 1312240

Comment 4

2 years ago
Pasting/updating my description from bug 1312240:

We recently implemented CSP on gimp.org the most secure way, i.e. without 'unsafe-inline': https://observatory.mozilla.org/analyze.html?host=www.gimp.org

Actual results: We had a small Wilber icon in the top (just left to "GIMP" item in the top black bar) and it ended up black (hence barely visible) because the style is fully inline (as any SVG file straight out of Inkscape): https://www.gimp.org/
It was not spotted until recently (SVG images passed under the inline script/css cleaning radar). All other SVG images used on our website have the same issue.

Note that I found a workaround for the time being: since our styling needs are mostly basic, I could convert all inline CSS into XML attributes ("Optimized SVG" export in Inkscape) with minimal loss, then I clean out all remaining style with a regexp. But this is far from an optimal workflow to have to process every SVG image through an export then do additional cleaning.

https://bugzilla.gnome.org/show_bug.cgi?id=773364

Expected results:
I checked the CSP spec and according to section "3.6 Policy Applicability", when a SVG is embedded via <img>:

> No policy; should be just as safe as JPG

https://www.w3.org/TR/CSP11/#which-policy-applies
So if not mistaken, in our case, since the Wilber icon is indeed included as <img>, Firefox should not apply any policy on the subresource, hence it should apply the inline CSS in the SVG icon.

Also I can confirm that it works as requested by the spec in Chrome: the CSP policy is applied if I display the SVG standalone for instance (no styling, it becomes dark: https://www.gimp.org/images/wilbericon.svg), but it appears ok, with styling, when used as `<img>` (in gimp.org).
Duplicate of this bug: 1315427

Comment 6

2 years ago
This is affecting portswigger.net too. We aren't comfortable with enabling unsafe-inline for styles as a workaround, as this opens up a lot of attack surface.
Priority: -- → P3
Duplicate of this bug: 1381127

Updated

a year ago
Duplicate of this bug: 1410730

Updated

9 months ago
Duplicate of this bug: 1405725

Updated

9 months ago
Duplicate of this bug: 1443435
The language from comment 4 doesn't seem to be in the current CSP spec draft at https://w3c.github.io/webappsec-csp/ nor in https://www.w3.org/TR/CSP3/

That said, looks like CSP is only honored on documents in browsing contexts in general (per https://w3c.github.io/webappsec-csp/#initialize-document-csp which is only called from the HTML spec during navigation).

Christoph, is my understanding there correct?  If so, why are we applying CSP to SVG images loaded via <img> at all?
Flags: needinfo?(ckerschb)
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #11)
> Christoph, is my understanding there correct?  If so, why are we applying
> CSP to SVG images loaded via <img> at all?

Your understanding is absolutely correct. As far as I can tell this is simply a bug in our implementation and we should eventually fix it.
Flags: needinfo?(ckerschb)
Duplicate of this bug: 1493735

Comment 14

21 days ago
WFM in current Nightly using
> Content-Security-Policy: default-src 'self'
and a SVG with inline CSS:
> Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”).
Status: NEW → RESOLVED
Last Resolved: 21 days ago
Resolution: --- → WORKSFORME

Comment 15

20 days ago
(In reply to sjw from comment #14)
> WFM in current Nightly using
> > Content-Security-Policy: default-src 'self'
> and a SVG with inline CSS:
> > Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”).

Did you only test that there was a warning when the inline style is blocked?

Did you also test that an SVG loaded as <svg> loaded fine (i.e. its style was not blocked) despite CSP, since there were kind of 2 issues in this report. Cf. comment 4, later confirmed as a bug in comment 11 and comment 12.
(Reporter)

Comment 16

19 days ago
I just tested with Nightly (65.0a1, 2018-10-29), and not only does the bug not seem to be fixed but I also don't see warnings in the console.

:sjw, were you accessing the .svg files directly? That was never the problem. The problem was SVG files loaded as a subresource.
Status: RESOLVED → REOPENED
Flags: needinfo?(sjw)
Resolution: WORKSFORME → ---

Comment 17

19 days ago
> Did you only test that there was a warning when the inline style is blocked?

I only checked for the console warning. If the CSP shouldn't be applied to the loaded SVG (I used <img>), than I can confirm that the bug does still exist. Can we change the summary to clarify what the main issue is?
Flags: needinfo?(sjw)
(Reporter)

Comment 18

19 days ago
As far as I can tell, neither one of the two issues raised by this bug are solved.

Which test site are you using to see if you are getting console errors? Do you know if there is a patch associated with fixing the console messaging?

Comment 19

19 days ago
I noticed some broken SVGs in a development environment after switching to a more restrictive CSP. There the warning I posted in the console and changing the inline styles to attributes fixed the issue for me.

I just created a simple test case (I think it's not possible to test this when uploaded to Bugzilla):

svg-csp.html:
> <!DOCTYPE html>
> <html>
>         <head>
>                 <meta charset="utf-8">
>                 <meta http-equiv="Content-Security-Policy" content="default-src 'self'">
>                  <title>Testcase</title>
>         </head>
>         <body>
>                 <img src="svg-csp.svg">
>         </body>
> </html>

svg-csp.svg:
> <svg width="150" height="150" viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
>         <style>
>                 circle {
>                         fill: orange;
>                         stroke: black;
>                         stroke-width: 10px;
>                 }
>         </style>
> 
>         <circle cx="50" cy="50" r="40" />
> </svg>

Here are some observations:
* When you open svg-csp.svg you can see the image as expected.
* When you open svg-csp.html you can see the image as expected.
* When you open svg-csp.html and refresh, the circle turns black and an error is logged:
> Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”). svg-csp.html:2:1

The last issue seems to be something new, related to local files. I didn't need to force refresh when the file was server from my development HTTP server.
I tested with a fresh profile in stable and nightly.

The SVG is a modified example from https://developer.mozilla.org/en-US/docs/Web/SVG/Element/style

Comment 20

19 days ago
Created attachment 9020850 [details]
svg-csp.svg

Comment 21

19 days ago
Created attachment 9020851 [details]
Testcase

Comment 22

19 days ago
I added the testcase anyway, but as expected the CSP can not be overwritten in Bugzilla.
(Reporter)

Comment 23

19 days ago
I just undid my fix as noted in comment #1.

If you go to https://pokeinthe.io/ and click on the "Content" dropdown at the top, you will see that the top three SVG files are blacked out (due to CSP) and that no errors occur in the console.
(Reporter)

Comment 24

19 days ago
Err, I meant "Contact", not "Content".

Comment 25

18 days ago
Yes, I can reproduce this. I only see a warning if I access https://pokeinthe.io/theme/images/icons/linkedin.svg directly.
I changed my testcase to load the image by CSS, but I still get the warning there.
(Reporter)

Comment 26

18 days ago
Note that CSP specification states that it is not supposed to be applied to SVG files loaded via <img> tags.

Comment 27

16 days ago
I just experienced it while setting up csp for a site that i'm working on, is this something Mozilla is working on ? Otherwise how can we help ?
Are you taking this on, or can you help find an owner for this bug? We may also want to reconsider the priority (currently set to P3)
status-firefox64: --- → ?
status-firefox65: --- → affected
Flags: needinfo?(april)
(Reporter)

Comment 29

16 days ago
I'm pretty sure that :ckerschb is the owner of this, but I do think that violating the CSP specification in this way should probably be a higher priority for fixing.

I get emails or tweets from people thanking me for writing my blog post about this problem at least once a week - it's the top Google result for "CSP SVG".
Flags: needinfo?(april)

Comment 30

16 days ago
This has also been changed in Edge recently:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7657500/
Christoph, is this something we may want to think about fixing for 65? It looks like we keep steadily getting duplicate reports, which I would take as a sign we should bump the priority on the issue. What do you think?
Flags: needinfo?(ckerschb)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #31)
> Christoph, is this something we may want to think about fixing for 65? It
> looks like we keep steadily getting duplicate reports, which I would take as
> a sign we should bump the priority on the issue. What do you think?

I tried to test this using the attached testcase. In the regular case I see the svg-csp.svg (black circle with orange in the middle). If I change the CSP to default-src 'none' I only see a black circle (no orange), but then I also get the following message in the browser console as well as the web console:

> Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”). svg-csp.html:2:1

Then I tried your testcase from Comment 8. When I go to https://pokeinthe.io/ and click on the 'Contact' menu I see blacked out SVGs in the menu.



Going forward, within Bug 965637 we are moving the CSP from the Principal into the Client (LoadInfo) which will fix a variety of problems around CSP (ultimately also allows us to apply CSP to system privileged pages, see Bug 1492063 and dependents). Anyway, when apply the patches from Bug 965637 both of the above mentioned cases seem to work. Bug 965637 is already in review and I expect it to land within this cycle. I will mark this bug depending on Bug 965637. If there are still issues after Bug 965637 has landed, we will follow up on it.
Depends on: 965637
Flags: needinfo?(ckerschb)
You need to log in before you can comment on or make changes to this bug.