Object.prototype.* writable?

Kyle Simpson getify at gmail.com
Sat May 7 17:05:31 PDT 2011


>> My first reaction to this assertion is to say: "so?" It's a rather moot 
>> argument to suggest that code which can be altered before it's run isn't 
>> trustable... of course it isn't. [...] because any malicious script (if 
>> it's first on the page) can completely hijack another part of the page? 
>> Yup, I agree.
>
> That was my point. Since you agree, I don't understand your point:

My point was that your argument was deflecting from the premise of the 
original request in a way that makes the conversation impossible to proceed. 
If you re-define the premise/assumptions to an unreasonable level, you make 
logical reasoning impossible. For instance, arguing that a virus could 
infect the JS engine of the browser is a *possible* scenario, but not a 
useful one to discuss in this context, because it fundamentally violates the 
premise. Similarly, arguing that a network router could be hacked to change 
code in-transit is conceivable, but moot and pointless to the spirit of my 
question.

The premise of the question is, whatever the state of the code on the page 
is (or how it got there), is there a way to prevent some piece of code from 
intentionally or unintentionally altering some important behaviors of native 
objects such that subsequent code could be tricked or tripped up? 
Furthermore, the spirit of the question was, granted there is no 100% system 
for that, but can we move the ball a little closer to the goal line with a 
very narrow idea of restricting a few things, in opt-in modes of JavaScript?


> What protections do you have in mind?

Specifically, I think:
1. All changes to Object.prototype.* should be ignored/error'd, such that 
the predefined members of Object.prototype.* (the native built-ins) are 
immutable. This would not necessarily prevent extensions to 
Object.prototype, simply prevent redefinitions of existing native 
functionality.

2. OR; Let Object.prototype.* members continue to be mutable, but let those 
effects ONLY affect user objects, and not built-in native objects (like 
String, Array, etc). However, a few of Object.prototype.*'s members should 
still be considered for immutability, like for instance `toString()`, which 
is commonly used in the scenario of borrowing its functionality via 
`.apply()`, as described earlier with `window.opera`.

3. OR; There are other more exotic ideas I could advance, such as keeping 
Object.prototype.* mutable, but then exposing an additional interface like 
Object.__prototype__ (which is the original prototype, and is immutable).


> And how, were your protections to be adopted

I was specifically suggesting they be part of one of the future opt-in 
modes, either for Harmony/Next, or more appropriately even, perhaps a future 
"strict mode"... or even call it "safe mode". `"use safe";` has a nice ring 
to it.


> would all bets no longer be off when loading a virtuous library into a 
> frame in which malicious code had already run first?

in the narrow context of what I'm suggesting, the protections afforded by 
the JavaScript engine would limit the ability of prior-malicious (or stupid) 
code from influencing some of the natives which my code might need to rely 
on.


>> As for accident, it depends how dumb that earlier piece of code was. If 
>> it modifies primordial methods so that they no longer satisfy their 
>> contracts in way that later code is ignorant of and unprepared for

Not all modifications are easily feature-testable such that later code would 
have any hope of preventing its own ignorance.


>> OTOH, if these earlier dumb scripts are not that dumb, then the later 
>> smart library should still be able to succeed.

To me, the notion of a "smart library" (even for the purposes of safety) is 
rather absurd. A fundamental assumption here is that there are in fact a 
certain subset of things which no JavaScript code should be allowed to do, 
so as to "play nicely" with other code. Extending Object.prototype has 
almost universally been taken as one such thing. Circumventing 
`location.href` inspection would be another good candidate.

We can't then say "well, we'll make an exception for this one smart library, 
and let him much with that stuff"... because then the "smart library" 
becomes the single-point-of-failure(aka attack).

That's why I approached this narrow question as specifically opt-in 
protections from the engine (non-circumventable), rather than in the 
user-space.


--Kyle



More information about the es-discuss mailing list