Another de-facto insecurity we need to fix in ES5

Douglas Crockford douglas at crockford.com
Mon Jun 15 20:12:05 PDT 2009


Mark S. Miller wrote:
> As I just mentioned on the debugging API thread, at the last EcmaScript 
> meeting we agreed
> 
> On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar at google.com 
> <mailto:waldemar at google.com>> wrote:
> 
>     Rather than describing the evil things that implementations do with
>     F.caller, we agreed to just impose a blanket prohibition of code
>     peeking into the environment records or identity of strict functions
>     on the stack.  This way a test suite can ensure that F.caller does
>     nnot reveal strict functions without us having to introduce the evil
>     things into the standard.  I'll write up proposed wording.
> 
> 
> This is an example of a more general principle. The language we're 
> evolving from isn't ES3, it's ES3 as currently practiced. When browser 
> vendors implement ES5, they won't actually implement ES5 as speced. They 
> will implement ES5 as extended to preserve some of the defacto practices 
> they currently support. When these likely future defacto extensions 
> would lose some of the integrity or security gains we're trying to 
> achieve with ES5, then we should find an adjustment to the ES5 spec that 
> does not break these defacto practices for old code but still allows new 
> code to defend itself from attackers using these defacto extensions.
> 
> The ES3 and ES5 specs both specify the implicit [[Prototype]] property 
> as something that is initialized once and then unchanged. All major 
> browsers today but IE alias this to the name "__proto__" (as if that's a 
> named property) and allow it to be mutated. None of the rest of the ES5 
> semantics has been critically examined in light of the possibility that 
> an implementation may allow this mutation. So long as [[Prototype]] is 
> pervasively mutable, then most interesting behavior of an ES5 object 
> won't be stable as well. I recommend:
> 
> Object.freeze(foo) guarantees not only that all of foo's named 
> properties be frozen and that foo is non-extensible, but also that foo's 
> [[Prototype]] will not be changed.
> 
> For non-frozen objects, we continue not to specify that [[Prototype]] 
> can be mutated or explain any means for mutating it. But neither can we 
> prohibit such mutations unless FF, Safari, and Opera are willing to give 
> up this feature. The proposal above won't break any old code that 
> depends on mutating __proto__ but will enable new code to protect 
> itself. I would like to propose something stronger, but don't know of 
> anything stronger compatible with this constraint.

Is this something the market can fix? Browsers with __proto__ will be unsafe for 
mashups. Sites that care about their users' safety will recommend sans __proto__ 
browsers. Parents who care about the safety of their families will install only 
sans __proto__ browsers. The share of the dangerous browsers falls to nothing 
and the safer browsers prevail. Problem solved.


More information about the es-discuss mailing list