[Webkit-unassigned] [Bug 171934] Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=171934

--- Comment #72 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Frédéric Wang (:fredw) from comment #70)
> Hi. There are a lot of comments in this discussion, I'd just like to try to
> summarize things and see be sure I understand the situation.
> 
> == Bug content ==
> 
> This bug is about not treating loopback adresses as mixed content:
> 
> (1) Required by the specification: 127.0.0.1 and ::1
> (2) Optional: localhost and *.localhost
> 
> In addition for (2)
> 
> (3) the spec adds the restriction that browsers must ensure they don't
> resolve to a non-loopback address.

All correct, yes.

> * Some maintainers of WebKit macOS/iOS ports find the proposed change
> sensible/ok (Youenn and Maciej) others expressed concerns (Brent and
> Alexey). Can you please elaborate whether these concerns apply to both
> (1)+(2) or just (2)? Also, would they be addressed by implementing (3) or do
> you think the current specs are still too lax and WebKit should keep
> departing from them?

Alexey wants to block non-localhost origins from loading any content from localhost, and he wants that to happen *before* we fix this issue. That's a controversial change that app developers are not going to like. Those concerns apply to both (1)+(2), and implementing (3) would not address them at all, because the goal there is to prevent websites from accessing localhost at all.

(In reply to Frédéric Wang (:fredw) from comment #70)
> * Michael and Antonio have investigated this a bit (thanks!). Are you still
> actively working on this? Do you have patches to share?

No, but the required code change for (1) is a one-liner (see comment #46). It's just tests that need work.

> * Tests are likely to break. We can workaround this for (1) by relying on
> localhost instead of 127.0.0.1 but at the end we will still need a better
> solution when we implement (2) such as the one Michael sketched.

I think it will need a new TestController setting, yes. Shouldn't be hard.

> * Implementing the restriction (3) might require change in low-level
> libraries. This is already done in GLib but for proprietary ports like
> macOS/iOS this will be up to Apple to handle it. However gecko and chromium
> developers implemented this, so it seems they could still be done at the web
> engine level?

Well Firefox and Chromium control their own network stack, including their own custom DNS resolution. WebKit uses the system network stack, so improvements necessarily have to happen there first. It's not architecturally possible for WebKit to guarantee (3); instead, we just have to assume that the system network stack implements the behavior we want. Currently that is true for the libsoup backend, but not true for Apple. I'm not sure if it's true for the curl backend, but since we haven't checked to see, we should assume not.

Now, we could modify DNSResolveQueue to resolve localhost ourselves instead of passing that to the system network stack, but that change would only apply to prefetching. WebKit's actual resource loads are still going to use the system network stack, and changing that would not be desirable. So yes, (2) is blocked on Apple, because only Apple can fix (3). We can do (1), though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200720/e101c68f/attachment-0001.htm>