W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

[whatwg] Javascript: URLs as element attributes

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 02 Dec 2010 13:20:27 +0100
Message-ID: <op.vm25wdfgsr6mfa@kirk>
On Thu, 02 Dec 2010 11:38:33 +0100, Simon Pieters <simonp at opera.com> wrote:

> On Thu, 02 Dec 2010 09:32:43 +0100, Philip J?genstedt  
> <philipj at opera.com> wrote:
>
>>>> Right, these aren't inlines, in Opera terminology at least. As far as  
>>>> I
>>>> can see the spec agrees on this, as frames/iframes have their own
>>>> browsing contexts.
>>>
>>> So do <object>s, sometimes, right?
>>
>> Yes, but as far as I can tell from the algorithm [1], the browsing  
>> context isn't created until step 8, after the URL in data="" has been  
>> resolved and fetched. In other words, at the time the steps for  
>> handling javascript: [2] are run, there's no browsing context, and it  
>> will be treated as any other inline.
>
> What if the steps are run because the data attribute changed?
>
> <object data=data:,foo></object>
> <script>
> document.getElementsByTagName('object')[0].data = 'javascript:alert(1)';
> </script>

The relevant step would be step 4: "Fetch the resulting absolute URL, from  
the element's browsing context scope origin if it has one."

So, at this point, there would already be a browsing context, I believe.  
If the only reason this is in the spec is so that javascript: URLs will  
execute in the <object> browsing context, then I suggest that this simply  
be changed so that data="javascript:..." never execute, regardless of  
how/when the attribute was set. Unless there are compat constraints here,  
this seems simpler and more predictable, and I would guess that this is  
what most browsers already do.

Some testing may be in order, though.

-- 
Philip J?genstedt
Core Developer
Opera Software
Received on Thursday, 2 December 2010 04:20:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC