Issue metadata
Sign in to add a comment
|
Security: view-source: is same-origin with the wrapped URI
Reported by
juhon...@gmail.com,
Apr 17 2018
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS I'm not sure when this changed, but view-source: now seems to be same-origin with the URI it wraps. In other words, scripts from `https://example.com/` are able to access `view-source:https://example.com/` and vice versa. VERSION Chrome Version: current stable Operating System: all REPRODUCTION CASE To check the origin of a view-source: page, open DevTools and type `location.origin`. In old versions of Chrome it used to be null, but now it matches the wrapped URI. To verify that script execution on a view-source: page is possible: 1. Navigate to `view-source:https://twitter.com/` 2. In the source code, find a link to `twitter.com` and click it 2.1. Link opens in a new tab 3. In the newly opened tab, open DevTools and use `opener` to access the view-source: page This is not necessarily a security issue on its own, but view-source: has been riddled with bugs in the past, which makes it a bad idea to allow script access. See for example Issue 108611 and Issue 247151. After you have script execution on a view-source: page, it's also possible to navigate to other view-source: pages across origins and manipulate the omnibox to show TLS indicators and hide the actual `view-source:` prefix.
,
Apr 17 2018
From https://chromium-review.googlesource.com/c/chromium/src/+/917121/1..2: Interestingly, for six years, view-source documents were in unique origins: https://chromium.googlesource.com/chromium/src/+/c92a57f13f7b09b68e5c0534129f23eba148ac5c Then, a fuzzer bug crbug.com/697830 came along in 2017, noting that a check fails because XMLDocumentParser.cpp puts a document in view-source mode but attaches an onload handler, causing a security CHECK failure (origin mismatch) before the event is invoked. The code that pushed the document to a unique-origin was removed in https://chromium.googlesource.com/chromium/src/+/3de53e557c2b84aed1cb4ba9ed1133ac361da46c. (That CL left behind the pointless "return" in this function that we again need now that we're pushing documents into a unique origin again). So why doesn't the same CHECK fail with this CL? Because blink::LocalDOMWindow::DispatchWindowLoadEvent calls CanExecuteScripts, and if it returns false, it doesn't call onload listeners... even if those listeners are listening from another document. Which gets weird because it means that onload events for sandboxed pages behave differently across browsers (https://bayden.com/test/sandbox/onload.html).
,
Apr 17 2018
In terms of fixes here, the simplest way to break the repro in #0 would be to change the link generation in view-source such that: anchor->setAttribute(relAttr, "noopener"); but more generally, yes, it would be good to: 1. Apply CSP with a default-src of none, 2. Disallow script execution, and 3. Push to a unique origin The only challenge is the degree to which these changes will break our test cases, which depend upon script execution and non-unique origins.
,
Apr 18 2018
,
Apr 18 2018
,
Apr 18 2018
If it lands, the change in Issue 834023 should break the supplied repro without actually changing to an opaque origin. We might wish to dupe this issue to issue 808407 , which calls for using an opaque origin and disabling script execution.
,
Apr 27 2018
,
Nov 4
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 elawrence@chromium.org
, Apr 17 2018