On Scope And Prototype Security
andrea.giammarchi at gmail.com
Sun Mar 17 12:42:18 PDT 2013
David I do not use, neither have a problem, with the example code but I
have used runtime prototype changes for state-machine like applications.
It is not possible to secure or make a class hidden, it was possible before
the introduction of __proto__ and Object.getPrototypeOf in ES3, now this is
gone, and this was my security concern.
Changing runtime prototype methods can be extremely powerful, just think,
as example, about an object used on the DOM with handleEvent and the
possibility to change behavior, using same DOM methods, through a single
prototype that changes accordingly with the user pointer (muse, pen, touch,
etc ... no need to invalidate all listeners and reassign a new one, just
change behavior though instances prototype)
There are many cases where changing runtime prototype, mutating, dropping,
whatever, can be used and it would be cool to secure nobody can retrieve it
outside the private scope.
Again, it was possible, now it's not possible anymore.
On Sun, Mar 17, 2013 at 10:37 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 17/03/2013 18:09, Andrea Giammarchi a écrit :
> My concern is about being unable to let "anyone" retrieve that property,
>> for introspection or to pollute it or change it being able to make my
>> private constructor insecure.
>> In the example there but in other situation I cannot freeze the prototype
>> and yet I cannot hide it from outside in a meaningful way.
> I see. I understand better why you change Private.prototype.init in the
> A solution here would be to have a single function starting with
> "if(domReady)" is which "domReady" is a boolean which value changes at the
> 'DOMContentLoaded' event.
> I won't pretend it's a perfect solution, but it works.
> A sufficiently smart interpreter could notice that the domReady value is
> never set to true after it's moved to false, so could remove the test (but
> I can already hear Andreas Rossberg about my over-optimism of what
> JIT-compilers do in practice :-) )
> AFAICT it looks like "just introspection" for something able to make
>> private classes basically impossible is not a security concern so thanks
>> for your answer, now I know there's no way to have that behavior now,
>> neither tomorrow (so, long story short: good to know)
> I'd like you to express more formally what property you're trying to
> defend. My understanding is the following:
> You have a constructor (and its .prototype property). You want to be able
> to change properties of the .prototype at any point in time, while
> providing instances generated by the constructor to some mixed trusted code.
> Expressed this way, one can notice that giving access to an instance
> implies giving access to the full [[Prototype]] chain (because of
> Object.getPrototypeOf and __proto__ in browsers supporting that), so anyone
> with access to an instance has access to the objects that are kept mutable,
> making the problem unsolvable.
> In my opinion, the issue is not in allowing access to [[Prototype]] but in
> expecting everything to be always mutable.
> Other than the "if(boolean)" solution above, a different solution could
> involve mixins.
> A different (but admittedly complex and too heavy for the problem at hand)
> solution could involve putting a proxy as .prototype. This proxy doesn't
> allow mutation (throw on set trap or whatever), but whoever has access to
> the underlying target (which can be kept private) can still modify it.
> My point is that access to the prototype chain isn't an insecurity in
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss