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