Es4-discuss Digest, Vol 8, Issue 44

Graydon Hoare graydon at mozilla.com
Tue Oct 30 18:45:23 PDT 2007


Douglas Crockford wrote:

> The proposal is not a more secure language. It does nothing to address ECMAScript's biggest  design flaw: the insecurity caused its dependence on a global object. XSS attacks are a direct consequence of this flaw. By making the language more complex, this problem becomes even harder to reason about and fix.
> 
> I have been bringing this up since my first day in the working group. This is not a concern that is being sprung at the last minute. 

It is true that you brought this up on the first day you came to the 
meetings. I said then, and I say again now, that I think we will 
actually be putting ES4 programmers in a better position wrt. safety 
than ES3 programmers.

I wonder if the following two basic facts about the ES4 environment are 
clear. I've brought them up in the past but you usually dismiss them 
rather than saying why exactly they don't help:

- fixtures in ES4 are early-bindable, non-overridable and (in cases of 
methods, types, classes, and other sorts of constants) non-replaceable. 
Intercepting control from a script that uses fixture names by mutating 
some part of the global object or prototypes is *not possible* in this 
design.

- 'use namespace intrinsic' at the top of an ES3 file, then publishing 
it under the ES4 mime type, should be enough to accomplish this in many 
cases. All the multiname references that would previously hit the 
prototype chains and/or global.foo bindings become fixture references 
that XSS code cannot intercept. Even if they don't early-bind due to the 
absence of type annotations on slots, the multinames wait around until 
runtime and the fixtures *mask* the public names / prototype chains.

Do they not help with some of the XSS scenarios? I imagine that they 
would, but have not nearly the depth of experience with XSS problems.

-Graydon




More information about the Es4-discuss mailing list