Re: img issue: should we restrict the URI

On 27/01/2008, 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.

As implied when I said "fully isolated" later on.

> 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:
yes. But as I mentioned, fully isolated. Meaning NO contact with the
browser or embedding page whatsoever.

>   1a) window.parent: what is it?
null, or always throw an access violation exception. Or even just have
all uses of it silently fail.

>   1b) window.print()
lacking the user as a source of events, I don't really think allowing
script to use it would be a good idea

>   1c) window.open(): should it work?
as above

>   1d) window.location: should the embedded content be able to set it?
possibly, not sure whether it makes sense or not to allow that. What
are the security implications of allowing it?


> 2) How are targeted form submits expected to happen?
Inside the contained image user caused events should not occur, those
should only happen on the container document. But see my next answer
about that. Targetted from the container to an img element: it's not a
frame element. Targetting an img from any source - forms, links or
window.open - has never worked before to my knowledge. Is there
anything about allowing SVG to run scripts inside the img element that
necessitates changing that?


> 3) Should form submits be allowed at all?
In the contained image? Well, does submitting a form without having a
possibility of user interactivity have any use cases?


> 4) Should XMLHttpRequest be allowed?
Similar non-scripted functionality is needed for the SVG support
itself, no? Are there any security/privacy implications of allowing
XMLHttpRequest that these other methods of including external
resources would not already force?

> 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>.
Well, it would be not for SVG in img specifically, rather for any
scripted content in any non-interactive embedding element (img, audio,
possibly video?), as well as for including scripted images in other
non-interactive ways, like background images or list bullet images
from CSS.

> > 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.

User events are not passed into the embedded content. Interfaces to
the browser or the container document are disabled. Internal
modification through DOM or otherwise is allowed. I think it could be
specced out.
-- 
David "liorean" Andersson

Received on Tuesday, 29 January 2008 19:23:24 UTC