W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: img issue: should we restrict the URI

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 29 Jan 2008 09:39:56 -0600
Message-ID: <479F48CC.1060006@mit.edu>
To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, "public-html@w3.org" <public-html@w3.org>

Dr. Olaf Hoffmann wrote:
> If the authors are different and the author of the embedding document
> does not like the behaviour of the SVG document

You're assuming the author of the embedding document has any idea what's inside 
the SVG.

Say the embedding document is MySpace.  The author of the embedding document is 
MySpace.  The image is inserted by a MySpace user.  The author of the SVG might 
be that user or someone else.  All MySpace wants to do is not allow that SVG to 
steal cookies.

> In all cases the behaviour
> of the embedded document should not depend on the embedding
> document.

That's just not true.  For example, the following script:

   <script>
     alert(window.parent.document.documentElement.innerHTML);
   </script>

behaves differently depending on the embedding document (and in particular on 
whether the two documents are same-origin).  Welcome to security restrictions, 
the topic of this thread!

> If the embedded document tries to manipulate the embedding
> document with scripting is a different problem

Would you really expect the following script:

   <script>
     parent.location = "http://evil.com";
   </script>

To execute when you include an <img>?  Note that for <object> this is allowed.

> In such a special case
> I see no problem if the author of the embedding document can restrict
> the behaviour somehow.

The point is, pretty much _any_ script running inside the <img> can affect the 
embedding document (see my list in a previous post).  Trying to close up all the 
holes is complicated, and failure-prone.  The correct solution is to disable 
script altogether.

> I know a lot of nasty, quite common things, but the quantity of
> nasty things is in general no reason, not to do it better ;o)

I seem to recall something about a "Don't break the web" design principle?

>> The security issue here is that just because a website allows users to post
>> images it might not actually want to allow them to run script.  If images
>> can run script, this becomes a problem.
> 
> Obviously such a problem already existed before HTML was invented

Sure.  But what does that have to do with the situation we're discussing? 
Because PostScript can have security holes HTML should too?  Sorry, I don't buy it.

> I personally do not need scripting in images, but this is my personal
> opinion only, other authors may find a way to use it to increase the
> pleasure for the audience or to create alternative displays of the image
> to improve accessibility of the content.

I'm not saying active content is inherently bad.  I'm saying that when the 
expectation is that content is passive, making it active generally leads to 
security holes.

Or viewed another way, all the UAs who're implementing SVG in <img> are 
disabling scripting.  Have you stopped to wonder why?  If the spec doesn't allow 
this, can it become a REC?

> I never tried, because from my point of view the construction of img in
> HTML4 is outdated

Then why exactly do you care what behavior is specified for <img>, exactly?  You 
keep using <object>, and live with the security issues.

-Boris
Received on Tuesday, 29 January 2008 15:39:36 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC