4 ms·

How do you differentiate between a valid and invalid request to localhost / the LAN? Lots of websites will link to something like `http://localhost:9200` http:

How do you differentiate between a valid and invalid request to localhost / the LAN? Lots of websites will link to something like `http://localhost:9200` http://localhost:9200` (e.g. Elasticsearch) in the documentation. So you decide to make it impossible to load that page in the context of a page loaded from a public IP address. Great. What is stopping them from tricking you into clicking it (or filling out a fake form), which is basically the same thing? You haven't really solved the problem. You've just made it slightly more difficult. The solution is: a) fix your applications so that they do not expose unsafe endpoints that can cause unintended side-effects merely by navigating to them b) stop using session cookies (at least stop using them alone) to authenticate actions. Use token-based authentication (like CSRF tokens) Edit: and before you say "check the referer header!", no, that will not solve the problem. The bad web page can simply not include the referer with something like `rel="noreferrer"`

pmontra 7y ago
> How do you differentiate between a valid and invalid request to localhost / the LAN? With the same origin policy? I think the post advocates for something like allowing localhost and private IP addresses only from those very same addresses or from the URL bar. Any other page shouldn't be able to access them. This will probably break something but what's the case for a web app to legitimately access local host? Maybe access to some local service installed by the user and managed "from the cloud".
- anaphor 7y ago
  Define "access". The SOP does not stop a page from initiating a request to any other origin, it stops it from interacting with it, so that, e.g. attacker.com cannot steal your session cookies from banking.com You can do all kinds of things that don't violate the SOP but initiate a request: - Link to another site - Redirect someone to another page using Javascript - Link an image from another site - Put a form that submits data to another site - Embed video/audio from another site - Embed an iframe from another site Do you propose disallowing all of those things? There are plenty of legitimate use cases for all of these things. If you wanted to do this you would have to disallow any type of links to local servers.
  - anaphor 7y ago
    Also, like someone already mentioned. DNS rebinding is a thing. So the SOP can be subverted under certain circumstances (browsers will do DNS pinning to protect against this but it's not a perfect solution)
  - SahAssar 7y ago
    Every one of those are solved by CSP/X-Frame-Options headers, CORS headers with content-type (non-normal form content-types) checks and proper handling of HTTP Methods. DNS rebinding is solved by https, and if you are doing something sensitive over a network (even a local one) I'm going to assume https is the proper way. We have ways of handling these things, they just require a bit of reading/implementation and are unfortunately non-default.
    - anaphor 7y ago
      Which is sort of exactly my point. There is no need to have a blanket ban on any linking between local/non-local sites. You just need to make sure they are set up to handle requests securely.
bpfrh 7y ago
I think a good idea would be to at least let the user confirm it. For example display a notification: "This website wants to interact with devices in your network, if your are at home, this includes all of your smart things, smart phones and other devices". I mean, we have a windows firewall and sandboxing on every level and then a webrowser suddenly acts as a vpn for every website? That can't be good security design
- anaphor 7y ago
  A confirmation might be helpful, yes. I think the challenge is to design a standard for that which won't completely flood people with warnings. I'm sure there are some "enterprise" applications that will load a ton of different resources from different services on an internal network. So would you have to click a confirmation box for every single one? Or would there be a way for administrators to disable it somehow?
  - bpfrh 7y ago
    No of course not. I would give one blanket permission for a website. Then if possible list the devices which it connected to. Or you alllow it only per device.

pmontra 7y ago

> How do you differentiate between a valid and invalid request to localhost / the LAN? With the same origin policy? I think the post advocates for something like allowing localhost and private IP addresses only from those very same addresses or from the URL bar. Any other page shouldn't be able to access them. This will probably break something but what's the case for a web app to legitimately access local host? Maybe access to some local service installed by the user and managed "from the cloud".

anaphor 7y ago
Define "access". The SOP does not stop a page from initiating a request to any other origin, it stops it from interacting with it, so that, e.g. attacker.com cannot steal your session cookies from banking.com You can do all kinds of things that don't violate the SOP but initiate a request: - Link to another site - Redirect someone to another page using Javascript - Link an image from another site - Put a form that submits data to another site - Embed video/audio from another site - Embed an iframe from another site Do you propose disallowing all of those things? There are plenty of legitimate use cases for all of these things. If you wanted to do this you would have to disallow any type of links to local servers.
- anaphor 7y ago
  Also, like someone already mentioned. DNS rebinding is a thing. So the SOP can be subverted under certain circumstances (browsers will do DNS pinning to protect against this but it's not a perfect solution)
- SahAssar 7y ago
  Every one of those are solved by CSP/X-Frame-Options headers, CORS headers with content-type (non-normal form content-types) checks and proper handling of HTTP Methods. DNS rebinding is solved by https, and if you are doing something sensitive over a network (even a local one) I'm going to assume https is the proper way. We have ways of handling these things, they just require a bit of reading/implementation and are unfortunately non-default.
  - anaphor 7y ago
    Which is sort of exactly my point. There is no need to have a blanket ban on any linking between local/non-local sites. You just need to make sure they are set up to handle requests securely.

bpfrh 7y ago

I think a good idea would be to at least let the user confirm it. For example display a notification: "This website wants to interact with devices in your network, if your are at home, this includes all of your smart things, smart phones and other devices". I mean, we have a windows firewall and sandboxing on every level and then a webrowser suddenly acts as a vpn for every website? That can't be good security design

anaphor 7y ago
A confirmation might be helpful, yes. I think the challenge is to design a standard for that which won't completely flood people with warnings. I'm sure there are some "enterprise" applications that will load a ton of different resources from different services on an internal network. So would you have to click a confirmation box for every single one? Or would there be a way for administrators to disable it somehow?
- bpfrh 7y ago
  No of course not. I would give one blanket permission for a website. Then if possible list the devices which it connected to. Or you alllow it only per device.