Letting websites talk to software that runs locally is quite dangerous, and probably never a legitimate use of web technology. 1. Local software is likely to have poor security settings, such as weak passwords. It doesn't even have to recognize HTTP to be vulnerable, as cross-protocol attacks do exist. 2. Often, such software is a proxy for hardware (see e.g. Arduino request in <https://bugs.webkit.org/show_bug.cgi?id=171934#c18>). That increases the risk. 3. Knowledge of locally running services can be used for fingerprinting. 4. For https pages in particular, talking to an unknown party on a local machine only identified by a port number violates page security too. See bug 171934 for more discussion.
<rdar://problem/40601596>
>https://bugs.webkit.org/show_bug.cgi?id=171934 You have a thread full of people, me including, who do need to talk to local software. With clear root CA risk that it leads to. You have the bug, the use cases and the risk of current solution. Yet you fail to see them and somehow conclude for made up reason that "those are not worthy"? Not something i would expect from people dealing with web standards.
Egor, you keep iterating on how much you want this, and how this used to work for a long time, so several developers came to rely on this feature. No one is going to ignore that. However, user security and privacy is the primary consideration by far. Also, not sure which CA root risk you are talking about in this context. This issue is about completely blocking loopback access, not about mixed content.
> Also, not sure which CA root risk you are talking about in this context I've clicked the wrong link, the response belongs to https://bugs.webkit.org/show_bug.cgi?id=171934 >and how this used to work for a long time, so several developers came to rely on this feature. Used to and still perfectly works in all other browsers. I wouldn't post it here if Safari wasn't the only one violating the spec. Why do we have to develop for different browsers with different code strategy? Wasn't the shared spec created exactly to avoid that? >However, user security and privacy is the primary consideration by far. And here's what hit my nerve the most. Look, I know a thing or two about web security and threat model of the web (look up track record on sakurity.com) and there is nothing wrong for a web page to talk to localhost *when localhost wants it*. PS. You could've made a good argument mentioning DNS rebinding (RCE in rails/redis) but you didn't. And DNS rebinding is considered a vulnerability in a localhost service, not the browser.
> there is nothing wrong for a web page to talk to localhost *when localhost wants it*. How does one determine the intent? I definitely have a bunch of services listening on loopback that are one parsing bug away from being a problem, and that I very much do not want to be accessed by webpages. One can think of having an explicit opt-in (process registering its loopback port for access from a specific web origin). That mitigates some of the concerns, but clearly not all of them. Either way, given that all of this is a gross architectural violation of web technology, developing tons of infrastructure around it seems like a poor strategy. > You could've made a good argument mentioning DNS rebinding DNS rebinding certainly helps some of the these attacks as one doesn't need to deal with CORS, sure. > And DNS rebinding is considered a vulnerability in a localhost service, not the browser. Blaming a multitude of services and people configuring them instead of a single choke point is probably why DNS rebinding remains an unresolved problem :)
Perhaps we should consider a Develop menu item to allow 127.0.0.1 for developers that have a need to enable it? This would keep things secure for the 99% of users that don’t need that interface exposed.
> How does one determine the intent? That was my first answer in 171934, literally: > That's kind of true, but why not just open up localhost that opts-in to be accessed? Preflight? I agreed that there are bugs that can happen, but offered to consider CORS preflight or any other way to re-enable localhost bridge back. Any header like Allow-Localhost: 1 would show the intent too. Or crossdomain.xml-style sharing as well. >developing tons of infrastructure around it seems like a poor strategy. With CORS approach I doubt you would increase code complexity. Violating the spec, on another hand, does increase code complexity for the developers and pushes to root CA options. > Blaming a multitude of services and people I too believe DNS rebinding could have been solving decades ago in web standards, but complete prohibition of localhost is unacceptable. It will push people to send data from the web page<->server<->localhost listener which is next level ugly and slow. Bottom line: A direct bridge from page to localhost is very useful and enables whole range of use cases. There are multiple low-overhead ways for localhost to show the intent to be talked to, from CORS to flags and special headers: choose whatever you like. I do not like the Developer Console option as it complicates things for normal users who just want e.g. local Spotify daemon to work.
I'm adding another request to please follow the web standards on this. Especially now that Edge has fixed this and will be pushing it out soon. Chrome, Firefox, and Edge all follow the web standard. As a developer with a legitimate use of web technology, it is beyond frustrating to see you go against the web standard. This leaves me with two options... 1: Go the self-signed certificate route. This results in my installer asking to install a certificate and for the user to trust it. This then results in them getting their IT security teams involved, multiple phone calls going back and forth on why it is okay to install the certificate, and other headaches. 2: Write my code to handle things differently on OSX/Windows. Users on Chrome/Firefox/Edge on Windows will not need the certificate. Users on Safari will. Neither of these options is acceptable. Both of these options are completely avoidable by following web standards. At this point I don't know what else to do other than strongly suggest that our customers don't use WebKit based browsers.
(In reply to ctclements from comment #8) > 1: Go the self-signed certificate route. This results in my installer > asking to install a certificate and for the user to trust it. This then > results in them getting their IT security teams involved, multiple phone > calls going back and forth on why it is okay to install the certificate, and > other headaches. I doubt IT departments are excited about you running invalidated server software on their corporate machines. Installing a certificate is a very low bar in comparison.
(In reply to Brent Fulgham from comment #9) > I doubt IT departments are excited about you running invalidated server > software on their corporate machines. Installing a certificate is a very low > bar in comparison. So far, no issues there. Is there a way that self-signing a certificate and installing it makes make my server software any more or less validated? Irregardless of my specific use case, the point is that 3/4 relevant (in my industry) browsers are following the spec. There is a reason we have web specifications. Not following the specification ends up in odd cases like this where we either have to write more code to accomadate the one browser that doesn't follow the other 3, or simply tell customers we don't support the browser.
(In reply to ctclements from comment #10) > (In reply to Brent Fulgham from comment #9) > > I doubt IT departments are excited about you running invalidated server > > software on their corporate machines. Installing a certificate is a very low > > bar in comparison. > > So far, no issues there. Is there a way that self-signing a certificate and > installing it makes make my server software any more or less validated? This makes it seem like the security aspects of your 'solution' are being hidden from the IT department, because your installer likely does not explicitly mention a new web-accessible service is being activated. The Certificate requirement (and the admin authentication required) is triggering action on behalf of the IT department, which is exactly the right thing to be happening. I.e., your "So far, no issues there." just means that in the security risk being introduced is hidden from all parties, while the Certificate activation requirement forces someone to think about what's happening.
(In reply to Brent Fulgham from comment #11) > This makes it seem like the security aspects of your 'solution' are being > hidden from the IT department, because your installer likely does not > explicitly mention a new web-accessible service is being activated. The > Certificate requirement (and the admin authentication required) is > triggering action on behalf of the IT department, which is exactly the right > thing to be happening. > > I.e., your "So far, no issues there." just means that in the security risk > being introduced is hidden from all parties, while the Certificate > activation requirement forces someone to think about what's happening. While it may seem to appear that way over the course of a handful of quickly typed paragraphs, I can assure you that our users (or really their IT departments) are aware of what they are installing in this case. That is all irrelevant though. The point here is that developers need to know if WebKit will follow the w3c specs or not. If WebKit will not follow them here, what else will they not follow them on?
Which standard are you talking about? Web browsers block dangerous resource loads all the time for all kinds of reasons. This one is not much different from blocking file: URLs loads from remote webpages, for example.
(In reply to Alexey Proskuryakov from comment #13) > Which standard are you talking about? Web browsers block dangerous resource > loads all the time for all kinds of reasons. This one is not much different > from blocking file: URLs loads from remote webpages, for example. The first comment on https://bugs.webkit.org/show_bug.cgi?id=171934 shows the w3c spec. It also shows the Chrome and Firefox takes on the issue. Here is the Edge link as well - https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11963735/ If WebKit refuses to match Chrome/Firefox/Edge, that is of course your decision, but surely you can see the headache this causes developers when one browser doesn't follow the others. If you truly believe this is a legitimate security concern, please reach out to the other teams so that we can arrive at a consensus. It doesn't benefit anyone to have browsers doing different things in this aspect.
That bug and the referenced spec are about mixed content handling. That's not a normative reference for what is under discussion here. The idea here is to block all loopback subresource loads from actual web pages, regardless of whether those are http or https. > please reach out to the other teams so that we can arrive at a consensus. It doesn't benefit anyone to have browsers doing different things in this aspect. WebKit is deeply committed to interoperability. Depending on the details of the final solution, it may be more or less suitable for coordination with other vendors. Changes that are primarily in browser UI (e.g. how https certificates are displayed in address bar) are generally made by browser vendors unilaterally. But that would be outside the scope of this WebKit bug anyway, as each browser that embeds WebKit makes its own decisions.
This issue of blocking localhost as well as not allowing mixed content is completely blocking Safari from multiple important use cases. The IoT field and the fintech/payments field are full of use cases for talking to localhost. Example: a point of sale running in the browser needs to talk to a server on localhost to send a payment request to a terminal on the network. Everything on the web being https nowadays, the browser needs to be able to talk to a http service on the machine. Self-signed certificates are non-sense in this context. I fail to understand the rationale to block localhost here. - Developers are giving you valid use cases - It's in the spec - Other browsers implement it - There are no workarounds If there were credible attacks based on this feature, you'd see Chrome and Firefox users being attacked left and right. This is not the case. Can we please allow this so that the Web doesn't take a step backwards, and so that we don't have to tell our users "oh you need to use Chrome or Firefox, this doesn't work on Safari". There's a spec - don't be an IE6 developer.
(In reply to antoine from comment #16) > This issue of blocking localhost as well as not allowing mixed content is > completely blocking Safari from multiple important use cases. Uses cases like Zoom, RingCentral, and Zhumu? :-P
https://wicg.github.io/private-network-access/ is related to this, and about reducing the ability for public sites to communicate with private/local IPs (requiring them to explicitly opt-in).