Intent to Implement: Cross-Origin-Opener-Policy

257 views
Skip to first unread message

Charlie Reis

unread,
May 29, 2019, 1:43:44 PM5/29/19
to blink-dev, Mike West, Anne van Kesteren, Nika Layzell, Ryosuke Niwa, Yutaka Hirano, Kinuko Yasuda, Artur Janc, Chromium Site Isolation
cr...@chromium.org https://docs.google.com/document/d/1Ey3MXcLzwR1T7aarkpBXEwP7jKdd2NvQdgYvF8_8scI/edit?usp=sharing Specification: https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e https://github.com/whatwg/html/issues/3740 (Not started yet) The Cross-Origin-Opener-Policy response header provides a way for a document to request a new browsing context group to better isolate itself from other untrustworthy origins. Optionally, browsers can also choose to place top-level documents in a different process from documents without a matching Cross-Origin-Opener-Policy. At least two types of attacks are possible when a document shares a browsing context group and process with cross-origin documents: 1) Cross-window attacks. For example, a malicious document may open a victim document in a new window and later navigate the window to a look-alike document to trick the user. 2) Process-wide attacks. Transient execution attacks like Spectre allow a malicious document to leak data from a victim document, if they share an OS process. In browsers with full Site Isolation and out-of-process iframes, it is possible to mitigate process-wide attacks by putting documents from different sites in different processes. Cross-window attacks are less severe than process-wide attacks, but still remain possible in such browsers. In browsers without out-of-process iframes, it is difficult to put cross-origin documents in a different process if they are in the same browsing context group, without breaking script interactions between same-origin popups and iframes. We want to give sites the ability to sever all references to other browsing contexts to mitigate cross-window attacks, and to make it easier for browsers without out-of-process iframes to load the victim document in a new OS process to mitigate process-wide attacks like Spectre.
In browsers that do not support the header, documents will not get the level of isolation they expect. Firefox: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1521808) Firefox has implemented this behind the browser.tabs.remote.useCrossOriginOpenerPolicy pref. Edge: No public signals Safari: Public support (https://github.com/whatwg/html/issues/3740#issuecomment-443008140) Safari 12 shipped an earlier version ("cross-origin-window-policy"), per https://developer.apple.com/safari/whats-new/. Web developers: No signals This header will often be used in tandem with Cross-Origin-Resource-Policy (https://www.chromestatus.com/features/4647328103268352) to prevent subresources from entering other renderer processes, as well as the to-be-renamed Cross-Origin-Resource-Policy-Policy (https://github.com/whatwg/html/issues/4175) to enable precise timers and memory measurements. When deploying this header, web developers may need to be careful not to break their existing uses of cross-window scripting after window.open calls. The initial implementation will be behind a flag. No polyfill should be needed, since this is a security feature that only restricts page behavior and doesn't add new capabilities on its own. This feature is designed to improve security by giving documents a way to better isolate themselves.
No DevTools changes currently planned. There is some interest in a report-only mode, though this is somewhat challenging to design. Yes The header will create new browsing context groups on all Blink platforms, though the process model behavior may be platform specific. No (Not yet implemented.) https://www.chromestatus.com/features/5432089535053824  

Yoav Weiss

unread,
Jun 6, 2019, 8:37:54 AM6/6/19
to Charlie Reis, blink-dev, Mike West, Anne van Kesteren, Nika Layzell, Ryosuke Niwa, Yutaka Hirano, Kinuko Yasuda, Artur Janc, Chromium Site Isolation
I'd recommend to kick it off ASAP so that it would get sufficient attention by the time you'd want to ship.
 
The Cross-Origin-Opener-Policy response header provides a way for a document to request a new browsing context group to better isolate itself from other untrustworthy origins. Optionally, browsers can also choose to place top-level documents in a different process from documents without a matching Cross-Origin-Opener-Policy. At least two types of attacks are possible when a document shares a browsing context group and process with cross-origin documents: 1) Cross-window attacks. For example, a malicious document may open a victim document in a new window and later navigate the window to a look-alike document to trick the user. 2) Process-wide attacks. Transient execution attacks like Spectre allow a malicious document to leak data from a victim document, if they share an OS process. In browsers with full Site Isolation and out-of-process iframes, it is possible to mitigate process-wide attacks by putting documents from different sites in different processes. Cross-window attacks are less severe than process-wide attacks, but still remain possible in such browsers. In browsers without out-of-process iframes, it is difficult to put cross-origin documents in a different process if they are in the same browsing context group, without breaking script interactions between same-origin popups and iframes. We want to give sites the ability to sever all references to other browsing contexts to mitigate cross-window attacks, and to make it easier for browsers without out-of-process iframes to load the victim document in a new OS process to mitigate process-wide attacks like Spectre.
In browsers that do not support the header, documents will not get the level of isolation they expect. Firefox: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1521808) Firefox has implemented this behind the browser.tabs.remote.useCrossOriginOpenerPolicy pref. Edge: No public signals Safari: Public support (https://github.com/whatwg/html/issues/3740#issuecomment-443008140) Safari 12 shipped an earlier version ("cross-origin-window-policy"), per https://developer.apple.com/safari/whats-new/. Web developers: No signals This header will often be used in tandem with Cross-Origin-Resource-Policy (https://www.chromestatus.com/features/4647328103268352) to prevent subresources from entering other renderer processes, as well as the to-be-renamed Cross-Origin-Resource-Policy-Policy (https://github.com/whatwg/html/issues/4175) to enable precise timers and memory measurements. When deploying this header, web developers may need to be careful not to break their existing uses of cross-window scripting after window.open calls. The initial implementation will be behind a flag. No polyfill should be needed, since this is a security feature that only restricts page behavior and doesn't add new capabilities on its own. This feature is designed to improve security by giving documents a way to better isolate themselves.
No DevTools changes currently planned. There is some interest in a report-only mode, though this is somewhat challenging to design. Yes The header will create new browsing context groups on all Blink platforms, though the process model behavior may be platform specific. No (Not yet implemented.) https://www.chromestatus.com/features/5432089535053824  

--
To unsubscribe from this group and stop receiving emails from it, send an email to site-isolation-...@chromium.org.
Reply all
Reply to author
Forward
0 new messages