Introduce a new PrivateNetwork permission for Chrome Apps
Reported by
jannhorn@googlemail.com,
Sep 13 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Unpack the attached webview-test.zip. 2. In webview-test/window.html , replace `http://127.0.0.1/` with the URL of some local webserver (e.g. on localhost or some domain name that points to an RFC1918 IP). 3. Install the unpacked app. 4. Inspect the user-visible permissions of the installed app. 5. Launch the installed app. 6. Wait a few seconds. What is the expected behavior? The webview should refuse to load content from the local IP address. What went wrong? Without special permissions, the app is able to fully interact with a website served from a local host, potentially giving it the ability to e.g. reconfigure the user's CUPS installation or router. The obtained level of access is roughly equivalent to universal CORS access for non-credentialed requests. It might make sense to reduce the likelyhood that this works by blocking RFC1918 addresses, which would be somewhat related to Mike West's cors-rfc1918 proposal. Did this work before? N/A Chrome version: 54.0.2837.0 Channel: dev OS Version: Flash Version: 23.0.0.141
,
Sep 14 2016
,
Sep 21 2016
,
Sep 21 2016
I need to better understand the security model here. As far as I can tell, the WebView allows the app to ignore Same-Origin-Policy altogether.
,
Sep 22 2016
Thanks for the repro files! To summarize my findings: 1. It's expected that a Chrome App with the WebView permission can circumvent Same-Origin-Policy and read/write/execute content in arbitrary origins via the exposed ExecuteScript API. 2. The impact of #1 is somewhat limited in a normal Chrome App, insofar as the Chrome App executes from an isolated context and the user's cookies/storage from the main browser do not carry over to that context. As a consequence, the impact to the user's information is limited to what operations he undertakes when using the app (e.g. supplying his Facebook credentials by logging into the WebView in the app exposes Facebook to attack by the app). 3. Access to private network addresses may expose a level of "ambient authority" otherwise unavailable to untrusted apps, insofar as these private network addresses are typically not reachable from web-sourced content because they are "inside the firewall" (modulo vectors like DNS rebinding attacks). Ambient Authority assumptions mean that the victim servers or services may have exploitable attack surface protected solely by virtue of the expectation that the attack surface is only reachable from trusted code. In my conversations with platform experts, #1-#3 have been triaged to be "Working as Intended" 4. For the future, there are proposals around limiting access (via fetch and navigation) to private addresses by requiring CORS (e.g. https://mikewest.github.io/cors-rfc1918/); these proposals are presently written with the expectation that the requesting originator has a security context that can be evaluated as "public" or "private". Today, a WebView in a Chrome App does not expose that distinction. If the WebView were to do so (for instance, by treating all Chrome Apps as a "public context" for the purposes of this evaluation), it's expected that the App Platform would need to introduce a new permission (e.g. PrivateNetworkAccess) that would allow circumvention of the CORS requirement in order to interoperate with servers and services that are not written to meet the CORS requirement. As this issue fundamentally represents a suggestion for a new security feature, I've changed its Type and assigned it to the component for triage. |
||||
►
Sign in to add a comment |
||||
Comment 1 by elawrence@chromium.org
, Sep 14 2016