Another de-facto insecurity we need to fix in ES5

Mark S. Miller erights at
Mon Jun 15 19:52:12 PDT 2009

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> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es5-discuss mailing list