dangerous interaction with application-level protocol sniffing in routers

[thejh]

APIs that allow attackers to connect to attacker-owned servers on arbitrary low ports are dangerous because such connections may be interpreted by routers/firewalls that attempt to enable reverse connections on dynamic, separate ports by sniffing application traffic.

This is why Flash banned traffic to low ports to fix CVE-2017-2938.

For an illustration of how much an attack might look, see e.g. https://samy.pl/slipstream/.

[trusktr]

Is this suggesting that web developers should not be trusted to write secure code, so we should stop the Raw Sockets proposal? It's the same problem any non-web app author has, right?

Do you have a proposal on how to improve it to make it more secure for web developers, other than canceling the API?

This API would be extremely useful and helpful for a wide variety of cases.

[cameron-martin]

Is this suggesting that web developers should not be trusted to write secure code, so we should stop the Raw Sockets proposal?

No, it's suggesting that an attacker can intentionally write insecure code and as a result access arbitrary ports on the client.

[nhairs]

The way I conceptualise it is that we are breaking the contract of the Web Browser in that the Web Browser is a heavily protected sandbox for accessing webpages. This also means that we rely on the browser to protect us against potentially malicious code being run by web pages by keeping it inside the sandbox.

Part of the reason we have killed off ActiveX, Java, Flash, etc over the years is that they consistently broke this contract and made web browsing dangerous for users.

That's not to say our current situation is perfect, even when restricted to webpages, there is ample opportunity to attack internal services via HTTP.

I don't think alerts / pop ups / warnings / etc are the way forward here either, most major web browsers have resorted to essentially hiding the "ignore" option from their giant red warning pages to stop people blindly clicking through them and getting attacked. This functionality doesn't seem like it would benefit majority of web users and exposing it to them may increase the chances they click through any warning box because they "just want the website to work". In the event that it does become mainstream raises real questions about why we are allowing websites to invent their own standards for communications when browsers exist for the standardisation that is HTTP etc.

On the flip side, I definitely see the advantages of using web browsers as a distribution mechanism and GUI platform for general software (which is what we are basically enabling by providing these lower level features), and it would be interesting to see it used as such. But I don't think we should be catering to the needs of those with more advanced use-cases at the cost of the security of majority of users who just want to be able to browse websites.

One way forward perhaps would be to make it a configuration option that must be enabled in the first place. On the other hand as I type this, I can already foresee websites showing "please enable this feature" banners to get users to bypass this step. See also: every macro enabled phishing document.

(This comment should potentially live on #1 rather than here >_>)