a future caller alternative ?

Kevin Reid kpreid at google.com
Mon Mar 11 12:41:11 PDT 2013


On Sat, Mar 9, 2013 at 10:13 AM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> but then again, the list of problems is massive here if it's about
> trustiness.
> Object.prototype can be enriched or some method changed, parseInt and
> parseFloat can be redefined to change payment details and stuff,
> String.prototype.trim can be faked to read all written fields before these
> are sent if the app does the cleanup, Function.prototype.apply/call can be
> redefined too so access to "unknown functions" is granted again
>

Yes, taking care of all those things is necessary as well. ES5 provides us
the tools to do so: Object.freeze(). If you recursively freeze all standard
global objects then all of the issues you mention are handled. Secure
ECMAScript (SES), developed by Mark Miller, does this; it provides an
execution environment which _is_ secure (given a sufficiently conformant
ES5 implementation).


> ... and all we worry about is a caller able to access without changing a
> thing a possibly unknown and private scope that if executed all it could do
> is causing an error?
>

If by “cause an error” you mean throw an exception, that's not all it can
do. Here's a very simplified example, which I have tried to make only
moderately silly; imagine a calculator/spreadsheet web-app with
user-defined functions. In order to make security relevant, imagine that it
(a) has persistent user data (i.e. a script could modify it on the server
by XHR), and (b) allows sharing of prepared calculations with other people.

var input = document.getElementById('input');
var output = document.getElementById('output');
function execute(fun, filter) {
  output.innerHTML = filter(fun(input.value));
}
function basicFilter(value) {
  return (+value).toFixed(4);
}

execute(new Function("x", "return (+x) + 1"), basicFilter);

SES patches the Function constructor so that it cannot access the normal
global scope (e.g. document itself), so the string code here can only
perform computation and use safe constructors (e.g. Object, Array, Date).

However, if the "user-written" function could use .caller, then it could
invoke the caller (which is the execute() function) with an alternate
'filter' which returns arbitrary HTML, at which point it can take over the
page and therefore the user's session as well.

In summary:
• Defending code from other code is not just a theoretical possibility: SES
is a working implementation.
• Not prohibiting .caller is sufficient to defeat this defense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130311/b54ed9a5/attachment.html>


More information about the es-discuss mailing list