[whatwg] Javascript: URLs as element attributes

Boris Zbarsky bzbarsky at MIT.EDU
Wed Aug 11 12:07:32 PDT 2010

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


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


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.


More information about the whatwg mailing list