Closed Bug 1890701 Opened 11 months ago Closed 7 months ago

(Security hardening) WebSockets or XMLHttpRequests to any local network addresses or localhost addresses from a non-local website should require a permission

Categories

(Core :: Security, enhancement)

Product:
Core
Component:
Security
Version:
Firefox 125
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 354493

People

(Reporter: el, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0

Steps to reproduce:

WebSockets or XMLHttpRequests to any local network addresses or localhost addresses from a non-local website should require an opt-in(!) permission like e.g. accessing the microphone does. It should show a site permission popup and require pressing "Allow", and until then should be either delayed or refused/blocked. The reasons are:

  1. It seems to be frequently abused for port scanning: https://medium.com/@stestagg/stealing-secrets-from-developers-using-websockets-254f98d577a0

  2. It breaks private mode completely, e.g. if you have discord installed and running and visit any discord.com chat server invite link, it'll suddenly notice you and your logged in account even though you're supposedly in private mode, offering to join the server with your account.

  3. There are regularly security holes that can only be abused from the local network, or even localhost. These would be relatively unproblematic for most users if they followed the advise of just not downloading any untrusted programs too easily, until you realize WebSockets rips this door wide open and allow any random website to silently poke any of these at any time. (And the advice of not visiting untrusted websites doesn't work, because by default Firefox loads advertising and advertising is by design loading untrusted content from constantly changing and often shady parties into tons of trusted websites.)

I know WebSockets requires some specific headers to go ahead with the connection and not terminate it again. However, it regularly happens that completely HTTP-unrelated protocols can be somehow tricked into viewing a HTTP request with specific crafted content as part of their own HTTP-unrelated protocol anyway to exploit things. Therefore, this safety mechanism is insufficient to prevent more grave security problems, and it also doesn't stop the basic port scanning which is already bad enough.

Steps to reproduce:

  1. For example, have discord running in the background (the standalone desktop app)
  2. Open a new private window in firefox
  3. Open any discord server invite link in the private window
  4. Suddenly, you'll notice your local discord app reacting even though it should have no way to somehow know in the private window who you are and somehow trace that back to your locally running desktop app that is meant to be completely independent of the web browser. This should require an opt-in permission.

Actual results:

Localhost resources (in this case a socket of the discord web app) is silently accessed even from private tab, although in my opinion this shouldn't be possible even for non-private tabs if it's not from a website with a localhost or local network URL shown in the address bar to start with.

Expected results:

A prompt is shown similar to the microphone access prompt that requires opt-in to access local network or localhost resources.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Component: Widget: Gtk → Security

For what it's worth, I keep telling advanced computer users about this, often programmers, and so far everyone was surprised that this is even allowed by default. It appears to be that not having this be an opt-in permission may not be taken into account by 99% of browser users, which seems like a potential security issue.

Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Duplicate of bug: 354493
Resolution: --- → DUPLICATE

I'm sorry to take up your time, but could you confirm or elaborate why this is a duplicate?

I think my proposal is going further, since I'm suggesting even just localhost and basically anything except public networks should be blocked by default and controlled by an explicit opt-in site permission. I think #354493 concerns itself with "problematic" LAN or localhost access, not all LAN or localhost access of any kind. My apologies if I'm just reading it incorrectly.

Okay, after re-reading it does seem to be a duplicate, just with a different proposed solution. I'll just move my suggestion over in a new comment.

You need to log in before you can comment on or make changes to this bug.