24822 2014-02-26 17:23:23 +0000 Clarification request: Is remote to local allowed? 2016-01-04 14:38:21 +0000 1 1 1 Unclassified WHATWG Fetch unspecified PC Windows NT RESOLVED MOVED blocked on detailed implementer input P2 normal Unsorted 1 nicholas mkwst annevk jaffathecake jonas mike mkwst robin w3c sideshowbarker+fetchspec oldest_to_newest 101443 0 nicholas 2014-02-26 17:23:23 +0000 This currently works in all browsers supporting CORS: * Setup a local web server such that cannot be accessed remotely. It responds with Access-Control-Allow-Origin: * for everything. * Load up a remote web app, say app.nczonline.net. * Inside of the web app, make an Ajax request to http://localhost:1234/resource There's nothing in the spec that says it shouldn't work, and so it does. The question I had is if this was an oversight (and therefore a bad idea to take advantage of) or a supported feature of CORS (in which case it's safe to assume it's not going away in the future). It seems like the question of whether or not remote resources should ever be able to access local resources is a higher-level security concern that needs to be addressed in the spec in some way. 102650 1 annevk 2014-03-19 16:16:55 +0000 So what is we want to do here? If URLs are not same-origin, and the target URL's host is "localhost", return a network error? 106832 2 jaffathecake 2014-05-27 10:31:21 +0000 Say I'm developing locally, and I have a local version of some API for testing purposes, would jakearchibald.dev (which maps to localhost) be able to reach localhost:3000? Would jakearchibald.dev be able to talk to jakearchibald.dev:3000? 106833 3 robin 2014-05-27 10:45:09 +0000 (In reply to Jake Archibald from comment #2) > Say I'm developing locally, and I have a local version of some API for > testing purposes, would jakearchibald.dev (which maps to localhost) be able > to reach localhost:3000? > > Would jakearchibald.dev be able to talk to jakearchibald.dev:3000? My expectation here would be that localhost (as a name) would be blocked, as would explicit access to 127.0.0.1 or ::1. Possibly, likewise for explicit access to the user's IP. But names mapping to loopback would not be affected so jakearchibald.dev could talk to jakearchihairy.dev. 106835 4 robin 2014-05-27 10:53:31 +0000 Further idea, based on discussion at: http://krijnhoetmer.nl/irc-logs/whatwg/20140527#l-237 If the origin that is making a request to localhost (or any other explicitly local address) is itself one that is local (either explicitly or because its domain maps to loopback) then that request is subject to the usual processing, CORS and all. If however that origin maps to any other IP, access to explicit local addresses is just blocked. This should block the attacks from arbitrary sites, while making it possible for developers to hack things locally without getting unexpected blocking behaviour for localhost. 107246 5 annevk 2014-06-04 09:08:28 +0000 Mike, should this be a duplicate of bug 22262? From public-webappsec it seems like this is MIX territory now. 107253 6 mkwst 2014-06-04 09:55:51 +0000 Yeah, it makes sense to pull this (along with the RFC1918 IP address restrictions) into the mixed content spec. I'm working on that, so I'll grab this bug. 120902 7 annevk 2015-06-11 09:59:02 +0000 What's the latest on this? 122554 8 mkwst 2015-08-11 06:52:33 +0000 (In reply to Anne from comment #7) > What's the latest on this? The latest is that the RFC1918 restrictions got pulled out of MIX because of disagreements, and there's no good home for them at the moment. I'd still like to make them happen, but WebAppSec wasn't enthusiastic about going along with me because of IoT concerns and etc. It's been on my "nice to do" list for Chrome for months now, but I haven't made time to understand enough of the network stack's decision-making process to get the data I need in the places I need it. *shrug* Status: Pending, I guess. 123320 9 annevk 2015-09-26 10:14:18 +0000 Nicholas, it seems like the answer to your question is that you should be wary about relying on this, but that we haven't really sorted out where that should be specified. Mike, can we track this issue elsewhere since I'd like to eventually close off Fetch bugs in favor of GitHub and it seems like this is no longer a Fetch issue per se. 123321 10 mkwst 2015-09-26 11:15:49 +0000 (In reply to Anne from comment #9) > Nicholas, it seems like the answer to your question is that you should be > wary about relying on this, but that we haven't really sorted out where that > should be specified. > > Mike, can we track this issue elsewhere since I'd like to eventually close > off Fetch bugs in favor of GitHub and it seems like this is no longer a > Fetch issue per se. Sure. This can live somewhere in w3c/webappsec. There hasn't been appetite to push this there in the recent past, but I'd like to try again. 124516 11 annevk 2016-01-04 14:38:21 +0000 https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0000.html https://mikewest.github.io/cors-rfc1918/ No need to track this here anymore.