a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Mar 8 14:38:27 PST 2013


So the point is that a function dealing with unknown objects can be reached
and invoked and my getter is an excellent example for this kind of "attack"
but again, why ES5 went through the Object.seal/freeze/preventExtension
direction for Objects but just dropped functionalities instead of going
through Function#secure() approach where "use strict" or not, which is easy
to drop via Ajax calls too, together with minifiers, linters, or
transpilers, that function would never carry the .caller and its arguments
won't expose the callee ?

Wouldn't this direction solve in a better way everything and keep giving
developers the ability to use callers for all others non debugger related
tasks?

I would let developers decide, as it is for Object.freeze() approach, and
explain where functions should not be reachable instead of "freezing all
functions by default" under use strict directive.


On Fri, Mar 8, 2013 at 2:28 PM, Kevin Reid <kpreid at google.com> wrote:

> On Fri, Mar 8, 2013 at 2:13 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
>
>> The Error.stack strawman is a great start at making Error.stack's
>> contents machine-readable, but doesn't remotely approach being a
>> solution for use cases previously addressed by Function.caller.
>>
>> I don't really understand the security argument in this case. Being
>> able to identify the particular function at offset N in the stack
>> shouldn't expose any privileged information
>
>
> The problem is exposing the ability to invoke the function. Not
> 'privileged' information, but 'privileged' operations.
>
>
>> If anything, being able to cheaply and reliably walk
>> the stack to - for example - identify your caller would allow you to
>> implement some interesting security patterns in your own code, if for
>> some reason you were trying to do sandboxing and code access security
>> in pure JS. If specified correctly you could make it possible to walk
>> the stack and ensure that the information you're getting isn't being
>> spoofed, which would allow you to reliably limit callers of a given
>> 'protected' function to a fixed whitelist of trusted functions,
>> something you can't do by parsing a dead stack trace.
>>
>
> Java tried stack inspection. It has failed. It has been responsible for
> quite a few vulnerabilities (of the sort which allow Java applets to break
> their sandbox) and does not compose well.
>
>
>> Apologies if I've missed some huge design philosophy underpinning the
>> design of ES6/ES7 re: security/sandboxing; I also don't really
>> know/understand how Caja fits into the picture.
>>
>
> References constitute permissions. To have a reference to a function is to
> be able to invoke it is to have the permission.
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130308/ae9709ec/attachment.html>


More information about the es-discuss mailing list