search

WICG / private-network-access

https://wicg.github.io/private-network-access/
Other
58 stars 22 forks source link

Bypass via "mixed" content #20

Open davidben opened 4 years ago

davidben commented 4 years ago

tl;dr: When a private IP fetches from a public IP, we should require TLS from the public IP.

Suppose http://corp.example is an intranet or localhost server. It serves an HTML file which has some JS, so it writes <script src="/script.js"></script>.

An attacker then points evil.example to corp.example's IP address and causes the user to visit http://evil.example. The intranet site could detect this by checking the Host header but, realistically, many servers do not check this.

CORS-RFC1918 will treat that document as private address space. The browser then loads /script.js which resolves to http://evil.example/script.js. The attacker now rebinds evil.example to an attacker-controlled IP. The attacker now has arbitrary script running in a private address space context, which bypasses CORS-RFC1918 checks.

I think the two things that went wrong in this scenario are:

  1. Although the document as authenticated via the intranet, the part of the base URL wasn't and the document's meaning depends on the base URL.
  2. An intranet-authenticated context sourced unauthenticated script from the public internet, which means its security level is effectively downgraded.

(1) seems hard to fix, short of the browser having intranet vs internet names preconfigured. In that case we wouldn't categorize these based on the resolved IP at all. But then we don't get to plug holes in the mass of broken configurations today.

(2) is really an analog of mixed content in HTTPS. If we blocked that, we would block this attack as well as other misconfigurations which make no sense. Though I do worry that (1) may have other fun implications to think about.

letitz commented 3 years ago

Interesting, thanks for the analysis David!

I think I agree with your proposal (tl;dr). It seems to me that is is strictly security-positive too.

I'm not sure how widespread this problem is, and would be interested to see some measurements to gauge its extent. This might affect launch decisions, but I do not think it should prevent this idea from making its way into the spec.

@mikewest do you agree?

mikewest commented 3 years ago

If we can get away with it from a deployment perspective, great. I'd suggest documenting the threat in a security considerations section, and pointing to the TLS requirement @davidben suggests as a possible solution. I would like things to move this way generally, but given the deployment challenges we already see, I'd suggest that something like this is a reasonable thing to ship later. :)