Re: [filter-effects][css-masking] Move security model for resources to CSP

On May 30, 2013, at 4:46 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Fri, May 31, 2013 at 2:32 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Daniel Holbert asked me an interesting question yesterday: Do external SVG resources (filter, mask, clip-path) behave like stylesheets? And I think they do. With all the restriction in place that you suggested earlier (no secondary resource load of the external SVG resource), is there a strong need to handle SVG resources differently than CSS stylesheets? As far as I know CSS stylesheets do not follow strict cross origin restrictions. Why would SVG resources need to do it?

Just to summarize:

The idea is to have the same fetch rules for SVG-images and external SVG resources (limited to the elements pattern, linearGradient, radialGradient, mask, filter, clipPath and color) on the CSS url() function. 

The external SVG document (image or resource) will be restricted to:
- Not load any further resources (no images, external stylesheets, scripts or further external SVG resources).
- No references to any other document, not even the original document fetching the current document.
- No execution of JavaScript code.
- No access to browser history (:visited CSS pseudo class won't trigger)

Still allowed:
- Referencing internal elements if just a fragment is defined: url(#frag). Absolute paths to the current document would be prohibited.
- dataURI
- Styling with inline Styles.
- SVG Animations
- No same-origin restriction!

In question:
- Blob (can it be used if no JS is running?)
- Events. Events are not only used by JS, but also to trigger SVG Animations (<animate begin="anim1.end" ...). Can events be a problem? Should they be disabled? They currently work in Chrome and FF. I don't think that there is a risk.

To realize the integration, an external SVG document would be marked as tainted. Tainted documents will have all the above restrictions. Ideally we can extend this model to SVG in general. The only possible thread could be the <use> element which can reference a subtree with a <foreignObject>. All resource loading restrictions will apply to the content of <foreignObject> as well. The biggest danger of a <foreignObject> is a child <iframe>. With the security model in place, this <iframe> would not be allowed to load any resources as well. Therefore, referencing <foreignObject> should be save as well.

This is a huge limitation to the current model of SVG which has no restrictions at all. My hope is that we can finally have a common model that every SVG viewer can agree on and put it into the SVG spec directly.

Greetings,
Dirk

> 
> You can address individual XML elements of an arbitrary SVG document using SVG resource references. You can't do anything like that with a CSS style sheet. I suppose you can try to load the style sheet and add random stuff to your document to try to figure out what the style rules are, but that seems less interesting.

The author could reference elements from external SVG documents on different domains to check if these elements exist in this particular SVG document. I am not sure if that is really a threat since the author can open the SVG file directly in the browser and look in the WebConsole/Inspector what kind of elements it has.
Other then that I do not see a thread with referencing elements. The style on external CSS stylesheets on the other hand, can be read by JS. Something like that is not possible with SVG resources.

> 
> Maybe you're right, but it requires a lot of careful thought by people with the right mentality before I'd be comfortable allowing cross-origin references. (We've been stuck with cross-origin CSS loads from the beginning, and have had to deal with some ugly fallout from that over the years.)

I am happy to have the security model reviewed by others (as many as possible actually). Please point others to this threat and comment. Do you have any folks in mind?

Greetings,
Dirk

> 
> Rob
> -- 
> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Friday, 31 May 2013 13:48:59 UTC