__proto__

Lars T Hansen lth at acm.org
Tue Sep 11 08:01:04 PDT 2007


__proto__ breaks abstraction boundaries in the language -- it's just
like function.caller, you get to look at and change objects that your
caller may wish to keep secret from you.  Whether it's actually a
security threat depends on the details of the environment: whether
your caller fits those criteria or not, or whether your run-time
environment has objects whose constructors are not exposed to client
code.

--lars

On 9/11/07, Kris Zyp <kriszyp at xucia.com> wrote:
> Is __proto__ somehow a new security threat? __proto__ has been around for
> ages in SM/FF and not only that, but it has been there in the more hazardous
> writable form. I just wanted it be actually included in the spec. Or is
> there some new functionality in ES4 that will somehow interact with
> __proto__ to introduce a security threat?
> Kris
> ----- Original Message -----
> From: "Lars T Hansen" <lth at acm.org>
> To: "Kris Zyp" <kriszyp at xucia.com>
> Cc: "Brendan Eich" <brendan at mozilla.org>; "liorean" <liorean at gmail.com>;
> <es4-discuss at mozilla.org>
> Sent: Tuesday, September 11, 2007 2:34 AM
> Subject: Re: __proto__
>
>
> > On the one hand, __proto__ is another potential security hole, and it
> > prevents implementations from sharing prototype objects among multiple
> > documents -- the link may be read-only but the object isn't.  Function
> > B called from function A with object O may hack O.__proto__ and A can
> > do nothing about it; suddenly all O-like objects in the system act
> > differently.
> >
> > On the other hand, Constructor.prototype is generally available for
> > any Constructor, so it's hard to see what the real damage is -- it's
> > not obviously worse than some other aspects of the language.
> >
> > On the third hand, some implementations may have specialized objects
> > for which no Constructor is available and for whom keeping
> > [[Prototype]] unavailable is desirable.  Similarly, some toolkits may
> > have private prototype objects that are not available to client code
> > because the constructor is hidden in a lexical scope (ES3) or
> > package/namespace (ES4).
> >
> > Introspection is great, but it assumes a lot about how trust works in
> > the environment.
> >
> > --lars
> >
> >
> > On 9/11/07, Kris Zyp <kriszyp at xucia.com> wrote:
> >> > The alternative above would standardize read-only __proto__, which
> >> > would
> >> > make that property no longer implementation-specific. But of  course we
> >> > have no proposal to do that.
> >> I realize this wasn't really the main subject... but could the __proto__
> >> property be defined in the spec (as readonly)? I would love to see that
> >> property standardized.
> >> Kris
> >>
> >> _______________________________________________
> >> Es4-discuss mailing list
> >> Es4-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es4-discuss
> >>
>
>


More information about the Es4-discuss mailing list