I am currently looking into Google Caja to run user-supplied JS code in the browser and in Node.
So far, I understand, that, in a browser context, “cajoled code” disallows reading and messing with the window state by running unsafe code through a full-blown parser that gets rid of all kinds of attack vectors, and then safely executing that code in an iframe of the same origin.
However, I am currently working on a solution using HTML5’s Worker (see here) and it seems to have the same effect. What does Caja have to offer that Worker does not have, other than the ability to customize security policies? Does it have any additional safety features?
5
Whether Caja has a security advantage depends on what your goals are.
These are the main features Caja offers for code sandboxing that all sandboxing methods currently available in browsers do not, as far as I know:
-
Synchronous interaction: you can define APIs which can be called by the guest code and respond immediately — they look like ordinary objects and functions. With workers, since they are explicitly threaded, all interaction must be via postMessage and therefore asynchronous.
Further, if you write your code in the object-capability style it is possible to place both your own application and the user-supplied code within the Caja sandbox and have them interact in arbitrary ways without having to use any heavyweight intermediation at the boundaries between them.
-
Confinement: you can prohibit the guest code from communicating with third-party servers. This means you can execute untrusted code on private data without allowing it to leak that data (it can only return the results of its computation, or display it to the user).
If neither of these is interesting to you, then go ahead and use workers.
(There are additional things you can do with Caja for HTML, e.g. controlling external links, which I have not addressed here because you seem interested in running “headless” JS only.)
2