Jail break by anonymous function call

[tzik]

On the online demo,

  (function(){return this})().postMessage

returns the native one.
I think this is an unintended leak of a dangerous object for the sandbox.

[asvd]

Thanks for the feedback.

What you did is obtained an access to the Worker's internal scope, now you can send messages to the main application. But the accessing the worker scope is not insecure, in fact that is the sandbox provided by the browser and reused by Jailed to protect the main application from being accessed by untrusted code.

The worst thing you can do in this case is closing the worker:

(function(){return this})().close();

or using a method provided by the Jailed library:

(function(){return this})().application.disconnect();

This is not dangerous, a plugin may kill itself if it wants ;-) The application will be notified and may restart a plugin in that case (try the last snippet in the console demo)

Normally an untrusted code running in a plugin created by Jailed library has full access to the worker's scope (particullary it may use postMessage(), but exported functions are designed to be a convenient replacement for that). The reason why I hid those properties in the demo is in that the Console is some kind of virtual environment for a user to evaluate custom JS on the fly. In this sence, the methods available to the worker are not related to the purpose of that application.

PS I have improved the disconnect handling by the console demo, thanks for pointing that out.

PPS Text selection was also re-enabled on the console, disabling it was a stupid idea :-)

[tzik]

I believe Worker is not intended to provide a sandbox...

Are you sure you don't mind the "jailed" script accesses any API in Worker?
Even though it can't directly access to DOM, it can access any other, including IndexedDB, FileSystem, WebSocket and XMLHttpRequest.
And even it may be able to access cookie via CORS XHR + withCredential flag.
I feel it's still dangerous to execute untrusted code in that.

How about replacing that with <iframe sandbox>?
It can have separate security origin to the outer page and your infrastructure seems easy to port to it.

[asvd]

You are probably right, I just had the impression of that a worker is suitable for sandboxing:

http://stackoverflow.com/questions/12209657/how-can-i-sandbox-untrusted-user-submitted-javascript-content

http://stackoverflow.com/questions/12791699/do-web-workers-increase-or-decrease-security

Otherwise I will have to investigate deeper on this (particullary on why iframe sandbox is more secure than a worker).

Please add any links / examples (which may help with clarifying) to this issue.

[asvd]

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Web_Workers

seems to contain some info on this

[asvd]

submitted related question

http://stackoverflow.com/questions/25964015/can-workers-be-secure-enough-for-an-untrusted-code

[asvd]

ok, seems like finally got a solution, will prepare a new release soon

[asvd]

the fix is committed into git, pending for a new release

[asvd]

fixed in v0.2.0

@tzik thanks for the contribution