Bug 88450 – Can't use eval in iframes sanbdoxed via CSP header

• Component: WebCore JavaScript
• Status: RESOLVED FIXED

[Mihai Parparita]

Test case: http://persistent.info/webkit/test-cases/csp/parent-no-eval.php (should see PASS in both frames, but only the second one has it).

The parent is served with the CSP header "script-src 'unsafe-inline'". It includes an iframe that is served with the CSP header "sandbox allow-scripts".

The iframe tries to make an eval() call, and fails with "EvalError: Eval is disabled" (with JSC) and/or "Code generation from strings disallowed for this context " (with V8).

If I include the same iframe with the equivalent "sandbox" attribute, then eval() works.

[Adam Barth]

Created attachment 146120 [details]
test

[Adam Barth]

Looks like the problem is that we're performing a secure transition from the initial about:blank document to the document from the network.  When we do that, we reuse the global object (this some crazy compat thing which I can explain if you're curious), and it carries forward the "no eval" bit.

The proper solution is probably to reset the "no eval" bit even when doing a secure transition.

[Adam Barth]

Created attachment 146131 [details]
possible fix

[Adam Barth]

Created attachment 146145 [details]
Patch

[Adam Barth]

Comment on attachment 146145 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=146145&action=review

> Source/WebCore/bindings/v8/ScriptController.cpp:300
> -    v8::Handle<v8::Context> v8Context = V8Proxy::mainWorldContext(m_frame);
> +    v8::Handle<v8::Context> v8Context = proxy()->windowShell()->context();

Note: This change isn't strictly necessary.  I just did it to mirror enableEval above.

[Mihai Parparita]

Comment on attachment 146145 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=146145&action=review

> Source/WebCore/bindings/v8/ScriptController.cpp:296
>      if (!m_proxy->windowShell()->initContextIfNeeded())

Nit: switch this to accessing m_proxy via proxy() for consistency with the other uses you're adding.

[Adam Barth]

Created attachment 146613 [details]
Patch for landing

[Adam Barth]

Comment on attachment 146613 [details]
Patch for landing

Actually, I should test this patch on JSC before landing it.

[Adam Barth]

Comment on attachment 146613 [details]
Patch for landing

JSC looks to work as well.  Good times.

[WebKit Review Bot]

Comment on attachment 146613 [details]
Patch for landing

Rejecting attachment 146613 [details] from commit-queue.

New failing tests:
fast/repaint/block-selection-gap-in-composited-layer.html
Full output: http://queues.webkit.org/results/12910753

[WebKit Review Bot]

Created attachment 146662 [details]
Archive of layout-test-results from ec2-cq-02

The attached test failures were seen while running run-webkit-tests on the commit-queue.
Bot: ec2-cq-02  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[WebKit Review Bot]

Comment on attachment 146613 [details]
Patch for landing

Clearing flags on attachment: 146613

Committed r119913: <http://trac.webkit.org/changeset/119913>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.