[whatwg] Sandboxing scripts in pages

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

Received on Friday, 12 January 2007 16:48:39 UTC