- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 01 Jun 2013 23:11:36 -0400
- To: Dirk Schulze <dschulze@adobe.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 6/1/13 6:40 PM, Dirk Schulze wrote: > I do not understand why you distinguish between path inside <clipPath> or outside <clipPath>. Because if you can only get geometry information from paths that are inside <clipPath> in the _target_ document, then you can only exfiltrate paths meant for clipping. But if you can get geometry information from an arbitrary path, then you can exfiltrate things like graphs. > Following example: Right. I assumed we were assuming no cross-origin <use>, since it has all sort of other issues in terms of extracting geometry information. > Both would work in the suggested model. For both you do not have access to the path data when you just reference the resource. <use> would just have limited access to elements within the same document. I'm not sure what you're talking about here, honestly. > Roc said that Firefox has special checking for fragment identifiers before checking IRI. Nope. Firefox converts strings in url() to IRIs at CSS parse time. Then later at dereference time we special-case the situation when the IRI ignoring the fragment identifier matches the document base IRI without fragment identifier and assume that this means you had a bare fragment identifier. > WebKit basically has something similar. Webkit doesn't actually convert the input strings to IRIs until much later in the pipeline, which leads to all sorts of inconsistencies in its handling of URIs, in my experience, depending on which codepath converts to IRI and which just uses the input string and what they do with the input strings. I would be strongly opposed to doing the WebKit thing in Gecko, because it's a very difficult model to not mistakes in, as an engine developer. > The only way to get an approximation of the original path is to inspect the hit region on the clipped element (the element is on your evil domain) with mouseover or elementFromPoint as discussed in the previous mail. If that is not your concern That is my concern, precisely. Once you have some piece of geometry being used as a clip, you can get its geometry information to whatever precision you want using elementFromPoint. Furthermore, you can get color information too, using a combination of filters and pointer-events, as far as I can tell. See http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html -Boris -Boris
Received on Sunday, 2 June 2013 03:12:07 UTC