How to clean up __proto__ (was: Why we need to clean up __proto__)

gaz Heyes gazheyes at
Fri Dec 30 11:42:49 PST 2011

On 30 December 2011 17:05, John J Barton <johnjbarton at>wrote:

> On Fri, Dec 30, 2011 at 3:53 AM, David Bruant <bruant.d at> wrote:
> How did this competition begin?
> A use case for JS security environment is loading app components
> cross-site. The other site is 'trusted' in that you believe it has code
> helpful to the user. But you want to limit its control, for reliability
> rather than security in the normal sense. Is this what you have in mind?
>> What I've said before applies and even against an XSS attack, you can
>> prevent cookie theft as long as you run first.
>> I can't see a way for the browser to enforce that trusted code run before
>> untrusted code.
> What causes 'untrusted' code to run at all? You must be doing something to
> cause the browser to load code outside of normal methods. That 'cause' is
> running first.
> To put this another way, what ever runs first *is* the trusted code.

I believe me and Mario Heiderich have solved this problem with JSLR:

As long as the javascript is executed first then you can protect the page
from untrusted javascript execution by whitelisting allowed scripts using
randomized tokens. Even when the site is vulnerable to type 1 XSS and DOM
based XSS, even within href attributes.

I have also developed a whitelisted Javascript environment that can
extended by simulating real dom objects making it difficult to discover you
are in a protected environment.

It might be of interest to the people of this list to check out Mario
Heiderich's slides as he discussed how to use ES5 methods to create a safe
js environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list