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

On May 31, 2013, at 9:47 AM, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

> On 5/31/13 9:48 AM, Dirk Schulze wrote:
>> - Referencing internal elements if just a fragment is defined: url(#frag). Absolute paths to the current document would be prohibited.
> 
> url(#frag) is canonicalized to an absolute URI at parse time at least in 
> Gecko, and that's the URI model in general.  So this is a somewhat 
> nonsensical requirement, imo.  Also one that doesn't seem to be needed, 
> since the behavior of absolute path to the resource document and 
> relative path to the resource document should be exactly identical.

You may be right. I just wanted to be extra clear.

> 
>> - No same-origin restriction!
> 
> It's not clear to me that this is ok.  <use> across origins sounds like 
> a pretty potent data-exfiltration vector to me.
> 
> Note that for stylesheets this is in fact a serious problem; there have 
> been a number of attacks on this vector with stylesheets in the past, 
> browsers have put into place some mitigations, but there are other 
> attacks remaining.  The only thing saving stylesheets here is that 
> almost no one stores login-required data in CSS.  Is the same true for 
> SVG?  I suspect not...

For <use>, there could indeed be data stored in elements that in theory can be read. This problem might be solveable with the redesign for <use> in the future. Means we would need special treatments for <use> for now :/.

I do not see that is the case for other resources like mask, clip-path, pattern and gradients. Especially not for the CSS url() function.

Greetings
Dirk

> 
>> - Blob (can it be used if no JS is running?)
> 
> No, it can't.
> 
>> - 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.
> 
> I don't think there is a problem with events given lack of scripting.
> 
>> 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.
> 
> -Boris
>

Received on Friday, 31 May 2013 17:23:05 UTC