Re: img issue: should we restrict the URI

On Jan 25, 2008 12:43 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Fri, 25 Jan 2008 19:22:13 +0100, Jeff Schiller <codedread@gmail.com>
> wrote:
> > Great - this behavior is exactly what I'd like to get defined in the
> > spec for <img> so that it is non-ambiguous what an "image" is and how
> > it behaves.
>
> To be honest, given that this impacts several CSS features, <svg:image>
> probably, and maybe other specifications as well defining it in HTML 5
> seems like a bit of stretch. Makes more sense as part of the SVG
> specification in my opinion.
>

In my opinion, I really think that these things should be considered
within the context of the HTML WG since we are trying to define the
expected behavior of the UA when encountering the html:img element
(not the UA behavior when it encounters the svg:image element, which
does not impose all these restrictions).  Isn't it within HTML's
jurisdication as "host language" in this scenario to impose certain
restrictions?

Leaving it out of the specification seems like it would hinder
inter-operable HTML5 implementations - and that seems like a bad idea
to me...

Given all the potentials that Boris metions, and the availability of
the <object> tag for anything requiring some level of scripting and/or
interaction - I would like to propose that, quite simply, the included
image is script-neutered.

This means any <script> tags and any event listeners/attributes are
ignored within SVG when it's included via HTML's <img> (though
declarative animations could still be allowed).

Another question:  If the SVG file links to another external resource
(for example, another SVG file), is this allowed when SVG is included
via HTML's <img>?  What about external CSS, rasters?   What about
foreignObject?  What does Opera do today?  Allow external references
but script-neuter those external SVGs too?  Sorry for all the
questions on this - yes, I should test this myself, just curious if
any experts know already...

As the list of potential gaps in my head grows here, I don't think we
can generate a comprehensive list that will cover all potential attack
surfaces (and all future possible image formats) - so I'm hoping we
can just come up with some blanket requirements that casts the net
wide.  Something like:

"The linked-to image must not be allowed to execute any logic defined
within the image resource or any of its own linked-to external
resources."

Regards,
Jeff

On Jan 27, 2008 4:44 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> liorean wrote:
> > and expose no way of getting from the content to the embedding document
>
> Or to the browser UI.
>
> This is actually not so easy, possibly.  It's certainly very failure-prone.  If
> it's possible to specify and implement this sanely, it might be OK to allow
> script in the <img>.  Things that would need to be specified, as a minimum:
>
> 1) Does the embedded content have a Window object?  If so:
>   1a) window.parent: what is it?
>   1b) window.print()
>   1c) window.open(): should it work?
>   1d) window.location: should the embedded content be able to set it?
> 2) How are targeted form submits expected to happen?
> 3) Should form submits be allowed at all?
> 4) Should XMLHttpRequest be allowed?
>
> etc, etc.
>
> For what it's worth, I think the answers to all of the above should be some
> variant of "no" or "the operation shouldn't be allowed".  That's a lot of
> special-casing to happen for SVG in <img>.
>
> > Only if the execution of those scripts depends on the embedding
> > website. Couldn't img elements simply run the script in a fully
> > isolated environment?
>
> If one came up with said hypothetical fully isolated environment, yes.  I
> suspect it would be pretty difficult to author scripts for, but I might be wrng.
>
> -Boris
>
>

Received on Monday, 28 January 2008 05:11:05 UTC