How to clean up __proto__ (was: Why we need to clean up __proto__)
gazheyes at gmail.com
Fri Dec 30 11:42:49 PST 2011
On 30 December 2011 17:05, John J Barton <johnjbarton at johnjbarton.com>wrote:
> On Fri, Dec 30, 2011 at 3:53 AM, David Bruant <bruant.d at gmail.com> 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:
randomized tokens. Even when the site is vulnerable to type 1 XSS and DOM
based XSS, even within href attributes.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss