Nuking misleading properties in `Object.getOwnPropertyDescriptor`
bruant.d at gmail.com
Wed Mar 13 09:08:36 PDT 2013
Le 13/03/2013 16:49, Mark S. Miller a écrit :
> On Wed, Mar 13, 2013 at 8:26 AM, Nathan Wall <nathan.wall at live.com
> <mailto:nathan.wall at live.com>> wrote:
> David Bruant wrote:
> > Tom Van Cutsem wrote:
> > > To my mind, the blame for the breakage lies with
> > > being mutated by the third-party script, not with property
> > > inheriting from Object.prototype. Thus, a fix for the breakage
> > > address that directly, rather than tweaking the design of
> > > descriptors, IMHO.
> > I agree.
> > would be to freeze all built-ins like SES  does. (In the
> > it could even make sense to add a CSP  directive for that)
> > If necessary, the application can first enhance the environment by
> > adding polyfills/libraries and such, but that's pretty much the
> > thing that's acceptable to run before freezing everything.
> Hey David and Tom. This is good advice for application authors,
> but I don't work at the application level; I write libraries. I
> don't want to freeze everything because I want to leave the
> environment open to monkey-patching and shimming by other
> libraries and the application authors. So this isn't an option for me.
> > "what if an attacker switches Array.prototype.push and
> These are issues that are easy to address by using stored
> late-bound function references rather than methods and array-likes
> instead of true arrays.
> var push = Function.prototype.call.bind(Array.prototype.push),
> arrayLike = Object.create(null);
> arrayLike.length = 0;
> push(arrayLike, 'item-1');
> As long as the environment is correct when my script initializes,
> I get all methods I need to use stored inside my library's
> closure. Freezing isn't needed.
> That's correct. I've written a bit of code like that myself. At first,
> for those used to JS or even just conventional oo, the style needed is
> very counter-intuitive and awkward -- it goes against the grain of
> what the language tries to make convenient. But amazingly, it is
> possible, and one even gets used to it after a while.
Would it be easier to teach everyone to freeze their built-ins or to
(re)write their code using this style?
> We need a name for your use case. It is definitely distinct from the
> normal JS library writing practice, which implicitly assumes that the
> primordials haven't been too corrupted but does nothing to detect if
> this is true.
Given what you're describing as normal library writing practice,
teaching everyone to freeze their built-ins sounds like a safer bet in
the path of acceptability and making the web overall safer.
In my opinion, to a large extent, using a library and messing around
with built-ins the library might be using is a recipe for disaster. This
practice shouldn't be encouraged.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss