W3C home > Mailing lists > Public > www-svg@w3.org > October 2012

Cross domain resource (was: Re: Ambiguities in fill:url() / stroke:url() syntax)

From: Dirk Schulze <dschulze@adobe.com>
Date: Fri, 26 Oct 2012 13:20:43 -0700
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: www-svg <www-svg@w3.org>
Message-ID: <DC121E2B-630C-4D4C-9CF1-0E5988527E48@adobe.com>

On Oct 25, 2012, at 12:10 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> Unfortunately that would be a real pain to implement in Gecko, because our code for loading SVG images is separate from our code for loading external resource documents, and we need to know at the start of the load which path to take. Also, we treat the loaded documents differently. We impose a same-origin restriction on external resource document loads but not on SVG image loads. SVG images are not allowed to refer to external resources for security reasons, but external resource documents can. SVG image documents can be shared between different users of the same SVG image (even from different domains), but external resource documents are not. Etc.

After more investigation, cross domain references of resources can indeed be a problem for XSS. For instance this seems not to be disallowed by the spec (Note: A script is running on the mask element when loaded):

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<mask id="mask" onload="console.log('CORS? Of course!')"/>

<rect width="100" height="100" mask="url(http://external.com/mask.svg#mask)"/>

I don't think that SVG handles this case.

After some tests, I could confirm that Firefox does not load resources with a different origin.
Opera just deactivates scripting and event handling on the resource.

Both strategies seem to protect the privacy of the user. However, clip-path (other then the other resources like filters, masks or paint servers) influences the hit testing. I don't know of a scenario that this could be used as an attack pattern. But might be worth to investigate more.

Adam Barth notes that cross referencing could be used to query the fragments on the external resource. Together with JavaScript you could try to search for certain ID's in the external document.

I think Firefox is following the HTML definition for cross origin resources. And in this case I would be in favor to be safe then sorry. Therefore, I suggest we do not allow referencing cross origin resources in general (like FF already does). Filter Effects[1] has this in the spec already and I will add this to CSS Masking[2] as well. I will add an issue that it needs a resolution from the WGs for the moment.


[1] http://www.w3.org/TR/filter-effects/#origin-restrictions
[2] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
Received on Friday, 26 October 2012 20:21:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:37 UTC