eval in chrome package app

Charles picture Charles · Aug 10, 2012 · Viewed 13.3k times · Source

I would like to create a package app chrome extension to allow the user to write and execute javascript code (like a javascript console).

I would like to use the eval() function to execute the JS code.

The classic javascript eval function throws an error when it's called from a chrome extension:

Uncaught Error: Code generation from strings disallowed for this context

To use eval in a chrome extension people need to use a sandbox, but when I write the sandbox in the manifest I get this error:

There were warnings when trying to install this extension: 'sandbox' is not allowed for specified package type (theme, app, etc.).

UPDATE

According to this issue, sandboxes are not supported for package apps, so I have two questions:

  1. Is there another method which I can use instead of eval()?

  2. Is it possible to use eval without a sandbox? (I think probably not for security reasons?)

Answer

apsillers picture apsillers · Aug 13, 2012

UPDATE:

Since at least January 2013, Chrome now permits the unsafe-eval Content Security Policy (CSP) directive, which allows eval execution outside of a sandbox:

The policy against eval() and its relatives like setTimeout(String), setInterval(String), and new Function(String) can be relaxed by adding 'unsafe-eval' to your policy

Add an appropriate CSP to you extension manifest, like:

"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"

The bug you refer to is now marked fixed, and has been included since Chrome 22.

Prior to the introduction of 'unsafe-eval', there was no way to have the CSP of a manifest_version: 2 extension allow execution of arbitrary text as code. At the time, Google made it clear there was no way to remove this restriction (outside of sandboxing):

Inline JavaScript, as well as dangerous string-to-JavaScript methods like eval, will not be executed... There is no mechanism for relaxing the restriction against executing inline JavaScript. In particular, setting a script policy that includes unsafe-inline will have no effect. This is intentional.

As mentioned above, this restriction can now be relaxed.