Ports that are blocked by browsers

Summary

Today I was experimenting with a small project using Docker and Flask. I just created two identical services and exposed them on two different ports: nothing fancy. However, to my surprise, only one of the two seemed to be working. The first service was hosted on port 8000. As expected, I could visit localhost:8000 and find the rendered HTML code that I had written. However, the second service hosted on port 6000 wasn’t giving me the same outcome. Instead of showing the HTML code I had prepared, my browser (Chrome) returned this error: This site can’t be reached The web page at http://localhost:6000/ might be temporarily down or it may have moved permanently to a new web address. ERR_UNSAFE_PORT Being curious, I tried to reproduce the issue without Docker, just with the bare minimum setup. I created two webservers using Python’s http.server: $ python -m http.server 8000 $ python -m http.server 6000 The two commands serve an HTTP server on port 8000 and 6000 respectively. And there it is again: while the first webserver works flawlessly, trying to reach the one on port 6000 returns the error described above. So what’s the problem? Cross-protocol scripting Turns out that some ports are explicitly blocked by browsers. This is done in response to the so-called Cross-protocol scripting vulnerability (VU#476267). Through this vulnerability, an attacker could forge malicious HTML code to send data to other services used by the victim (for example crafting spam emails, or printing through a network printer). IMAP, SMTP, NNTP and POP3 are just a small portion of the affected services. Mozilla and other browser vendors fixed this vulnerability by explicitly banning ports that belong to the vulnerable services. This way, when the malicious HTML code tries to send its data, it will basically receive the same error that I received above. What I find confusing is that each browser seems to show (or not show) a different message for the same situation. As we saw above, Chrome show...