Bug 71599 – JavaScript URLs execute in sandboxed iframes

• Component: New Bugs
• Status: RESOLVED FIXED

[Adam Barth]

JavaScript URLs execute in sandboxed iframes

[Adam Barth]

Created attachment 113737 [details]
Patch

[Adam Barth]

This patch fixes an intentional regression from earlier today.

[Eric Seidel (no email)]

Comment on attachment 113737 [details]
Patch

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

> Source/WebCore/dom/ScriptExecutionContext.h:190
> +    SandboxFlags m_sandboxFlags;
>      RefPtr<SecurityOrigin> m_securityOrigin;
>      RefPtr<ContentSecurityPolicy> m_contentSecurityPolicy;

You might want to add a fixme about your intended eventual design here.

[Adam Barth]

> You might want to add a fixme about your intended eventual design here.

For those following along by email, I suggested to Eric that we should factor a SecurityContext base class out of ScriptExecutionContext.

[Adam Barth]

Hum...  Looks like I broke some things.  One moment.

[Adam Barth]

Created attachment 113741 [details]
updated patch

[Adam Barth]

Committed r99347: <http://trac.webkit.org/changeset/99347>

[Tony Chang]

This appears to have caused an assert to be hit in fast/encoding/hebrew/8859-8-e.html.  The stack is:

ASSERTION FAILED: m_frame->document()->securityOrigin()->isUnique()
/b/build/slave/webkit-mac-latest-dbg/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../bindings/ScriptControllerBase.cpp(44) : bool WebCore::ScriptController::canExecuteScripts(WebCore::ReasonForCallingCanExecuteScripts)
1   0x2832d671 WebCore::ScriptController::canExecuteScripts(WebCore::ReasonForCallingCanExecuteScripts)
2   0x283ba06c WebCore::V8Proxy::retrieve(WebCore::Frame*)
3   0x283bcb6b WebCore::V8Proxy::mainWorldContext(WebCore::Frame*)

[Tony Chang]

Oh, the same assert for fast/css/getComputedStyle/computed-style-border-image.html .

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=fast%2Fcss%2FgetComputedStyle%2Fcomputed-style-border-image.html%2Cfast%2Fencoding%2Fhebrew%2F8859-8-e.html

[Adam Barth]

Thanks.  That's very strange.

[Adam Barth]

I'll try to reproduce locally with the Chromium port.

[Adam Barth]

Those stack traces are really odd:

ASSERTION FAILED: m_frame->document()->securityOrigin()->isUnique()
/b/build/slave/webkit-mac-latest-dbg/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../bindings/ScriptControllerBase.cpp(44) : bool WebCore::ScriptController::canExecuteScripts(WebCore::ReasonForCallingCanExecuteScripts)
1   0x17600671 WebCore::ScriptController::canExecuteScripts(WebCore::ReasonForCallingCanExecuteScripts)
2   0x1768d06c WebCore::V8Proxy::retrieve(WebCore::Frame*)
3   0x1768fb6b WebCore::V8Proxy::mainWorldContext(WebCore::Frame*)
4   0x15649097 WebKit::WebFrameImpl::mainWorldScriptContext() const
5   0x1558498f WebKit::WebTestingSupport::resetInternalsObject(WebKit::WebFrame*)
6   0x155524cf TestShell::resetTestController()
7   0x1550e5b1 runTest(TestShell&, TestParams&, std::string const&, bool)
8   0x1550de8f main
9   0x154edaf6 start
[43320:2307:463329065975150:ERROR:process_util_posix.cc(134)] Received signal 11
	0   DumpRenderTree                      0x154aa0cf base::debug::StackTrace::StackTrace() + 63
	1   DumpRenderTree                      0x154aa06b base::debug::StackTrace::StackTrace() + 43
	2   DumpRenderTree                      0x15b17ee7 base::(anonymous namespace)::StackDumpSignalHandler(int, __siginfo*, __darwin_ucontext*) + 295
	3   libSystem.B.dylib                   0x963b305b _sigtramp + 43
	4   ???                                 0xffffffff 0x0 + 4294967295
	5   DumpRenderTree                      0x1768d06c WebCore::V8Proxy::retrieve(WebCore::Frame*) + 92
	6   DumpRenderTree                      0x1768fb6b WebCore::V8Proxy::mainWorldContext(WebCore::Frame*) + 43
	7   DumpRenderTree                      0x15649097 WebKit::WebFrameImpl::mainWorldScriptContext() const + 87
	8   DumpRenderTree                      0x1558498f WebKit::WebTestingSupport::resetInternalsObject(WebKit::WebFrame*) + 63
	9   DumpRenderTree                      0x155524cf TestShell::resetTestController() + 559
	10  DumpRenderTree                      0x1550e5b1 runTest(TestShell&, TestParams&, std::string const&, bool) + 1377
	11  DumpRenderTree                      0x1550de8f main + 3439
	12  DumpRenderTree                      0x154edaf6 start + 54
ax: bbadbeef, bx: ebdff9c3, cx: ebdff9c3, dx: ebdff9c3
di: 18f45006, si: 18f44fa8, bp: bfffe768, sp: bfffe710, ss: 23, flags: 10286
ip: 17600676, cs: 1b, ds: 23, es: 23, fs: 0, gs: f
None

The odd thing is that they're below:

5   0x1558498f WebKit::WebTestingSupport::resetInternalsObject(WebKit::WebFrame*)
6   0x155524cf TestShell::resetTestController()

which is testing-only machinery, and it doesn't make sense that those tests would even execute that line of code because it only execute in view-source mode, which these tests aren't.

[Adam Barth]

In both cases, the tests are the first test alphabetically in their folder, which probably means they're at the start of a test block.

[Adam Barth]

The preceding tests are (at least on Linux) are

fast/encoding/dumpAsText/utf-16-no-bom.xml
fast/css/dumpAsText/xml-stylesheet-pi-not-in-prolog.xml

which is interesting because they both have "dumpAsText" in their path.

[Adam Barth]

I can't reproduce by running the individual tests (or their folder), but I can reproduce using this command line:

./Tools/Scripts/new-run-webkit-tests --chromium fast/encoding/dumpAsText fast/encoding/hebrew --child-processes=1

[Adam Barth]

From chromium/TestShell.cpp:

    if (testUrl.find("/dumpAsText/") != string::npos
        || testUrl.find("\\dumpAsText\\") != string::npos) {
        m_layoutTestController->setShouldDumpAsText(true);
        m_layoutTestController->setShouldGeneratePixelResults(false);
    }

[Adam Barth]

I have a fix locally.

[Adam Barth]

Should be fixenated after http://trac.webkit.org/changeset/99351