search

w3c / webappsec-mixed-content

WebAppSec Mixed Content
https://w3c.github.io/webappsec-mixed-content/
Other
12 stars 22 forks source link

Clarify mixed content behavior for access to origins in CIDR 127.0.0.0/8 or ::1/128 #17

Open seemant opened 5 years ago

seemant commented 5 years ago

Should access to http://127.0.0.0/8 or ::1/128 be considered safe for mixed content policy? We have noticed that some browsers have allowed http://127.0.0.1, but still consider access to other addresses such as http://127.79.20.1 as risky and apply the mixed content policy.

The W3C spec considers origins in the above CIDR(s) "potentially trustworthy". However, browsers seem to have special affinity to 127.0.0.1. And Safari refuses to honor 127.0.0.1 also.

annevk commented 5 years ago

I suspect you're seeing https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost in part.

seemant commented 5 years ago

I was referring to the following section of W3C spec: https://www.w3.org/TR/secure-contexts/#potentially-trustworthy-origin, it says 127.0.0.0/8 or ::1/128 is a "potentially trustworthy" origin.

Following specification update commit says "Among other things, http://127.0.0.1, will not be considered mixed content": https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165. I assume "Among other things" means other local addresses are also allowed? But browser developers don't think seem to think so.

In our tests we did not use 'localhost' for fetching the content.

mikewest commented 4 years ago

This spec (and Secure Contexts) treats 127.0.0.0/8 as "secure-enough" to load content. It's difficult to test that behavior via WPT, but it was the intended result, and it's the result that I think Chrome ships (https://cs.chromium.org/chromium/src/net/base/url_util.cc?rcl=446cbaf691612489d47644ca13fa72128a1c1911&l=358, called from https://cs.chromium.org/chromium/src/services/network/public/cpp/is_potentially_trustworthy.cc?rcl=446cbaf691612489d47644ca13fa72128a1c1911&l=205).

Safari was reconsidering their stance earlier in the year (https://bugs.webkit.org/show_bug.cgi?id=171934), so I'm hopeful that they align with the spec in the somewhat near future.

https://bugzilla.mozilla.org/show_bug.cgi?id=1488740 is a similar bug against Mozilla, though I don't think it covers exactly the case you're pointing to. It's probably a good idea to file a more specific bug against that engine.

fred-wang commented 3 years ago

Safari was reconsidering their stance earlier in the year (https://bugs.webkit.org/show_bug.cgi?id=171934), so I'm hopeful that they align with the spec in the somewhat near future.

Some refactoring is in progress in WebKit to align better with the spec, but for now I'm not sure we can easily "adhere to the localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address)." see https://bugs.webkit.org/show_bug.cgi?id=171934#c78 ; perhaps that would be easier if the spec allows WebKit to do that if it is sure that APIs/libraries resolve to loopback IP addresses.

https://bugzilla.mozilla.org/show_bug.cgi?id=1488740 is a similar bug against Mozilla, though I don't think it covers exactly the case you're pointing to. It's probably a good idea to file a more specific bug against that engine.

The Mozilla part is done.

annevk commented 3 years ago

I think it's a bug in https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06#section-3 that it doesn't allow for name resolution APIs to be altered and the application to rely on them being altered. It's black box indistinguishable and therefore totally valid.

annevk commented 3 years ago

As part of having to say something about DNS in Fetch I've been considering moving the localhost requirement there somehow, though I didn't realize it allowed for variation (I thought we'd always require localhost to map to loopback).

fred-wang commented 3 years ago

As part of having to say something about DNS in Fetch I've been considering moving the localhost requirement there somehow, though I didn't realize it allowed for variation (I thought we'd always require localhost to map to loopback).

If all browsers are moving to implement this localhost requirement, should we consider removing this variation ? Does anyone know what was the rationale for introducing it ?

@othermaciej wondered the same when we discussed this on webkit slack:

othermaciej 20 days ago Looking at the spec closer, it seems like the relevant clause is a MAY. othermaciej 20 days ago Is there urgency on aligning on interpretation of the MAY? In which case maybe it should become a SHOULD or a MUST?

annevk commented 3 years ago

I think that would make sense, and if we define it in Fetch we sidestep the question as to whether it should be applicable for the wider internet.

mikewest commented 3 years ago

I think it's a bug in https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06#section-3 that it doesn't allow for name resolution APIs to be altered and the application to rely on them being altered. It's black box indistinguishable and therefore totally valid.

  1. What would you like that document to say instead?
  2. I'm happy to move it to Fetch, as I wasn't able to successfully get it moving with the DNS folks in the IETF, and Fetch covers the bits I actually care about.
annevk commented 3 years ago

I'm not sure about the exact text and whether it matters as it sounds like it will move to Fetch, but I would make resolving localhost to the loopback address a requirement on applications that want the secure context guarantee and leave the implementation details out of it. And then in a note explain that if they are to use a name resolution API for localhost they have to be sure that it doesn't resolve localhost conditionally.

(In Fetch I think I want an algorithm for getting an IP address out of host that would just not defer to DNS or equivalent systems for localhost.)

paulsemel commented 1 year ago

Hello everyone,

I am willing to move forward this discussion so that we can settle on this subject and update the spec accordingly to make it clearer. I will enlarge the discussion a bit to literal IP addresses in general, although loopback addresses will still be treated here.

AutoUpgrade

The idea here is to not upgrade literal IP addresses (all of them). The reason for this is that it is very unlikely we will be able to get a cert for this if we'd be to do the upgrade. Plus, certificate providers like Let's Encrypt do not provide support for this. For the case of the literal loopback IP address, this is also a way to do what web devs requested, and prevents running into "but it works when I run it locally!".

Block Fetch

Then, to avoid having a loophole in mixed content with literal IP addresses, we would hard block them, independently of the type of the mixed content. However, this does not apply to loopback address, since the latter is considered "potentially trustworthy”.

annevk commented 1 year ago

(Fetch has https://fetch.spec.whatwg.org/#resolve-an-origin these days by the way.)

annevk commented 1 year ago

Looking at this again in light of #62, https://bugs.webkit.org/show_bug.cgi?id=171934#c96 is still problematic as https://wicg.github.io/private-network-access/ is not deployed. And even if it were deployed it might not stop port scanning.

mikewest commented 1 year ago

I don't think PNA aims to block requests to IP addresses entirely. @letitz and @iVanlIsh are more up to date than I am on the details, but my recollection was that we'd gate access to private networks on a permission that bypassed mixed content for some specific device (https://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md). Perhaps one of them can weigh in here?

That said, having a default mixed content behavior that blocks requests to IP addresses doesn't seem inconsistent with the model that explainer proposes, does it?

annevk commented 1 year ago

@mikewest #62 doesn't block a number of IP addresses. The concern lies with those.

paulsemel commented 1 year ago

But I guess #62 doesn't go against the concerns made about localhost (and their respective IP address ranges) since it's only meant to be more restrictive on public IP addresses. I think it does not prevent from changing the behaviour for the remaining IP addresses (the loopback ones) if there is a consensus about it. However, I then agree #62 doesn't close this issue.

What we can do is keep this issue open and try to move forward on specifically the local IP address ranges, and move forward on #62 as it's not related to this. What do you think @annevk?

carlosjoan91 commented 1 year ago

To add to what Paul mentioned, IIUC #62 doesn't make access to localhost any more lax than it was before. Since localhost is already defined as potentially trustworthy, with the prior mixed content wording it was already considered not mixed content by the spec, so the exception to hard blocking mixed content IP addresses that Paul is adding only preserves the status quo for localhost. If this is the case, I think the discussion about making access to localhost more restrictive can be handled separately from this change.

annevk commented 1 year ago

I see, I didn't realize "is a potentially trustworthy URL" already bakes a bunch of this in. I think #62 can close this after all, but the fix proposed doesn't seem exactly right. I left a further comment there.

letitz commented 1 year ago

I'm not clear on what the end result of merging #62 does. It sounds like it prevents autoupgrading literal IP address URLs without changing which are blocked as mixed content (localhost: allowed, others: blocked).

In any case, PNA as currently spec'ed does not prevent port scanning. Once https://github.com/WICG/private-network-access/pull/94 lands it will prevent port scanning when the fetch is mixed content. I would like to eventually show a permission prompt for all fetches, even non-mixed content, which would prevent port scanning.