evalInSandbox
John J Barton
unconvinced so he has asked me to explain my skepticism. Or so I
understand ;-).
Back at Firebug 1.2 we realized that Firebug 1.1 used eval() to
implement the Firebug console and command line. That was insecure, as
the eval call ran with extension privileges but functions from the web
page can get run during the eval() process.
To fix it we started with evalInSandbox. I did not understand what it
does then and I don't now. With help from some mozilla people we tried
various things but really it was voodoo. We got some aspects of the
console and command line to work but each round uncovered another case
that failed. Eventually I implemented an elaborate mechanism to pass
strings via event handlers instead.
All that background is to claim that I really did try evalInSandbox. A
few efforts since the just confirmed my assessment.
Let me try to pick apart the intro on
https://developer.mozilla.org/En/Components.utils.evalInSandbox
----
In certain circumstances, you may want to evaluate JavaScript code
with restricted privileges.
----
Already I am lost because I don't understand the concept here. This is
not the problem I want to solve. I want to evaluate Javascript code in
another scope, another DOM window, in a way that is safe. Restricted
privileges is necessary but not sufficient.
----
In Firefox 1.5 (Gecko 1.8) or later, an API exists to allow you to do
this. It contains the notion of a "sandbox" that you can create and
evaluate code in its context.
----
But I don't care about the sandbox context, so I don't understand why I
care about evalInSandbox.
----
Code evaluated using this method will always execute with restricted
privileges, as on a normal web page.
----
Well except of course the sandbox is not a normal web page.
A bit further down is the part that causes the voodoo to begin:
----
The sandbox is just an empty JavaScript object marked as being created
by the restricted privilege principal. It will become the global scope
object when you pass it to evalInSandbox(text, sandbox). You may want
to add objects to this scope.
----
So the game we played was to "add objects to this scope" from the web
page and hope we got the right ones. But we never did.
Ok if I can anticipate Boris a bit, the answer could be: evalInSandbox
is for other eval() problems, not this one. That may be true but every
time I need eval() its because I have source I want to run in a scope.
If I can't figure out how to get the right scope, then I can't succeed.
Maybe there is some simple answer we missed and we can just fix the MDC
page.
jjb
Boris Zbarsky
> Already I am lost because I don't understand the concept here. This is
> not the problem I want to solve. I want to evaluate Javascript code in
> another scope, another DOM window, in a way that is safe.
Then neither eval nor evalInSandbox really do what you want, right?
> So the game we played was to "add objects to this scope" from the web
> page and hope we got the right ones. But we never did.
Did you try setting the prototype of the sandbox to the relevant window?
> Ok if I can anticipate Boris a bit, the answer could be: evalInSandbox
> is for other eval() problems, not this one. That may be true but every
> time I need eval() its because I have source I want to run in a scope.
> If I can't figure out how to get the right scope, then I can't succeed.
Makes sense; if the prototype trick above doesn't work, we should file a
bug to have a way to do what you were trying to do. I agree that
evalInSandbox is really not designed around that use case and using it
for that is a pain even if it works.
-Boris
John J. Barton
> On 11/17/09 9:13 PM, John J Barton wrote:
>> Already I am lost because I don't understand the concept here. This is
>> not the problem I want to solve. I want to evaluate Javascript code in
>> another scope, another DOM window, in a way that is safe.
>
> Then neither eval nor evalInSandbox really do what you want, right?
That is correct. In fact I think this is always correct: they have the
wrong scope and wrong security principal and it's hard to fix them.
>
>> So the game we played was to "add objects to this scope" from the web
>> page and hope we got the right ones. But we never did.
>
> Did you try setting the prototype of the sandbox to the relevant window?
Yes, we did that near the end; I noticed that Greasemonkey uses this. I
regret I did not record the problem in this case.
>
>> Ok if I can anticipate Boris a bit, the answer could be: evalInSandbox
>> is for other eval() problems, not this one. That may be true but every
>> time I need eval() its because I have source I want to run in a scope.
>> If I can't figure out how to get the right scope, then I can't succeed.
>
> Makes sense; if the prototype trick above doesn't work, we should file a
> bug to have a way to do what you were trying to do. I agree that
> evalInSandbox is really not designed around that use case and using it
> for that is a pain even if it works.
Bug 529474 - evalInGlobalScope as a secure alternative to eval
jjb