5 ms·

This seems mostly benign, basically changing the default cross-boundary behavior from "allow" to "deny" but also providing a way for intranet devices to exclude

This seems mostly benign, basically changing the default cross-boundary behavior from "allow" to "deny" but also providing a way for intranet devices to exclude themselves. On the other hand I'm also not a huge fan of these measures because they address the issue from the wrong end. Servers should protect themselves from CSRF, it shouldn't be the job of browsers to do that. A server (think router or IoT device) shouldn't be like: Hey I'm getting an internal IP anyways so I'm going to be lax. With this there's now no motivation to fix anything from the server/device side so you have failure modes where someone's using a weird/old browser that doesn't preflight and they're vulnerable but everyone still has a false sense of security... Additionally, I'm worried that rather than adopt the whole preflight/headers thing, a lazy org might decide to just repurpose some reserved public IP space for their internal private addressing so things don't "cross-bounds" anymore...It basically becomes unusable security that's circumvented like writing your password on a sticky because it's forced to be really complex. Never underestimate the ability for someone to blow through any and all security or safety measures if they prevent them from doing something that they could do before...

cygx 5y ago
As far as I'm concerned, this change is long overdue: Browsers should never have granted arbitrary websites the ability to port scan your local machine and network. Note that Opera came with cross network protections a decade ago, cf https://web.archive.org/web/20121001002815/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20121001002815/http://my.opera.c...
- jabbany 5y ago
  Scanning is not allowed anyways just from standard cross-origin protections. If intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. It's the same reason you cannot embed an Ajax request in your blog to query someone's bank account's API. In order for information to be made available to the external site, the service has to cooperate with the remote site already. In fact, even CSRF is mostly due to the server misusing HTTP. Look at the example in the W3C doc, where the remote site has a hidden frame/resource that hits local servers. Well guess what, GET requests should not change state, so changing some DNS configuration via a GET request is already doing it wrong. There's no inherent reason an intranet site should be treated any differently from an Internet site. At best the current argument is that "intranet sites are more likely to be hacky and poorly implemented", but that should reflect more on those devices/services on the intranet than anything else.
  - cygx 5y ago
    If intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. You use connection timing for that, cf https://nullsweep.com/why-is-this-website-port-scanning-me/ https://nullsweep.com/why-is-this-website-port-scanning-me/
    - jabbany 5y ago
      Again, not an issue with local network vs Internet. You can do the same fingerprinting to check for connection ability against Internet sites too... If anything this is a bug with WebSockets and its cross-origin implementation. The existing cross-origin request specs already specify that there should not be information being leaked about the target resource unless cross-origin was allowed. Iframes don't let you time how long the thing inside loads anymore, img also stopped making this available, same for things like AJAX, and so should it be for websockets too. If indeed the only information the scan is gleaning is based on timing then it's no different from the other JS timing attacks (some of the early ones could expose arbitrary slices of ram!)--- it's a bug and should be fixed as such. When you say doing private/public IP filtering is to fix this kind of issue, then what's really being said is "I still want websockets fingerprinting and port scanning to _work_, just not with any internal network IPs".
southerntofu 5y ago
> Servers should protect themselves from CSRF, it shouldn't be the job of browsers to do that. I personally strongly disagree with this point. I believe a web browser tab should only communicate with one network location, and 3rd party content/requests should be disabled overall. This way we would have a much saner and user-respecting web. So sure i should be able to click a link to turn off my lights using a local address (although why the fuck would i have IoT in the first place? humanity would be better off if IoT just died), but a remote website should not be able to control what i do with other locations without my explicit consent.
marcosdumay 5y ago
> Servers should protect themselves from CSRF, it shouldn't be the job of browsers to do that. You mean that servers are the ones supposed to protect themselves from 3rd parties commandeering the browser to act like the browser acts when you are using it? I fail to see how that's the correct way to solve the problem. Doing it on the server just ensures that you'll get an ever growing pile of hacks and never really solve the problem.
- jabbany 5y ago
  Because the protections already exist. The existing same-origin policies already offer sufficient protections for "not having the browser commandeered". The only reason this exists is because bad _local network_ implementations are _common_, not that they cannot be made secure just like those on the Internet. The example in the W3C doc (https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/) to justify this is an instance of a broken server implementation. It's using a GET request to set some value even when GET should not have side effects. It's a common vulnerability but its totally the server's fault here. If you have your pants down at home and someone happens to see you naked through your window, it's on you. The solution should be to close your curtains, not "make everyone wear glasses that automatically blur any open windows".

cygx 5y ago

As far as I'm concerned, this change is long overdue: Browsers should never have granted arbitrary websites the ability to port scan your local machine and network. Note that Opera came with cross network protections a decade ago, cf https://web.archive.org/web/20121001002815/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20121001002815/http://my.opera.c...

jabbany 5y ago
Scanning is not allowed anyways just from standard cross-origin protections. If intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. It's the same reason you cannot embed an Ajax request in your blog to query someone's bank account's API. In order for information to be made available to the external site, the service has to cooperate with the remote site already. In fact, even CSRF is mostly due to the server misusing HTTP. Look at the example in the W3C doc, where the remote site has a hidden frame/resource that hits local servers. Well guess what, GET requests should not change state, so changing some DNS configuration via a GET request is already doing it wrong. There's no inherent reason an intranet site should be treated any differently from an Internet site. At best the current argument is that "intranet sites are more likely to be hacky and poorly implemented", but that should reflect more on those devices/services on the intranet than anything else.
- cygx 5y ago
  If intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. You use connection timing for that, cf https://nullsweep.com/why-is-this-website-port-scanning-me/ https://nullsweep.com/why-is-this-website-port-scanning-me/
  - jabbany 5y ago
    Again, not an issue with local network vs Internet. You can do the same fingerprinting to check for connection ability against Internet sites too... If anything this is a bug with WebSockets and its cross-origin implementation. The existing cross-origin request specs already specify that there should not be information being leaked about the target resource unless cross-origin was allowed. Iframes don't let you time how long the thing inside loads anymore, img also stopped making this available, same for things like AJAX, and so should it be for websockets too. If indeed the only information the scan is gleaning is based on timing then it's no different from the other JS timing attacks (some of the early ones could expose arbitrary slices of ram!)--- it's a bug and should be fixed as such. When you say doing private/public IP filtering is to fix this kind of issue, then what's really being said is "I still want websockets fingerprinting and port scanning to _work_, just not with any internal network IPs".

southerntofu 5y ago

> Servers should protect themselves from CSRF, it shouldn't be the job of browsers to do that. I personally strongly disagree with this point. I believe a web browser tab should only communicate with one network location, and 3rd party content/requests should be disabled overall. This way we would have a much saner and user-respecting web. So sure i should be able to click a link to turn off my lights using a local address (although why the fuck would i have IoT in the first place? humanity would be better off if IoT just died), but a remote website should not be able to control what i do with other locations without my explicit consent.

marcosdumay 5y ago

> Servers should protect themselves from CSRF, it shouldn't be the job of browsers to do that. You mean that servers are the ones supposed to protect themselves from 3rd parties commandeering the browser to act like the browser acts when you are using it? I fail to see how that's the correct way to solve the problem. Doing it on the server just ensures that you'll get an ever growing pile of hacks and never really solve the problem.

jabbany 5y ago
Because the protections already exist. The existing same-origin policies already offer sufficient protections for "not having the browser commandeered". The only reason this exists is because bad _local network_ implementations are _common_, not that they cannot be made secure just like those on the Internet. The example in the W3C doc (https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/) to justify this is an instance of a broken server implementation. It's using a GET request to set some value even when GET should not have side effects. It's a common vulnerability but its totally the server's fault here. If you have your pants down at home and someone happens to see you naked through your window, it's on you. The solution should be to close your curtains, not "make everyone wear glasses that automatically blur any open windows".