[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 #4 from Birunthan Mohanathas <birunthan at mohanathas.com> ---
(In reply to Alexey Proskuryakov from comment #1)
> We should consider blocking cross origin access to localhost completely,
> it's a pretty terrible security risk.

That would be in violation of the spec. Also note that Chrome and Firefox
Nightly allow cross origin access to 127.0.0.1 and ::1 from both HTTP and
HTTPS sites.

(In reply to Alexey Proskuryakov from comment #3)
> This opens up any service listening to connections on loopback interfaces to
> attacks of any kind. A web page can exploit request parsing bugs, or it can
> exfiltrate data that was meant to only be made available to a loopback
> counterpart.

These are valid concerns, but please note that there are legitimate use cases
localhost access. The Chromium commit message from comment 0 describes the
what people have been forced to do for these legitimate cases:

> Currently, mixed content checks block http://127.0.0.1 from loading in a
> page delivered over TLS. I'm (belatedly) coming around to the idea that
> that restriction does more harm than good. In particular, I'll note that
> folks are installing new trusted roots and self-signing certs for that
> IP address, exposing themselves to additional risk for minimal benefit.
> Helpful locally installed software is doing the same, with even more
> associated risk.

Also see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=607878

I think a better path forward would be to allow cross origin access to
127.0.0.1 and ::1 only if the loopback server sends back the CORS headers
(i.e. Access-Control-Allow-Origin) even over HTTP.

-- 
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/20170511/e1107c01/attachment.html>