W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2013

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Sat, 1 Jun 2013 21:20:12 -0700
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <4A2BDD73-E0E3-4713-A4D7-808535D0846C@adobe.com>

On Jun 2, 2013, at 1:03 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

> On 6/1/13 11:54 PM, Dirk Schulze wrote:
>> To focus on clip-path: Do I understand you correctly that there is no difference in the security consideration between my two examples (inline path and <use> reference of path in same document)?
> 
> They both allow exfiltrating the path information.
> 
> Are they both allowed in your proposal?  That's the part I'm trying to 
> understand.
> 
>> If yes. Do you think there is a security breach with the potential recovery of the path data inside of <clipPath>?
> 
> Allowing cross-origin exfiltration of _arbitrary_ path geometry seems 
> like an entirely unacceptable security breach to me.  Your example shows 
> that cross-origin <use> allows such exfiltration.  Therefore, we can't 
> allow cross-origin <use> without putting some sort of mitigations in place.

I think this is the point of confusion here. <use> is not allowed to have cross-origin references in my proposal. But more important is your next paragraph:

> 
> Exfiltration of just path geometry that is explicitly being used as a 
> clipping path by the source being exfiltrated from is somewhat 
> questionable, but it's not obvious to me whether it would contain 
> sensitive data in practice.  I would suggest we should err on the side 
> of assuming it would, since this is the sort of thing that's really hard 
> to close down once you open it up...
> 
> Does that answer your question?  I'm really not quite sure what you're 
> really asking here.

Yes, the previous paragraph did. Basically we need to use CORS on <clipPath> in every case to avoid the (even if extremely unlikely) exfiltrating of path data. I would actually avoid different handling between SVG resources. (clipPath, mask, linearGradient, radialGradient and pattern should be treated the same.)

However, this brings me to my last question: The 'clip-path' shapes (rectangle, circle, ellipse and polygon functions)[1][2]. I think they are very useful, however, they would have the same problem of path exfiltrating. The first three shapes are basically fine. It is hard to encode any data in a circle or rectangle. But polygon might be used for texts (transformed to a polygon) as well. Since stylesheets can be cross-origin, we have the same problem as with the <clipPath> element. I think there are three solutions:

- remove basic shapes as part of clip-path property (I would dislike that.)
- remove just the polygon function (This is actually the most useful one IMO.)
- basic shapes do not have any affect on hit testing. If you want to include hit testing use <clipPath> (with CORS).

What do you think?

Greetings,
Dirk

[1] https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html#the-clip-path
[2] http://www.w3.org/TR/2012/WD-css3-exclusions-20120503/#supported-svg-shapes

> 
> -Boris
Received on Sunday, 2 June 2013 04:20:40 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 June 2013 04:20:41 UTC