[whatwg] Sandboxing scripts in pages

Sat Jan 13 02:28:21 PST 2007

A widget is a small program which lies on top of the main  
application. In the case of widgets a transparent iframe looks a good  
solution to me. Creating a sandbox will be very, very complex.  
Discussions will rise about whether or not the sandbox may render  
anywhere on the canvas, or just on a specified area. Though I am not  
yet convinced of the advantages I am not totally against.  
Intuitively, a sandbox method looks useful to me.
But what to sandbox? If you want to sandbox DOM access, a method  
should be available to create multiple DOM's within the same document  
with restrictions. Anne, does this conflict with the work of the CDF wg?

<body>
   <script type="text/javascript">
     window.onload = function () { ... do something ... }
   </script>
   <div sandbox="true"><!-- any script which is a descendent of this  
element cannot see what is outside the DIV element. this becomes the  
documentElement.
     foo
     <script type="text/javascript">
       window.onload = function () { ... do something... } // how to  
handle this?
     </script>
     <!-- alerts 'div' -->
     <input type="submit" onclick="alert 
(document.documentElement.nodeName);">
   </div>
   <!-- this cannot be reached from inside the sandbox div -->
   <div id="outside">
     bar
   </div>
</body>

This looks inelegant to me.

--jorgen

On Jan 13, 2007, at 1:48 AM, James M Snell wrote:

> Comments on a blog, no. (I'm not sure who brought up that use  
> case). I'm
> thinking more along the lines of widgets embedded into a page. E.g.,
> many users of our internal blogs like to embed widgets from various
> external sites into their templates.  Many of these are embedded using
> <script src="..." />.  Because these scripts run within the context of
> the larger page, a potentially malicious script that has access to the
> complete DOM could silently scrape content from the page and send that
> out to an external server.
>
> Again, I'm not proposing any particular solution.  Nor am I saying  
> there
> aren't already existing solutions to these problems that can work.   
> What
> I'm saying is that having some way of isolating a script would be  
> ideal
> and I was curious as to what others had to say about it.
>
> - James
>
> Jorgen Horstink wrote:
>>
>> On Jan 12, 2007, at 10:30 PM, James M Snell wrote:
>>
>>>
>>> Anne van Kesteren wrote:
>>>> [snip]
>>>>>
>>>>> Frames are a terrible solution. The content is after all a part  
>>>>> of the
>>>>> page it's hosted in, but we want to sandbox it to make sure it  
>>>>> can't
>>>>> do any harm.
>>>>
>>>> The proposed alternative is severely underdefined and won't work  
>>>> for the
>>>> foreseeable future anyway.
>>>> [snip]
>>>
>>> Minor nit:
>>>
>>>   s/proposed alternative/simple strawman to illustrate the point/
>>>
>>> I just want the behavior or something that comes close without
>>> necessarily having to resort to aggressive filtering.  That is, I  
>>> don't
>>> necessarily want to eliminate scripts from the comments, I just  
>>> want to
>>> be able to limit their impact.
>>>
>>> Either way, I'm fully aware that any new invention here would take a
>>> while to actually work.
>>>
>>> - James
>>>
>> Please provide a real use case. I second Anne's point of comment
>> sanitation. Can you give me one single use case when it is useful  
>> to use
>> ECMAScript in a comment on a blog? Secondly, just as Bjoern states; a
>> malicious script could easily position new element on top of other
>> elements. Or do you want to restrict that too? I cannot see what  
>> CSS has
>> to do with it, since it is not a style issue, but a DOM access  
>> behavior
>> issue.
>>
>> -- Jorgen
>>
>>
>