[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

Maciej Stachowiak <mjs at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |mjs at apple.com
         Resolution|WONTFIX                     |---

--- Comment #36 from Maciej Stachowiak <mjs at apple.com> ---
(In reply to youenn fablet from comment #28)
> It is unclear to me why we relate mixed content checks with localhost access.
> Attacks to localhost servers are currently easy to do no matter mixed
> content or not, I do not see what protection we get there.

Let's think through this. The mixed content policy is meant to protect users from being misled into thinking they are interacting with a secure page with content from a known source, but effectively it's not, because non-https content could have been tampered with in transit. We don't want to give users a false sense of security in this case. It might not be safe to type a credit card number or a password on such a page.

The suggested risks of any access from remote pages to the loopback address are:
(1) Pages could exploit local web services that weren't meant to be accessed from an untrusted source.
(2) Trojan software could install a trap version of a local web service that aims to exploit the page making use of it.

It seems to me these threats are not properly addressed by a failed mixed content check (which would either result in an insecure indicator or a failed resource load if the referring page is http:). The first attack could be performed from an http: page, or in any case the page performing it may not care about an "insecure" warning in the location field. By the time that shows up, the attack has likely already happened, and users would not expect "insecure" to put them on notice of this. A rogue service as in (2) could still exploit pages that deploy any of the many workarounds for this limitation. Furthermore, if malware can run an http server, it cn probably do other malicious things locally to interfere with the integrity of websites.

So while it may make sense to consider limitations for remote access to local web servers, holding out on this tweak to the mixed content rules does not fulfill the purpose of mixed content rules, nor does it properly mitigate the attacks.

Therefore reopening because I think this was closed based on an incorrect rationale.


> As for web sites that get data from localhost, they are doing the requests
> so they should know what the security model is.
> 
> Some workarounds:
> - Self signed certificates :(
> - Deliver the web site through HTTP :(
> - Make the connection between browser and localhost server go through a
> proxy: HTTPS/WSS/WebRTC. The localhost server would need to keep a
> connection with this proxy so that it is available or it should be 'waken
> up' by making the browser navigating to it.
> 
> We should think of the best way to protect Web apps/WebKit apps from these
> attacks (and probably LAN server access in general). Maybe an opt-in or
> content blockers could help there.
> It is reasonable to think that some WebKit applications will want to allow
> access to 127.0.0.1 and for good reasons. I do not see why mixed content
> checks should interfere with such apps.
> 
> Aligning with the spec makes sense to me at this point.

-- 
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/20190124/98300cbb/attachment-0001.html>