Sandboxed Scripts and Styles on HTML / comments? (idea?)

Hi, I want to know what do you think about adding the capability of browsers
to add a sandboxed script/style.. this is partly implemented on a program
I'm doing but that is far from standard, and I want to see what do you
think.. this was also suggested by daniel when talking about CSS issues.

So the idea is to add sandboxed scripts and styles to HTML in a safe way.

This is useful for SNS and others that want to allow the user to execute
javascript, without endangering their session. As of right now the following
solutions exist:
1.- Open Social (google gadgets)
    -> this is a bad solution, allows attackers to do phishing attacks by
simply using a frame breaker, modify the state of other applications, etc..
2.- Google CAJA
    -> this requires server-side code that does stuff with the JS / or java.
3.- JSReg / ACS
    -> this is a work in progress, more details will be released next week
or so.. this is a good alternative but well..
4.- Facebook Sandbox
    -> has proven to be unsafe, and also requires server interaction.
5.- A microsoft program that requires silverlight (I dont remember it's
name, haha..)
    -> requires silverlight

I think this is better compared to the solution of sandboxing iframes for
the following reasons:

1.- Sandboxed iframes in have either:
    -> Scripting enabled (and comunication between the host application and
guest is made via postMessage)
           not really sandboxed.
    -> Scripting disabled (and users can't really interact like this)
           not useful
2.- Current solutions require the server to parse CSS/JS inorder to judge if
they are safe.
3.- As Mozilla's Add Ons have demonstrated, it IS possible to keep two JS
programs executing with different privileges and interacting with each other
(and the DOM) with an acceptable security. I have made a demo here:
      http://sandbox.sirdarckcat.net/contest1.php

Where I try to demonstrate this protections applied to the web (eg. not only
for addons but also websites).. The only 'dangerous' (dangerous meaning
could have a vulnerability) part of my solution is the "safe" function, that
is supposed to be a Wrapper, but if we use firefox's native wrapper (being
XPCNativeWrapper and XPCSafeJSWrapper) being specifically XPCSafeJSWrapper:

https://developer.mozilla.org/en/XPConnect_wrappers#XPCSafeJSObjectWrapper
> This wrapper was created to address some problems with XPCNativeWrapper.
In particular, some extensions want to be able to safely access
> non-natively-implemented content defined objects (and to access the
underlying JavaScript object under an XPCNativeWrapper without its strong
> behavior guarantees). XPCSJOW act as a buffer between the chrome code.
>*
*> *Note:* Because any type of object can be wrapped here, there is no
predefined behavior. The only guarantee here is that untrusted code will run

> in an untrusted context. In particular, the underlying object might act
entirely differently from what is expected.
>
> Safe JSObject wrappers are implicitly created in some circumstances. All
properties are visible through this wrapper.

We should be able to do this safely... I would like to see if any mozilla
guy can clarify if this is possible, and if you want a partial
implementation you can test the aforementioned demo..

The idea would be the following:

All scripts that have:

<script type="text/sandboxed-javascript"
handler="sandboxedScript1"></script>

and

<style type="text/sandboxed-css" handler="#sandboxedDiv"></style>

will behave in a way that will not affect the page security/privacy,
meaning:

For scripts:
All scripts that run here will belong to a different principal, and all
their return values will be wrapped (something like if the user declares:

  function a(b){return c;}

then the code that will b executed will be:

  function(b){return wrapper(a(wrapper(b)))}

or something like that (probably using arguments[]..)

this function wrapping will protect the "host" code from loosing it's
reference to "this", as well as will be sure that the objects he receive are
safe.. since the code is wrapper, it can't be traversed via
arguments.callee.caller, and the wrapped argument allows the host to be sure
that the unsafe code can't access the host DOM (with a pointer or
something).. and even if they do, there could be security mecanisms that
forbid this code to access host's objects directly (unwrapped/unserialized).

This allows host->guest and guest->host comunication safely (and by safe I
mean, DOM is unreachable evendo DoS attacks may still be possible, unless we
put the code as a "js worker" running in a different thread), without access
to the DOM.. this IS useful since now you can safely add "gadgets" to your
code safely.. etc..

If you saw, there's another argument called handler:
handler="sandboxedScript1"

that means that all global objects will be catched on a object called
"sandboxedScript1", meaning that now a new object called sandboxedScript1
will be the way to access the sandboxed stuff.

For styles:
All position:, properties are disabled, advanced selectors are disabled
(meaning attribute selectors), bindings, javascript URIs, and etcetera (that
can lead to js execution) is disabled..

This will only apply for the element in "handler", for example:

<style type="text/sandboxed-style" handler="#sandboxedDiv">
b{color:blue}
</style>

<b>this is bold</b>
<div id="sandboxedDiv">
user information that can be prettified here.
 <b>this is bold and blue</b>
</div>

will only put blue the "information" part.

So.. that has obvious advantages over the other solutions, and would make
the world a safer place, may even bring peace to the world.. what do you
think?

Greetings!!

-- Eduardo
http://www.sirdarckcat.net/

Sent from Hangzhou, 33, China