tl;dr: Local IP addresses are not globally unique.

This attack is a bit broader than the title implies:

 i) It doesn't strictly require the browser's cache.
 ii) It doesn't require any sort of MITM.

Scenario demonstrating both: 

1. While I'm in the coffee shop, I visit http://dodgysite, which contains http://192.168.171.1/Probe.html as a subframe of the current page. 
2. That frame continually pokes at http://192.168.178.1/ via fetch() or XHR, waiting patiently until...
3. I close my laptop and bring it home. At home, I open my laptop and the attackers' frame is now same-origin to my home router. 

Other variations:

1. If the user's local service has any localStorage, indexedDB, cookies, etc, those can be stolen by the attacking service.
2. If the user had stored credentials in their password manager, those could be at risk (we have a few mitigations that might protect automated groveling, but inadvertent user-interaction might foil them) 

elawrence: Regarding c#1, to work without MITM, does that mean that the attacker must control both the router and the website that the user is browsing? I'm not clear on how that works otherwise. This is plausible for a captive portal, but that is already a MITM.

Re #3: In the attack scenario, the attacker controls two different endpoints: 

   1. Some endpoint that the user is deliberately browsing
   2. An endpoint with a private IP address that matches the private IP address to attack on the user's home/private network

My point that the attacker need not be a MiTM is that the victim could be browsing the attacker's site directly, so the attacker need not do on-the-fly modification of any third-party pages (as in step #1 of the original report). Having a MiTM position provides the benefit that the attacker need not entice the user to visit his site, he can MiTM inject into any other HTTP page the user happens to load.

I think this is related to https://crbug.com/378566, but I'm not an expert. Assigning to mkwst for triage. 

It's similar to 378566, but even after that change is in place, the attacker would just serve a CORS policy from their private IP, enabling their poisoned resource to be cached for later reuse. That later reuse would be same-origin to the router page and this CORS restrictions wouldn't come into play. 

Comment 8 is correct. Limiting access to internal IP ranges as in 378566 will not address the scenario outlined here, as the attacker would simply allow access to their attack pages.

Comment 1 is also correct. RFC1918 IP addresses are not unique, and are completely dependent on the user's network environment. I can think of draconian ways of addressing the cache problem ("don't cache resources for RFC1918 addresses", for instance), and even more draconian ways of addressing the active page/frame porblem from comment 1 ("reload RFC1918 pages whenever the local IP address changes", for example), but I'm not sure how to evaluate whether those are reasonable solutions.

I think I agree, however, that it's reasonable to treat them differently to "normal" DNS names.

+ some network folks for their thoughts.

Ping - any thoughts here would be much appreciated.

I'm unsure if there's a specific request? I have no (new) thoughts to share. Everything described is working as intended, from a spec point of view, and any divergence would be a divergence from spec behaviour.

Various behaviours:
- Don't cache resources for HTTP pages. Full stop. There's no way to guarantee the authenticity of the request to support its persistence.
  - Breaks the web.
  - But prevents others from breaking it.
- Don't cache resources for "Internal" pages
  - Lack a definition of internal (is it just the IP? Is it "resolves to that IP?")?
    - This would fundamentally change how the Fetch spec works w/r/t loading behaviours, which would affect all Chrome loads anyways
  - Doesn't meaningfully address the problem for other forms of HTTP resources
  - A reasonable question about the 'priority' of this related to other efforts. Is this meaningfully moving the security bar forward?
- Declare it as a WontFix/WorkingAsIntended - a known issue with the flaws of HTTP

I defer to OWP-Security on this. I don't really think it's network related at all. HTTP is bad, and if you're in a privileged position on the network - whether it's responding to local IP addresses or the ability to MITM HTTP - then all bets are over. Any changes here really go into the Blink loading side (I think), minimally because it involves the Fetch spec which is more in the //content and Blink-side.

c#14: thanks for the thoughts. This helps a lot.

I'm going to WontFix this for now and open it up.