3 ms·

By default, browsers do block sites from doing dangerous things to other sites, like sending authenticated API requests; they only let by stuff that is supposed

By default, browsers do block sites from doing dangerous things to other sites, like sending authenticated API requests; they only let by stuff that is supposed to be harmless, like hotlinking images. And then they have a mechanism called CORS that lets those services say "this particular site can make API requests and such". The problem is that Zoom, since they didn't understand CORS, and yet did want to allow their site to make API requests, turned what should have been an harmless action (GET an image) into a dangerous one. Browsers could block everything, but all I think would happen is that Zoom would just find some other silly (and potentially more dangerous) way of doing the same thing, because they want the site to be able to talk to the service. If you're writing your own service to be used on an internal network, you don't need a VPN or anything. Just don't accept unauthenticated requests that make changes, and ignore CORS.

eric_h 7y ago
> Just don't accept unauthenticated requests that make changes, and ignore CORS. The problem here is that it’s really pretty trivial to scan a local network and get valuable metadata about the router and other devices on the network, just using JavaScript and xmlhttprequest. It’s not that the local services are at risk of being exploited, but the whole (average, unhardened home-) network could be compromised by identifying devices with known exploits and, well, exploiting them. Now I’m trying to come up with a non-PITA way of isolating browsing from my local network while still allowing direct access to my local network!
- danShumway 7y ago
  > Now I’m trying to come up with a non-PITA way of isolating browsing from my local network while still allowing direct access to my local network! UMatrix will protect you from most of this (with the exception of DNS rebind attacks). I don't necessarily disagree with people who are frustrated that their browser can do this, but I also think it's completely reasonable to make it easy for browsers to send requests on an intranet. There are multiple devices in my house that wouldn't work with that capability. The "problem", to the extent that there is a problem, is that securing these devices relies on developers doing the right thing -- and developers are untrustworthy. Theoretically, it would be better to put users in control. But that's not a specific problem with Intranet requests, that's a problem with CORS in general as it applies to the entire Internet.
  - wool_gather 7y ago
    > it's completely reasonable to make it easy for browsers to send requests on an intranet Agree. But shouldn't we distinguish a request that originates from the local user's input into the browser from one that originates from a remote entity? I'm slightly ignorant here; maybe this isn't technically possible?

eric_h 7y ago

> Just don't accept unauthenticated requests that make changes, and ignore CORS. The problem here is that it’s really pretty trivial to scan a local network and get valuable metadata about the router and other devices on the network, just using JavaScript and xmlhttprequest. It’s not that the local services are at risk of being exploited, but the whole (average, unhardened home-) network could be compromised by identifying devices with known exploits and, well, exploiting them. Now I’m trying to come up with a non-PITA way of isolating browsing from my local network while still allowing direct access to my local network!

danShumway 7y ago
> Now I’m trying to come up with a non-PITA way of isolating browsing from my local network while still allowing direct access to my local network! UMatrix will protect you from most of this (with the exception of DNS rebind attacks). I don't necessarily disagree with people who are frustrated that their browser can do this, but I also think it's completely reasonable to make it easy for browsers to send requests on an intranet. There are multiple devices in my house that wouldn't work with that capability. The "problem", to the extent that there is a problem, is that securing these devices relies on developers doing the right thing -- and developers are untrustworthy. Theoretically, it would be better to put users in control. But that's not a specific problem with Intranet requests, that's a problem with CORS in general as it applies to the entire Internet.
- wool_gather 7y ago
  > it's completely reasonable to make it easy for browsers to send requests on an intranet Agree. But shouldn't we distinguish a request that originates from the local user's input into the browser from one that originates from a remote entity? I'm slightly ignorant here; maybe this isn't technically possible?