Massive security concerns

[marcoscaceres]

So, there is clearly going to be massive security concerns with this API... as there has been with every attempt to do this in the past (e.g., https://github.com/sysapps/tcp-udp-sockets ... to Web Sockets themselves). Before we even start on this, it might be worth having a call with various folks around how feasible it is to even attempt this API.

[rvklein]

Something like would completely break the security model(s) of the web. Just thinking about it is giving me a headache. Attempting to implement anything remotely similar to the idea proposed here without numerous massive security concerns would be a nightmare.

[ckmaresca]

It is generally a bad idea and extremely undesirable to implement any protocol in a modern system (particularly a consumer focused application with widespread use) that is natively plain text with zero secure channels (e.g. TCP & UDP). While the intention may be noble - with 30 years in tech (and 4 years on a red team), I have learned that it is beyond naive to think that a malicious someone won't exploit this for evil. There is a reason why TCP & UDP are largely avoided except for IPC, particularly in consumer devices. I would only point to all the building management systems exploits (specifically Niagara) from a few years ago as an object lesson in avoiding unencrypted channels.+

If you believe in ethical computing, then avoiding implementing things that have highly negative blowback is something you should strive for.... Fundamentally, implementing this is a moral/political question, not a technical one.

+ https://www.cyberscoop.com/fox-protocol-fbi-warning-port-1911-ics-security/

[elansys-kc]

https://github.com/WICG/raw-sockets/issues/23#issuecomment-683276427

"I'm not sure blocking MDNS makes sense. There is far more danger in the proposal than allowing multicast on multicast ports to help the user allow a connection without internet access?

It would make far more security sense in my mind to only allow MDNS and a specific TCP port to be used by the browser and so developers would need to consciously decide to allow browsers to communicate with their devices.

There is far more danger in allowing connections to existing printers than MDNS over MDNS ports! Especially when printing support is already good in browsers and networks.

Perhaps any port could be allowed to the internet but only specific ports locally?"

[plinss]

The TAG reviewed this proposal and has largely the same concerns. Our feedback: https://github.com/w3ctag/design-reviews/issues/548#issuecomment-697793427

[hober]

Has there been any progress on this issue in the last year+?

[phoglenix]

As noted in #35 this is partially implemented in Chrome but is currently blocked on increased security features to support it.

[uasan]

Perhaps a reasonable compromise would be to only allow the use of raw sockets if the page is running like the installed PWA application?

[phoglenix]

Although apps on many platforms can open sockets freely, we do not think being installed/running as a PWA is a sufficient security mitigation for web apps. As noted above, this API would be a significant departure from the security model of the web.

[kevlar700]

It isn't clear what "more secure-context" means. I would suggest that if the browser is executed in such a way as to ONLY execute a particular already installed PWA, then that would be much more App like and more secure than the web model.

[uasan]

When installing the PWA, we must provide the user with UI, which will contain a list of permissions that the application needs, the user can refuse to install or not give the desired permission, the same practice is in mobile applications

[kevlar700]

PWAs run automatically. I don't think any PWA should get raw socket access even if it asks for permission. Unless a user has knowingly executed an app icon. This would also bring an opportunity to decouple from DNS that requires online connections for apps to run.

[extremeheat]

This is indeed very unsafe. None of the security mitigations listed in the explainer seem to actually solve anything, but trying to apply duck-tape to fix a leaking ship. "CORS bypass? Block 443, problem solved"... "Internal network access? Just block some subnets"...

Normal users are never to be trusted ; many people are not tech-literate enough to understand what a socket is, they just see a prompt and realize they need to connect to something. And many will blindly do as you say. When an attacker controls the DNS, you can't even be sure where the request is going to end up. Even more dangerous is the "Remember" feature which allows presumably unrestricted access on that website. Saying "access to only this hostname" is totally useless. Why? Because a malicious actor can easily control the DNS.

Don't get me wrong, this is a very cool feature and I'm sure many people would love to see sockets in the browser to remove needing to download external tools like communication clients (IRC, matrix, etc), terminal access, printers, special server protocols and other things. But the vast majority of these use cases can already be covered through browser extensions, or well known and trusted native applications. As is said, "the web is the wild west"... once a feature is out there in the wild, there is nothing that can be done about malicious websites or abusive actors. Even trusted websites can abuse browser features. But this feature in specific exposes more risk to the user than arguably any other browser feature.

Users can be used for denial of service attacks, be used to sniff local networks (rotating DNS), and connect to any service regardless of whether the server wants to accept web requests or not (there is no UA for raw sockets). If this feature were to be released, you can expect to see new websites claiming to allow you to access X service from your browser. Users will enter their credentials and who knows what happens from there--a malicious actor can steal credentials or anything all the while everything seems transparently OK to you. It's a lot worse than normal phishing which is mostly blocked via CORS to the extent that it's possible.

Some website or service (e.g. advertising) gets hacked, and they can now ask the user to connect to any TCP/UDP server they want, regardless of frame, script, and CORS protection. Or more scary, targeted attacks at individuals to transparently access internal network services.

Conversely, introducing security mitigations by restricting features or the conditions they can be used in also lessens the utility of having such an API in the first place.

[uasan]

browser extensions, or well known and trusted native applications

or PWA?

[stiiin]

What has been done to address the response of the TAG (w3ctag/design-reviews#548)?

[phoglenix]

As noted in #35 this is currently blocked on increased security features to support it. Those security features would hopefully address the issues raised by the TAG. Sorry for being vague but I don't think any more info is publicly available. I'll try to remember to update #35 if anything relevant is announced.

[lifaon74]

It may not be the most pertinent comment but I'll try my best:

I would love to see more powerful features in the browser, including direct socket, and I thing that security threats should not be an obstacle to the development of new, ever more innovative and powerful apps.

Users ARE already fooled and tricked by phishing, fake links, they download an run unknown softwares and applications, and even when warnings are prompted, they often bypass them, etc... and on the other side, attackers always find alternatives to circumvent the limits and security put in place. always has been and always will be. It's the far west, and the most advanced users will always be one step ahead.

However, I don't say we should do nothing to protect users, I only say that it should not stop us to develop cool features.

So, to mitigate such a functionality, we may imagine a Content-Security-Policy that enables direct sockets instead of disabling it (this way all the existing websites won't be affected, and direct sockets are disable by default), we may think about prompt with a red background indicating a dangerous feature, and a red logo on the search bar (just like non secure websites), etc... there is plenty of solutions, and we should use them instead of stoping such a great project.

[jdspugh]

So, there is clearly going to be massive security concerns with this API... as there has been with every attempt to do this in the past (e.g., https://github.com/sysapps/tcp-udp-sockets ... to Web Sockets themselves). Before we even start on this, it might be worth having a call with various folks around how feasible it is to even attempt this API.

I can see the API with the link. Are there any references to the problems they encountered?

[james-smith-a8e6]

From the IWA explainer, it seems that IWAs would be installed in basically the same ways as native apps currently are:

Once bundled, an application could be distributed to users in a number of ways:

• A raw signed Web Bundle.
• Packaged into a platform-specific installation format such as an APK, MSI or DMG.
• Distributed through an operating system, browser or third-party “app store”.
• Automatically installed by enterprise system configuration management infrastructure.

In fact one of the motivations given for IWAs is as an alternative to Electron:

When Chrome Apps were deprecated, they chose to move their application to the Electron framework and accept the increase the download size and complexity of their application rather than put their users at risk.

Native apps can open direct sockets, so I don't see why IWAs, assuming the installation process is the same as native apps, should have any additional restrictions.

[phoglenix]

You're correct. IWAs encompass the "increased security features" that are intended to allow Direct Sockets and other powerful APIs to become available to the (packaged, isolated) web.