[Proposal] Per-application (per-port) permission for loopback access

[ylemkimon]

Currently, local (loopback after #17) permission grants access to all applications on localhost. This has two problems:

• It's not clear to users what application the page is requesting access to. This makes it hard for web sites to convince users to grant the permission, and users cannot make an informed decision and may just click "Allow" if they get tired of it.
• Once granted, the page has full access to all loopback applications. This can be abused to fingerprint the device or exploit vulnerabilities.

I think per-application (per-port) permission for loopback access would be beneficial for both web sites and users.

This could be implemented in a similar manner to PWA installation. The application serves a manifest on the root or a .well-known path, and when the page requests a permission it shows a dialog like:

**Grant local app access**
[Origin] would like to connect to the following application and other local applications listening on port 3000.

[Icon] [Name]
127.0.0.1:3000

From the app
[Description]

[Allow] [Deny]

The security and privacy implications would be minimal, as an application can already display a pop-up, access browser data, and access the local network.

[tresf]

Similar to:

• Provide a mechanism for whitelisting #38

... quoting:

• "In my case, simply allowing IP|HOSTNAME:PORT would be perfect; I find this to be a good compromise for apps, since they'd only be allowing a single port through.
• I'd even be ok with a small "hey, this website is using LNA" indicator in the address bar, similar to how sites playing audio or sites with insecure connections appear."

[MicahZoltu]

I think this is quite important. There are services I may run locally, particularly peer to peer services like a blockchain client or a P2P file storage gateway like IPFS and I would like websites to be able to utilize those services both for performance and privacy reasons. However, I don't want those same websites to be able to port scan my host and see all of the servers I am running, which would both be a privacy problem and a security problem because many locally running services aren't security hardened (e.g., random dev server I'm running in the background).

In addition to the .well-known suggestion above, one could imagine apps being able to register themselves with the OS or local browsers during installation so that the prompt can give the user a clear query rather than a vague one. "Example.com would like to connect to your local Minecraft server." is a lot more comforting than "Example.com would like to connect to all services running on your device."

[larseggert]

"Example.com would like to connect to your local Minecraft server." is a lot more comforting than "Example.com would like to connect to all services running on your device."

We discussed this, but this won't work. Because I would make my malware say "Mozilla recommends you allow this."

[MicahZoltu]

If the malware is already can register a port handler and listen on a port, I feel like your computer is already compromised far more than a website being able to connect to that port would allow.

Is there some sort of attack escalation that opens up by allowing applications to register as local port handlers?

[tresf]

If the malware is already can register a port handler and listen on a port, I feel like your computer is already compromised far more than a website being able to connect to that port would allow.

Hmm... I think you're misinterpreting @larseggert's comments which are more around control of the wording. The moment the browser allows a good actor to provide a comforting message, malware will masquerade as the same. The only way to avoid this would be digitally signing the message -- which I'd be happy to help test and/or prototype -- but still could suffer a replay attack or fall subject to a sandbox limitation preventing any reasonable validation.

I think we need to focus on the whitelist in general, as wording would then be suppressed completely and no longer a factor for spoofing.

However, I don't want those same websites to be able to port scan my host and see all of the servers I am running,

This is a FANTASTIC use-case for PORT-ONLY whitelisting!

[MicahZoltu]

Perhaps my suggestion wasn't clear. I'm suggesting that the wording come from the app on the device that registered the port handler with the OS or browser. I fully agree that the website should NOT be able to supply their own wording.

[tresf]

Perhaps my suggestion wasn't clear. I'm suggesting that the wording come from the app on the device that registered the port handler with the OS or browser. I fully agree that the website should NOT be able to supply their own wording.

It's clear, but without explanation of how this will work, it'll be a bunch of PayPal and Bank Of America spoofs, so you'll have to be more specific. I don't think what you're describing is technically possible, but I'm all ears.

[ylemkimon]

@larseggert

We discussed this, but this won't work. Because I would make my malware say "Mozilla recommends you allow this."

I agree that displaying untrustworthy content in the browser's chrome is generally a bad idea. But wouldn't an application that can bind to the loopback interface already have the capability to draw over the chrome?

Now I think, the capability to bind a socket and the capability to access the compositor are not the same, especially with Wayland and UWP. But I still think it's important to let the user know which application the page is requesting access to.

[tresf]

But wouldn't an application that can bind to the loopback interface already have the capability to draw over the chrome?

Yeah, that's what my app does, but we do this for security/courtesy reasons. I believe most apps won't and AFAIK there's no way to enforce this.

[MicahZoltu]

1. User installs OS.
2. User installs Chrome.
3. User installs SomeApp.
4. During SomeApp installation, SomeApp registers itself with the OS or Chrome (similar to how an app registers as a protocol handler) as an app that is serving content at port 12345, and as part of that registration it provides its name: SomeApp.
5. User navigates to https://example.com that wants to access port 12345.
6. User receives a permission prompt:

   example.com would like to communicate with SomeApp running on your device (http://localhost:12345). Allow | Deny

7. User clicks Allow.
8. example.com now can make requests to http://localhost:12345
   I believe on Windows you need write access to the Registry in order to register a protocol handler, though there may be a way to do it with less permissions. I'm not sure how protocol handler registration works on OSX/Linux.

If someone navigates to https://paypal.ru, they would get a prompt:

paypal.ru would like to communicate with SomeApp running on your device (http://localhost:12345)

If someone installs PayPalApp on their device and then they navigate to https://example.com, they will get a prompt:

example.com would like to communicate with PayPalApp running on your device (http://localhost:12345)

There is nothing that Chrome can do to stop the user from installing PayPalApp, nor is there anything Chrome can do to stop the user from navigating to https://paypal.ru (at least not in the context of this specification). In the context of this specification, all Chrome can do is decide what to present in the permission prompt. Displaying only the port would not protect the user from anything here because they already have PayPalApp installed on their device and/or they have already navigated to https://paypal.ru.

[tresf]

all Chrome can do is decide what to present in the permission prompt. Displaying only the port would not protect the user from anything here because they already have PayPalApp installed on their device and/or they have already navigated to

What I think you're missing here is that the browser is taking the app name from the URI registration on the OS, and no such app name entry exists for port numbers that I'm aware of.

I'm not sure how protocol handler registration works on OSX/Linux.

Here's what URI protocol registration looks like across Desktop platforms (click to expand)

In this case, the value "QZ Tray" is fetched from the following locations:

• macOS: Info.plist

  <key>CFBundleURLTypes</key>
  <array>
      <dict>
          <key>CFBundleURLName</key>
          <string>QZ Tray</string>
          <!--    ^--- HERE -->
          <key>CFBundleURLSchemes</key>
          <array><string>qz</string></array>
          <!--           ^--- HERE -->
      </dict>
  </array>

• Linux: /usr/share/applications/qz-tray.desktop

  [Desktop Entry]
  Type=Application
  Name=QZ Tray   # <--- HERE
  Exec="/opt/qz-tray/qz-tray" %u
  Path=/opt/qz-tray
  Icon=/opt/qz-tray/qz-tray.svg
  MimeType=application/x-qz;x-scheme-handler/qz;  # <--- HERE
  Terminal=false

• Windows: HKCR

  Windows Registry Editor Version 5.00
  
  [HKEY_CLASSES_ROOT\qz\shell\open\command]
  ;                  ^--- HERE
  @="\"C:\\Program Files\\QZ Tray\\qz-tray.exe\" \"%1\""

  • Slightly unrelated -- and perhaps a skill issue -- but on Windows, my app does NOT actually show "QZ Tray" but rather qz-tray.exe in the pop-up dialog. Edit: Figured it out, Chrome uses the FriendlyApplicationName, taken from the exe's properties.

So when I ask "explanation of how this will work", I mean technically.

• How will the browser know you which port is assigned to the app?

TL;DR (click to expand)

... so what you're proposing -- which BTW, I don't disagree with from a usability perspective -- currently offers no universal registration mechanism, so asking the browser to present an app name for a given port, there's no universal standard in place means the browser either has to do one of the following: 1. Roll its own validation (how?) or 2. Roll it's own registration (how?) or 3. Use some complex predictive or assumptive technique (how?) -- to definitively bind (like the above URI registration standards bind) an app name to a port.

Explaining the workflow that the user sees is mostly irrelevant without a technical method for registration and AFAIU, it's this idea of "port registration" that's missing/unknown currently.

[MicahZoltu]

I see the confusion now. I'm proposing this specification specify a mechanism by which applications on the device can register with the browser or OS. I am not suggesting that this mechanism already exists. This would be akin to (2) in your list I believe.

This is not an impossible standardization task, as it has been done for protocol handlers in the past, and I would imagine following a similar pattern would be a good place to start. In an ideal world, the OS would play an active role (like it does with protocol handlers). Barring that though, I think every desktop OS has a mechanism for host-wide cross-app data sharing (registry in Windows, various config files in Linux, not sure on OSX).

Note: In your example above, I believe that at least on Windows there is a mapping of protocol -> handler in the registry as well, so an app (like a browser) can look up the handler given only the protocol. That is what would be needed for ports as well, since the browser has a port and it needs to then "find" what app is (allegedly) listening on that port.

---

The more we discuss this though, the more your suggestion for .well-known has grown on me as an elegant solution. The primary disadvantage of that solution is that every service would need to serve HTTP requests at the designated port, which could get complicated if you are serving some other protocol.

[tresf]

This is not an impossible standardization task

No, but getting all (Windows, macOS, Linux ... etc) to agree on system-wide app:port assignments is a near-impossible feat. I think there's a bit of "it was done, it can be done" rhetoric here, but it's my impression that browsers have historically been at the mercy of the OS in this regard. Taking URI registration as an example:

• Windows 95 / Internet Explorer 3.0 (e.g. mailto:)
• Linux: XDG Utils / ~2006-2010
• macOS: Launch Services / ~2001

... so by the time a browser such a Chrome came along, these were already well-established.

I think every desktop OS has a mechanism for host-wide cross-app data sharing (registry in Windows, various config files in Linux, not sure on OSX).

I've shared three standards that I use on the Desktop in my reply above (reg, plist and desktop file). While it's true that all three locations can theoretically store new, arbitrary information to share with an app, it's rather optimistic to believe they will. Furthemore, the idea of an app requesting information directly from another app is often frowned upon so OS standards are often preferred instead. That said, if we can get buy-in by the Chromium or Firefox teams to use these locations for browser-specific data, I would be very happy as an app author, I'm already writing to these locations.

the more your suggestion for .well-known

For clarity, that was ylemkimon's proposal. 🍻