Bug 147568 – The SVG <image> element can only be loaded if it is a data uri or its SVGDocument is interactive

• Component: SVG
• Status: NEW

[Said Abou-Hallawa]

The specs does not say a non-interactive SVG can't load sub-resources form the same origin. This has been limiting building a structure of SVG images. It has been also confusing because we allow loading the same image for interactive SVG document but we do not for non-interactive SVG document. The only reliable solution is to make the SVG self-contained by including the external resources as data uri images. This solution is also cumbersome since it enforces duplicating the same image data if it is referenced by multiple images. It also makes updating the data uri images a lengthy process especially for cases like including the company logo in all the SVG images.

Since there is nothing in the specs which prevents loading sub resources from an SVG image (at least from the same origin) and since it seems important feature in organizing the graphics documents and make sharing resources useful and effective, I proposing this change. I am collecting a list if issues I have found from testing my change and from discussing this change with other WebKit developers.

1. IE is the only browser which supports loading an image from an SVG. Chrome and FireFox does not allow SVG from loading external images except for interactive SVG images.
2. We need to handle the circular referencing the same way we do for <iframe>.
3. WebInspector might need to show the hierarchy of SVG image referencing.
4. The specs does not say if a data uri image can or can't reference external resource, but I think they should not. The data uri resources should be self contained. One implementation obstacle which makes it hard is the data uri resource does not have a URL so it is difficult to relate an external URL inside the data uri to the document which includes the data uri image itself.

[Said Abou-Hallawa]

Created attachment 258117 [details]
Patch

[Philip Rogers]

Allowing subresource requests from images (even the same domain) can have bad security implications. What do you think about an approach like CSP for this? The idea would be to have the server opt-in to allowing subresource requests from images.

[Build Bot]

Comment on attachment 258117 [details]
Patch

Attachment 258117 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/12708

New failing tests:
http/tests/security/svg-image-with-css-cross-domain.html
http/tests/security/svg-image-with-cached-remote-image.html

[Build Bot]

Created attachment 258123 [details]
Archive of layout-test-results from ews100 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Simon Fraser (smfr)]

(In reply to comment #2)
> Allowing subresource requests from images (even the same domain) can have
> bad security implications. What do you think about an approach like CSP for
> this? The idea would be to have the server opt-in to allowing subresource
> requests from images.

Can you elaborate on the security implications of loading same-origin resources for SVG images?

[Build Bot]

Comment on attachment 258117 [details]
Patch

Attachment 258117 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/12738

New failing tests:
http/tests/security/svg-image-with-css-cross-domain.html
http/tests/security/svg-image-with-cached-remote-image.html

[Build Bot]

Created attachment 258127 [details]
Archive of layout-test-results from ews107 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[Said Abou-Hallawa]

Created attachment 258135 [details]
Patch

[Philip Rogers]

(In reply to comment #5)
> (In reply to comment #2)
> > Allowing subresource requests from images (even the same domain) can have
> > bad security implications. What do you think about an approach like CSP for
> > this? The idea would be to have the server opt-in to allowing subresource
> > requests from images.
> 
> Can you elaborate on the security implications of loading same-origin
> resources for SVG images?

The attack vector I've seen in the wild is to use SVG images as tracking devices. We saw this on gmail.com where email with embedded SVG images would ping an external server and act as a read receipt for spammers. While external servers aren't a problem for same-origin requests, these subrequests can still leak data to an attacker through same-origin tracking (e.g., counter gifs) and open redirects (e.g., myorigin.com/leakyphp.php?img=badserver.com/readreceipt.gif). I don't think sites that accept user-uploaded svg images are hardened against this type of attack which is why opt-in might be a nice middle ground.

[Said Abou-Hallawa]

(In reply to comment #9)
> (In reply to comment #5)
> > (In reply to comment #2)
> > > Allowing subresource requests from images (even the same domain) can have
> > > bad security implications. What do you think about an approach like CSP for
> > > this? The idea would be to have the server opt-in to allowing subresource
> > > requests from images.
> > 
> > Can you elaborate on the security implications of loading same-origin
> > resources for SVG images?
> 
> The attack vector I've seen in the wild is to use SVG images as tracking
> devices. We saw this on gmail.com where email with embedded SVG images would
> ping an external server and act as a read receipt for spammers. While
> external servers aren't a problem for same-origin requests, these
> subrequests can still leak data to an attacker through same-origin tracking
> (e.g., counter gifs) and open redirects (e.g.,
> myorigin.com/leakyphp.php?img=badserver.com/readreceipt.gif). I don't think
> sites that accept user-uploaded svg images are hardened against this type of
> attack which is why opt-in might be a nice middle ground.

Is this kind of attack specific to loading resources from non-interactive SVG? What makes these kinds of requests are allowed for interactive SVG but not allowed for non-interactive SVG?

[Philip Rogers]

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #5)
> > > (In reply to comment #2)
> > > > Allowing subresource requests from images (even the same domain) can have
> > > > bad security implications. What do you think about an approach like CSP for
> > > > this? The idea would be to have the server opt-in to allowing subresource
> > > > requests from images.
> > > 
> > > Can you elaborate on the security implications of loading same-origin
> > > resources for SVG images?
> > 
> > The attack vector I've seen in the wild is to use SVG images as tracking
> > devices. We saw this on gmail.com where email with embedded SVG images would
> > ping an external server and act as a read receipt for spammers. While
> > external servers aren't a problem for same-origin requests, these
> > subrequests can still leak data to an attacker through same-origin tracking
> > (e.g., counter gifs) and open redirects (e.g.,
> > myorigin.com/leakyphp.php?img=badserver.com/readreceipt.gif). I don't think
> > sites that accept user-uploaded svg images are hardened against this type of
> > attack which is why opt-in might be a nice middle ground.
> 
> Is this kind of attack specific to loading resources from non-interactive
> SVG? What makes these kinds of requests are allowed for interactive SVG but
> not allowed for non-interactive SVG?

Does "interactive" here refer to "dynamic interactive mode" from https://svgwg.org/specs/integration? If so, the basic issue is just author expectations. Sites that allow user-uploaded interactive content (svg, html, etc) have an expectation of needing to deal with scripting attacks. Authors seem to be more liberal with user-uploaded images but may not understand the security implications (e.g., the gmail team).

Are you sure IE supports this? I tested this in both IE and Edge and they seem to block subresource requests from SVG images loaded via <img src="...">.

I don't mean to be a stick in the mud though... this area is very confusing for authors and I'd like to give them a better answer than data:uri.

[Said Abou-Hallawa]

Created attachment 258178 [details]
test case

[Said Abou-Hallawa]

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (In reply to comment #5)
> > > > (In reply to comment #2)
> > > > > Allowing subresource requests from images (even the same domain) can have
> > > > > bad security implications. What do you think about an approach like CSP for
> > > > > this? The idea would be to have the server opt-in to allowing subresource
> > > > > requests from images.
> > > > 
> > > > Can you elaborate on the security implications of loading same-origin
> > > > resources for SVG images?
> > > 
> > > The attack vector I've seen in the wild is to use SVG images as tracking
> > > devices. We saw this on gmail.com where email with embedded SVG images would
> > > ping an external server and act as a read receipt for spammers. While
> > > external servers aren't a problem for same-origin requests, these
> > > subrequests can still leak data to an attacker through same-origin tracking
> > > (e.g., counter gifs) and open redirects (e.g.,
> > > myorigin.com/leakyphp.php?img=badserver.com/readreceipt.gif). I don't think
> > > sites that accept user-uploaded svg images are hardened against this type of
> > > attack which is why opt-in might be a nice middle ground.
> > 
> > Is this kind of attack specific to loading resources from non-interactive
> > SVG? What makes these kinds of requests are allowed for interactive SVG but
> > not allowed for non-interactive SVG?
> 
> Does "interactive" here refer to "dynamic interactive mode" from
> https://svgwg.org/specs/integration? If so, the basic issue is just author
> expectations. Sites that allow user-uploaded interactive content (svg, html,
> etc) have an expectation of needing to deal with scripting attacks. Authors
> seem to be more liberal with user-uploaded images but may not understand the
> security implications (e.g., the gmail team).
> 

My understanding about this terminology is the following. A standalone SVG is called an interactive SVG. The SVG is the top level document since it is loaded directly in the browser and hence executing the script is allowed in this case and this is why it is called "interactive". If the SVG is loaded from an <object> or <iframe> tag it is still interactive since it's loaded in its separate document.

An SVG loaded from an <img> tag is called non-interactive. No script is allowed to run in this case.

> Are you sure IE supports this? I tested this in both IE and Edge and they
> seem to block subresource requests from SVG images loaded via <img
> src="...">.
> 

I attached a test case which shows all green rectangles in IE 11 and WebKit with the attached patch. It does not show green rectangles in Chrome and FireFox. If you tried the test case of the attached patch it won't work in IE since IE does not support SVG fragments. And this test case uses the SVG fragments with all the images it references.

> I don't mean to be a stick in the mud though... this area is very confusing
> for authors and I'd like to give them a better answer than data:uri.

I agree.

[Philip Rogers]

(In reply to comment #13)
> (In reply to comment #11)
> > Are you sure IE supports this? I tested this in both IE and Edge and they
> > seem to block subresource requests from SVG images loaded via <img
> > src="...">.
> > 
> 
> I attached a test case which shows all green rectangles in IE 11 and WebKit
> with the attached patch. It does not show green rectangles in Chrome and
> FireFox. If you tried the test case of the attached patch it won't work in
> IE since IE does not support SVG fragments. And this test case uses the SVG
> fragments with all the images it references.

Can you double-check this again? In both IE11 and Chrome on Windows I see the same results on your testcase where svg subresources are not loaded. I don't have Edge here at work but I can test this when I get home. Are you loading your testcase from a server or the local filesystem?

[Said Abou-Hallawa]

Created attachment 258243 [details]
IE screenshot

This is how IE 11 shows the attached test case. The window in the top loads the test case from a web-server while the window in the bottom loads the page from the file-system.

[Said Abou-Hallawa]

(In reply to comment #14)
> Can you double-check this again? In both IE11 and Chrome on Windows I see
> the same results on your testcase where svg subresources are not loaded. I
> don't have Edge here at work but I can test this when I get home. Are you
> loading your testcase from a server or the local filesystem?

A screen-shot is attached. It shows how IE 11 shows the test case when it is loaded from a web server and from the file system.

[Said Abou-Hallawa]

Created attachment 258249 [details]
Chrome screenshot

This is a screen shot from Chrome "Version 44.0.2403.130 m" displaying the same test case from local file system and from web server.

[Philip Rogers]

(In reply to comment #15)
> Created attachment 258243 [details]
> IE screenshot
> 
> This is how IE 11 shows the attached test case. The window in the top loads
> the test case from a web-server while the window in the bottom loads the
> page from the file-system.

Very odd!

Can you try hitting your testcase off my webserver?
http://pr.gg/svg-images-with-linked-images.html

I tested Edge 20.10240.16384.0 (default settings) and IE 11.0.10240.16384 and both had the same behavior of not loading SVG image subresources (screenshot: pr.gg/svgimageswithlinkedimages.png). I also tested this on a colleague's windows box as well as Microsoft's RemoteIE service with the same behavior.

[Said Abou-Hallawa]

Created attachment 258276 [details]
win7-win8-screen-shot

This screenshot shows how IE 11.0.9600.17691 on win7 and 11.0.9600.17905 on win8 render the test case. I think the difference is related to the IE version not the windows version. It looks like IE assumed it is a bug and they fixed it between these two versions.

[Said Abou-Hallawa]

(In reply to comment #18)
> (In reply to comment #15)
> > Created attachment 258243 [details]
> > IE screenshot
> > 
> > This is how IE 11 shows the attached test case. The window in the top loads
> > the test case from a web-server while the window in the bottom loads the
> > page from the file-system.
> 
> Very odd!
> 
> Can you try hitting your testcase off my webserver?
> http://pr.gg/svg-images-with-linked-images.html
> 
> I tested Edge 20.10240.16384.0 (default settings) and IE 11.0.10240.16384
> and both had the same behavior of not loading SVG image subresources
> (screenshot: pr.gg/svgimageswithlinkedimages.png). I also tested this on a
> colleague's windows box as well as Microsoft's RemoteIE service with the
> same behavior.

I think you are right. I attached a screenshot for Chrome, FireFox and IE 11.0.9600.17691 on Windows7. The test case shows all green on this version of IE. The screenshot shows also IE 11.0.9600.17905 on Windows 8. The test case is rendered consistently with other browsers. I think IE considered this behavior a bug and they fixed it between IE 11.0.9600.17691 and IE 11.0.9600.17905. And since you tried it on IE 11.0.10240.16384 which is even newer, you saw the red rectangles.

Sorry for the confusion.

[Said Abou-Hallawa]

The issue will be discussed in the next w3 csswg meeting: https://wiki.csswg.org/planning/paris-2015

[Simon Fraser (smfr)]

Said, the spec does describe the various modes, and whether they allow external resources. I think SVG images are considered "Secure animated mode":

https://svgwg.org/specs/integration/#secure-animated-mode

[Said Abou-Hallawa]

I read https://svgwg.org/specs/integration/ and this is my understanding about the referencing and the processing modes:

if (SVG document is a top-level document) {
    referencing_mode = "top-level document referencing mode";
    processing_mode = "dynamic interactive processing mode";
} else if SVG document is an embedded document) {
    referencing_mode = "embedded document referencing mode";
    processing_mode = "dynamic interactive processing mode";    
} else if ((SVG document is referenced by the SVG ‘image’) || (SVG document is referenced the HTML 'img')) {
    if (animation can run) {
        referencing_mode = "animated image document referencing mode";
        processing_mode = "secure animated processing mode";
    } else {
        referencing_mode = "static image document referencing mode";
        processing_mode = "secure static processing mode";
    }
} else if (SVG document is loaded as a resource) {
    referencing_mode = "resource document referencing mode";
    processing_mode = "secure animated processing mode";
} else if (SVG document is a font document) {
    referencing_mode = "font document referencing mode";
    processing_mode = "secure animated processing mode";
}

So according to the pseudo code above, the processing mode of an SVG document when it is referenced by an SVG 'image' is either "secure animated processing mode" or "secure static processing mode" based on whether the animation can run or not. I was not sure what disabling the animation mean in this context.

The "secure static processing mode" allows external references. This mode is what I am talking about and I think many users will need it. Imagine a company of many static (non animating) images and they want to display them with a copyright, draft or logo images. If these images are SVG documents and they reference external SVG documents that will be a clean solution.

[Said Abou-Hallawa]

Reading https://svgwg.org/specs/integration/, I am not sure why the SVG document, when loaded as resource or font, is processed in "secure animated processing mode. Should not it be processed in "secure static processing mode"? Why the "declarative animation" is allowed for a 'mask' or a 'clip-path' while external references is disallowed?

[Simon Fraser (smfr)]

(In reply to comment #23)
> The "secure static processing mode" allows external references.

Not according to https://svgwg.org/specs/integration/#secure-static-mode.

[Simon Fraser (smfr)]

After brief discussion at the FX meeting, other vendors agree that this would be a good idea. Mozilla folks are going to try to figure out why they disabled it.

We agree that there are times when we would want to continue to disallow external resources (SVG in cursor, and in a data URI).

[Simon Fraser (smfr)]

Some more info in https://bugzilla.mozilla.org/show_bug.cgi?id=628747

[Philip Rogers]

(In reply to comment #26)
> After brief discussion at the FX meeting, other vendors agree that this
> would be a good idea. Mozilla folks are going to try to figure out why they
> disabled it.
> 
> We agree that there are times when we would want to continue to disallow
> external resources (SVG in cursor, and in a data URI).

Hey Simon, are there links to the minutes? I'd like to find out more.

[Said Abou-Hallawa]

(In reply to comment #25)
> (In reply to comment #23)
> > The "secure static processing mode" allows external references.
> 
> Not according to https://svgwg.org/specs/integration/#secure-static-mode.

Sorry I meant "static mode" which is currently not used by any referencing_mode.

[Said Abou-Hallawa]

(In reply to comment #26)
> After brief discussion at the FX meeting, other vendors agree that this
> would be a good idea. Mozilla folks are going to try to figure out why they
> disabled it.
> 
> We agree that there are times when we would want to continue to disallow
> external resources (SVG in cursor, and in a data URI).

I agree the data URI image should not have any external reference. It can only reference data URI resources.

[Simon Fraser (smfr)]

(In reply to comment #28)
> (In reply to comment #26)
> > After brief discussion at the FX meeting, other vendors agree that this
> > would be a good idea. Mozilla folks are going to try to figure out why they
> > disabled it.
> > 
> > We agree that there are times when we would want to continue to disallow
> > external resources (SVG in cursor, and in a data URI).
> 
> Hey Simon, are there links to the minutes? I'd like to find out more.

http://logs.csswg.org/irc.w3.org/css/2015-08-27/#e584792

There wasn't really any new info. I think the info in https://bugzilla.mozilla.org/show_bug.cgi?id=628747 is most relevant. The redirect issue is probably the most important.

[Simon Fraser (smfr)]

Another relevant thread here:
http://lists.w3.org/Archives/Public/www-style/2015Sep/0116.html

[Brady Eidson]

Comment on attachment 258135 [details]
Patch

This patch has been pending review since 2015 with no recent activity.
It seems unlikely that it would even still apply to trunk in its current form.

Clearing from the review queue.

Feel free to update and resubmit if the patch is still relevant.