Issue metadata
Sign in to add a comment
|
XFO-related WPT tests fail in --isolate-origins mode |
||||||||||||||||||||||||
Issue descriptionREPRO STEPS: 1. Run the following 3 layout tests while isolating wpt test origins: - external/wpt/x-frame-options/deny.sub.html - external/wpt/x-frame-options/multiple.sub.html - external/wpt/x-frame-options/sameorigin.sub.html Example command: DISPLAY=:20 third_party/WebKit/Tools/Scripts/run-webkit-tests -t gn --no-retry --additional-drt-flag=--no-sandbox --additional-drt-flag=--isolate-origins=http://www.web-platform.test:8001/,http://www1.web-platform.test:8001/,http://www2.web-platform.test:8001/,http://xn--n8j6ds53lwwkrqhv28a.web-platform.test:8001/,http://xn--lve-6lad.web-platform.test:8001/,http://www.web-platform.test:8081/,http://www1.web-platform.test:8081/,http://www2.web-platform.test:8081/,http://xn--n8j6ds53lwwkrqhv28a.web-platform.test:8081/,http://xn--lve-6lad.web-platform.test:8081/,https://www.web-platform.test:8444/,https://www1.web-platform.test:8444/,https://www2.web-platform.test:8444/,https://xn--n8j6ds53lwwkrqhv28a.web-platform.test:8444/,https://xn--lve-6lad.web-platform.test:8444/ --additional-expectations=third_party/WebKit/LayoutTests/FlagExpectations/site-per-process external/wpt/x-frame-options EXPECTED BEHAVIOR: All tests pass ACTUAL BEHAVIOR: 3 tests fail, indicating an unexpected ability to access contentDocument of a cross-origin frame: assert_throws: function "function () { return i.contentDocument; }" did not throw NOTE: I've marked this bug as a security bug mostly out of caution. The bug probably doesn't impact --isolate-extensions and I am not sure if the bug applies to the sign-in isolation. I also only skimmed the tests and it is possible that this is only a test issue (it didn't seem like it at a first glance).
,
Oct 26 2017
We ought to be committing the blocked frame into an error page with an opaque origin. Perhaps the error page mechanism isn't playing nicely with `--isolate-origins`? Since we haven't shipped this flag yet, I'm not sure this makes sense to track as a security bug. It's just a bug in the feature that we should fix before shipping it. I'd suggest opening this up if y'all don't have objections. :)
,
Oct 26 2017
Issue 777419 (see comment #8) sounds somewhat similar to the theory in #c2.
,
Oct 26 2017
RE: #c1 This does indeed look like a dupe of issue 582245 as pointed out in #c1 - no exception gets thrown because (when running external/wpt/x-frame-options/deny.sub.html) we return early below (and exception would have been thrown by CanAccessWindow): bool BindingSecurity::ShouldAllowAccessTo( const LocalDOMWindow* accessing_window, const Node* target, ExceptionState& exception_state) { if (!target) return false; <-- EARLY RETURN HAPPENS HERE IN PRESENCE OF OOPIFs return CanAccessWindow(accessing_window, target->GetDocument().domWindow(), exception_state); } RE: c2 I'd rather keep the restrictions given that 1) issue 582245 is restricted and 2) we plan to ship --isolate-origins in M63 (and OOPIFs in general have shipped in M56).
,
Apr 13 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by alex...@chromium.org
, Oct 25 2017