[whatwg] Javascript: URLs as element attributes

[Cris Neckar]

Re-sending from the correct address.

---------- Forwarded message ----------
From: Boris Zbarsky <bzbarsky at mit.edu>
Date: Wed, Aug 11, 2010 at 12:07 PM
Subject: Re: Javascript: URLs as element attributes
To: Cris Neckar <cdn at google.com>
Cc: whatwg at whatwg.org


On 8/11/10 2:57 PM, Cris Neckar wrote:
>
> 6.1.5
> "So for example a javascript: URL for a src attribute of an img
> element would be evaluated in the context of an empty object as soon
> as the attribute is set; it would then be sniffed to determine the
> image type and decoded as an image."

Right.

> Browsers currently deal with these in a fairly ad-hoc way. I used the
> following to test a few examples in various browsers.

Your test is assuming an "alert" property on the scope chain, and that
the value of the property is a function.  The first assumption would
be false in the situation described in 6.1.5, since an empty object
would have no such property.

> Firefox 3.6.3: Allows object.data, applet.code, and embed.src. Blocks
> all others.
> Firefox 3.7.863: Allows object.data and embed.src. Blocks all others.

Gecko's currently-intended behavior is to do what section 6.1.5
describes in all cases except:

 <iframe src="javascript:">
 <object data="javascript:">
 <embed src="javascript:">
 <applet code="javascript:">

> Has there been discussion on this in the past? If not we should work
> towards defining which of these we want to allow and which we should
> block.

Agreed.

For what it's worth, as I see it there are three possible behaviors
for a javascript: URI (whether in an attribute value or elsewhere):

1)  Don't run the script.
2)  Run the script, but in a sandbox.
3)  Run the script against some Window object (which one?)

Defining which of these happens in which case would be good.  Again,
Gecko's behavior is #2 by default (in all sorts of situations;
basically anywhere you can dereference a URI), with exceptions made to
do #3 in some cases.

-Boris