3 ms·

Ports that are blocked by browsers (2023)

48 points by keepamovin 1y ago

Dwedit 1y ago
If you really really need to connect to a server running on a "forbidden port", you can use client-side network forwarding, such as SSH tunnels or Netcat.
- M95D 1y ago
  Or you can set "network.security.ports.banned.override" with a list of ports you want unblocked.
snvzz 1y ago
A glaring omission is listing ports for any browser other than firefox. Do they do the same? Are they the same ports?
- rolph 1y ago
  ports have standardized default usages, this means new or poorly configured installs are prone to abuse, so its generally good to limit these ports in some way. https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbe...
- banana_giraffe 1y ago
  Different ports, here's the list for Chromium: https://github.com/chromium/chromium/blob/76892135714e5b4f162c72b8bb995b54741d637e/net/base/port_util.cc#L35 https://github.com/chromium/chromium/blob/76892135714e5b4f16...
deleted 1y ago
[deleted]
joecool1029 1y ago
I'm surprised IRC wasn't on the list after the IRC flooding incident years ago: https://news.softpedia.com/news/Firefox-Bug-Used-to-Harass-an-Entire-IRC-Network-133613.shtml https://news.softpedia.com/news/Firefox-Bug-Used-to-Harass-a... I guess the concern is targeting local services not remote ones.
- banana_giraffe 1y ago
  Interestingly, they are there: https://github.com/mozilla/gecko-dev/blob/771bc161e016e2bd1f7982a88d387916fdf350dd/netwerk/base/nsIOService.cpp#L117 https://github.com/mozilla/gecko-dev/blob/771bc161e016e2bd1f... (Confirmed on a recent-ish Firefox browser) They look to have been there for at least 5 years, dunno when they were added before that.
wayvey 1y ago
Wow, been a full stack webdev for over a decade and somehow I don't remember ever encountering this. Nice post!
- keepamovin 1y ago
  Yes lol me too! Here’s how I recently found out about it: So I was doing a customer demo, and everything was going great — I was in the middle of showing them how to set up BrowserBox, and I said, “You know, BrowserBox can run on any port, so let’s just pick one. Maybe…” and I just randomly picked one — 9000? I input that, hit run, and opened the login link in the browser, and nothing happened. And I was like, what? So I said, “I’m sure it’s nothing, let’s check the logs.” I checked the logs, and I see this “bad port” error. And I’m like, bad port? What the…? I went down a rabbit hole trying to figure out what was going on — all in the middle of a customer demo. Anyway, I put a pin in it, changed the port, and moved on with the demo. But basically, what happened is: the port for the actual headless Chrome service is always 3000 less than the application port. So in this case, that meant the headless Chrome had been listening on port 6000. Chrome was fine with that. But when I tried to connect to that with Node.js — specifically using undici, the native Node fetch — it refused to connect to port 6000. And somehow, this is the first time after, like you, being a web dev for more than ten years and working on this project for five, that I’d ever encountered that. I can’t believe I never picked port 9000 before in my life! Anyway, I actually find it kind of ridiculous that a server-side library would restrict what I can connect to. So I created a very well-tested shim of fetch — API identical — but based on the http2 and http libraries in Node. It turned out to be this surprisingly impactful thing that I’d never, ever heard about before. And honestly? I think it’s really stupid that the Node.js fetch library has this browser-based restriction.
  - ranger_danger 1y ago
    I remember it explicitly, but I have been in webdev since the 90s, and using alternate ports was more common back then. One of the original vulns for this was reported in 2001. https://www.kb.cert.org/vuls/id/476267 https://www.kb.cert.org/vuls/id/476267

48 points by keepamovin 1y ago

If you really really need to connect to a server running on a "forbidden port", you can use client-side network forwarding, such as SSH tunnels or Netcat.

M95D 1y ago
Or you can set "network.security.ports.banned.override" with a list of ports you want unblocked.

snvzz 1y ago

A glaring omission is listing ports for any browser other than firefox. Do they do the same? Are they the same ports?

rolph 1y ago
ports have standardized default usages, this means new or poorly configured installs are prone to abuse, so its generally good to limit these ports in some way. https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbe...
banana_giraffe 1y ago
Different ports, here's the list for Chromium: https://github.com/chromium/chromium/blob/76892135714e5b4f162c72b8bb995b54741d637e/net/base/port_util.cc#L35 https://github.com/chromium/chromium/blob/76892135714e5b4f16...

deleted 1y ago

[deleted]

joecool1029 1y ago

I'm surprised IRC wasn't on the list after the IRC flooding incident years ago: https://news.softpedia.com/news/Firefox-Bug-Used-to-Harass-an-Entire-IRC-Network-133613.shtml https://news.softpedia.com/news/Firefox-Bug-Used-to-Harass-a... I guess the concern is targeting local services not remote ones.

banana_giraffe 1y ago
Interestingly, they are there: https://github.com/mozilla/gecko-dev/blob/771bc161e016e2bd1f7982a88d387916fdf350dd/netwerk/base/nsIOService.cpp#L117 https://github.com/mozilla/gecko-dev/blob/771bc161e016e2bd1f... (Confirmed on a recent-ish Firefox browser) They look to have been there for at least 5 years, dunno when they were added before that.

wayvey 1y ago

Wow, been a full stack webdev for over a decade and somehow I don't remember ever encountering this. Nice post!

keepamovin 1y ago
Yes lol me too! Here’s how I recently found out about it: So I was doing a customer demo, and everything was going great — I was in the middle of showing them how to set up BrowserBox, and I said, “You know, BrowserBox can run on any port, so let’s just pick one. Maybe…” and I just randomly picked one — 9000? I input that, hit run, and opened the login link in the browser, and nothing happened. And I was like, what? So I said, “I’m sure it’s nothing, let’s check the logs.” I checked the logs, and I see this “bad port” error. And I’m like, bad port? What the…? I went down a rabbit hole trying to figure out what was going on — all in the middle of a customer demo. Anyway, I put a pin in it, changed the port, and moved on with the demo. But basically, what happened is: the port for the actual headless Chrome service is always 3000 less than the application port. So in this case, that meant the headless Chrome had been listening on port 6000. Chrome was fine with that. But when I tried to connect to that with Node.js — specifically using undici, the native Node fetch — it refused to connect to port 6000. And somehow, this is the first time after, like you, being a web dev for more than ten years and working on this project for five, that I’d ever encountered that. I can’t believe I never picked port 9000 before in my life! Anyway, I actually find it kind of ridiculous that a server-side library would restrict what I can connect to. So I created a very well-tested shim of fetch — API identical — but based on the http2 and http libraries in Node. It turned out to be this surprisingly impactful thing that I’d never, ever heard about before. And honestly? I think it’s really stupid that the Node.js fetch library has this browser-based restriction.
- ranger_danger 1y ago
  I remember it explicitly, but I have been in webdev since the 90s, and using alternate ports was more common back then. One of the original vulns for this was reported in 2001. https://www.kb.cert.org/vuls/id/476267 https://www.kb.cert.org/vuls/id/476267