Open davidben opened 4 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?
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. :)
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
tocorp.example
's IP address and causes the user to visithttp://evil.example
. The intranet site could detect this by checking theHost
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 tohttp://evil.example/script.js
. The attacker now rebindsevil.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) 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.