Re: Notes on implementing non-local URI references and resource documents

On Tue, Oct 14, 2008 at 8:23 PM, Erik Dahlström <ed@opera.com> wrote:

> On Mon, 13 Oct 2008 18:24:22 +0200, Boris Zbarsky <bzbarsky@mit.edu>
> wrote:
>
> > 4) There is no indication in the specification as to what size should be
> > used for the canvas of the resource documents. Perhaps this never
> > affects rendering and thus doesn't matter; I can't tell for sure that
> > this is the case, especially where foreignObject is involved.  Gecko
> > currently sets the canvas size to 0x0.
>
> Do you while loading and processing the resource document, or when
> rendering the resource document as part of the main document? The svg spec
> should define what viewport to use for the latter case, or in some cases
> there may not be one (e.g for some <use> constructs).


The concern is that there might be corner cases where something depends on
the size of the resource document canvas. Proving that there is no such
dependency is quite difficult.

For example, what about a file foo.svg containing
<svg xmlns="...">
  <defs style="stroke-width:10%;">
    <pattern id="p"><rect width="1" height="1" stroke="yellow"/></pattern>
  </defs>
</svg>
It appears that if another SVG file contains fill="url(foo.svg#p)", the
rendering does depend on the size of foo.svg's initial viewport, which is
undefined.

> 5) To reduce attack surface, Gecko does not execute scripts in resource
> > documents at the present time.  We're not convinced that we want to
> > change this at any point in the foreseeable future.  We do plan to
> > implement non-Turing-complete declarative animation in resource
> documents.
>
> It probably makes sense to apply some form of access control in a future
> spec, similar to what's being done to <iframe> elements in HTML5 with
> @sandbox.


What's the relationship? The question here is simply whether resource
documents should execute scripts they contain, or not. They currently don't
in Opera, IIRC. A lot of issues arise if they were to execute, even given
they are unable to access the primary document.

> 6) To reduce the risk of inadvertent information leakage, Gecko
> > currently does not allow linking to resource documents across origins.
> > The security check performed is the same as that for XMLHttpRequest (so
> > does not take document.domain into account).  We do plan to make this
> > check subject to Access-Control [3] to allow a server to export SVG
> > resource documents for use by other sites.
>
> Is this information leakage any different from someone using e.g <iframe>?
>

Yes. With SVG external references, one document can determine whether
another XML document contains SVG elements with certain IDs and types, and
in some cases by studying geometry (or being even more clever, see my
previous post to this list about recovering pixel values using filters and
pointer-events), it could discover more properties of those elements. None
of this is possible with IFRAMEs (although cross-origin IFRAMEs themselves
are a regrettably large attack surface).

> 7) It's not clear to me from section 5.6 [4] whether event handler
> > attributes on elements in a subtree pointed to by a <use> should be
> > cloned onto the instance tree, but it's certainly what Gecko does right
> > now.
>
> Sort of, but there is one crucial difference:
>
> "If event attributes are assigned to referenced elements, then the actual
> target for the event will be the SVGElementInstance object within the
> "instance tree" corresponding to the given referenced element."
>
> Have SVGElementInstance:s been implemented in gecko?


No, but that doesn't matter here...

> This means that a <use> can effectively import
> > scripts from the referenced document into the primary document scope.
>
> Hmm...do you mean for the case when a <use> references a tree that contains
> a <script>? I don't think scripts are imported to the primary document by
> use, they're executed only in the document context that they're in.


I think what we're worried about here is pulling in event handlers from the
referenced document. Regardless of SVGElementInstance, those event handlers
will still run with full access to the primary document, so this is a way
for a referenced document to attack a primary document.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]