4 ms·
"hidden img tags to all common gateways (eg 192.168.0.1) are loaded in background onerror/onsuccess events attached to img tags" It has always been a big mista
by _qulr 6y ago
"hidden img tags to all common gateways (eg 192.168.0.1) are loaded in background
onerror/onsuccess events attached to img tags"
It has always been a big mistake for browsers to allow internet pages to make requests to LAN IPs. This has been exploited before: https://www.forcepoint.com/sites/default/files/resources/files/report-attacking-internal-network-en_0.pdf https://www.forcepoint.com/sites/default/files/resources/fil...
- anaphor 6y agoThe mistake is web applications that rely on session cookies alone to authenticate requests. Of course it's not their fault that it's so difficult to secure web apps, but by now this is common knowledge (CSRF/Confused Deputy Attacks). Not allowing browsers to make requests to internal IPs would break many things. We should be moving towards an internet architecture where there is no such distinction anyway.
- viraptor 6y agoThere's still lots of use cases for internet to local communication. Not everything lives in the cloud completely and there will be services which legitimately need to get data from your internal endpoints.
- pseudalopex 6y agoBrowsers use prompts for less dangerous things.
- kortilla 6y agoThere is nothing special here about LAN IPs. This same problem impacts anything that sits behind a firewall that the browser might have access to. A browser has no way to know that a particular IP address is supposed to be sacred and unreachable by other websites. I’ve seen several dashboards hosted externally that load things from internal IP addresses and that design is MEH but it works.
- jeremyjh 6y agoThere absolutely is something special about most of these IPs. There are blocks that are reserved only for use in private networks. IETF standards for IPv4 on this topic have been in place for decades: https://en.wikipedia.org/wiki/Reserved_IP_addresses https://en.wikipedia.org/wiki/Reserved_IP_addresses https://tools.ietf.org/html/rfc1918 https://tools.ietf.org/html/rfc1918
- kortilla 6y agoNo, there isn’t anything special about them from a browser’s perspective. They have been reserved so they can be re-used across private networks without conflicting with routes on the Internet. An address in the rfc1918 space isn’t magic and a shitload of corporate/campus/etc networks depend on treating them just like any other IP address when you load stuff up in a browser. If a page loads a resource from a private address, it can easily be a local cache on the network. It can also be a dashboard like the example I gave you. Example: local.dashboard.example.org resolves to 192.168.255.244 dashboard.example.org resolves to some public address and web server that hosts a page that loads resources from local.dashboard.example.org
- jeremyjh 6y agoHow would we configure our routers if we could not access the router's IP address from a browser?
- _qulr 6y agoThat's not the suggestion. Nobody is suggesting that browsers shouldn't be able to load http://192.168.0.1 http://192.168.0.1 in the address bar. The suggestion is that an http://web.url.com http://web.url.com page should be blocked from making requests to LAN addresses, at least by default. I'm fine with a browser setting for corporate/enterprise users, but most home internet users have no need or desire for web pages that load resources from the LAN.
- necovek 6y agoYou'd be happy to learn that some electronic ID "middleware" (being generous here) rely on the ability to talk to localhost servers (see NexU for instance — https://github.com/nowina-solutions/nexu https://github.com/nowina-solutions/nexu).