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

David Bruant bruant.d at gmail.com
Fri Dec 30 16:00:01 PST 2011


Le 30/12/2011 18:05, John J Barton a écrit :
> On Fri, Dec 30, 2011 at 3:53 AM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Le 30/12/2011 02:28, John J Barton a écrit :
>>     On Thu, Dec 29, 2011 at 5:11 PM, David Bruant <bruant.d at gmail.com
>>     <mailto:bruant.d at gmail.com>> wrote:
>>
>>         Le 30/12/2011 01:00, Lasse Reichstein a écrit :
>>         > On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller
>>         <erights at google.com <mailto:erights at google.com>> wrote:
>>         I've been thinking about this "run first" idea for some time.
>>         Since on a
>>         webpage, security seems to depend on your ability to run code
>>         first, it
>>         would be interesting if there was a way to ensure that some code
>>         (preferably defensive) is run before *any* other code. Though
>>         I find
>>         this interesting, I'm still not sure whether this would be a
>>         good or bad
>>         idea. I'm also clueless on how it would look like.
>>         Creative ideas welcome.
>>
>>
>>     The browser runs first: what can't it do that you want to support?
>     I was thinking of the case of XSS for instance where your code is
>     in competition with unexpected and malicious code.
>
>
> How did this competition begin?
"competition" was an expression :-)

> 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?
Why not for security?
I've recently watched a talk by Marc Stiegler:
http://www.youtube.com/watch?v=vrbmMPlCp3U
In this talk he suggests that we can better cooperate if we have
security in mind since it can lead to safely cooperate even with
untrusted parties. Even among mutually suspicious parties. It's an
interesting idea considering that the usual answer to "I don't trust a
party" often leads to "I won't cooperate with this party at all".
Same Origin Policy is an instance of this. And I heard some people are
frustrated by the fact that one domain is unable to interact with
another domain:
http://louisremi.com/2011/12/06/cors-an-insufficient-solution-for-same-origin-restrictions/


>  
>
>     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?
Loading code from another domain and being victim of DNS spoofing. I
don't have a link right now, but I think that what put WebSockets on
hold for some time was that a researcher showed that he was able to play
with the version of the protocol at the time. With his hack, he was
doing DNS spoofing and basically, when you thought you were loading the
jquery script from Google CDN, you were actually running the attacker code.
That's an untrusted code, which run on your browser.

The protocol and implementations have been fixed accordingly, I think,
but who knows in what other circumstances a malicious script can run on
your page.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111231/62f60c10/attachment.html>


More information about the es-discuss mailing list