Browsers block many ports, if you move your internal service to an unblocked port, you expose it to every browser in the network! (e.g. a mail server or IRC, something that can be talked to over http.)
Browsers block many ports, if you move your internal service to an unblocked port, you expose it to every browser in the network! (e.g. a mail server or IRC, something that can be talked to over http.)
You could join and spam an IRC server via javascript in the past.
Now if you try it you get something like NS_ERROR_PORT_ACCESS_NOT_ALLOWED.
If you move to a non-standard port javascript can talk to your internal IRC again.
> Anybody that cared to could just use any other software to spam your IRCd.
No they couldn't use other software. They couldn't access the server, cuz they are not inside of the network.
Their javascript is inside the network tho, that's why browsers implement this port blacklist.
Moving an internal app to a non-standard port might expose it to malicious javascript, that's all I'm saying.
Wide open, from within the LAN... not many consider internal apps wide open. Besides browsers, you need actual hacking to reach internal services, a SSRF for example. Or real remote code execution and at that point, you have other problems.
> Counting on browsers to keep your network secure is foolish.
I think what you're saying is: treating the internal network as secure is foolish. That I would agree with.
I never said you should rely on the browsers port banning. It's the other way around, people usually don't even know you can talk to IRC over HTTP and therefore don't even consider it a risk and are protected without even knowing.
My point is not "use port banning as security measure". My point is just: if you move apps to a non-standard port you might expose it to browsers, so better use the standard!
I thought there are even ssh clients that run in javascript in the browser. That wouldn't work if browsers were blocking access to port 22 for outgoing packets/connections.
"This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."
I'm not sure that web browsers are a popular vector for network exploits. Counting on anything client-side is not a wise approach to network security.
I don't know how widespread these kinds of attacks are but they are reasonably well known which is why these port blacklists were implemented in the first place:
https://www-archive.mozilla.org/projects/netlib/portbanning.
I'm up-voting your original comment because it does seem like a potentially valid concern, at least worthy of discussion, and shouldn't be down-voted in my opinion.