7 ms·

These are reasonable security measures, but it does bother me that there's no way around them. I don't use android (or Chrome) so I don't know, but could anyone

These are reasonable security measures, but it does bother me that there's no way around them. I don't use android (or Chrome) so I don't know, but could anyone more knowledgable about these moves chime in about whether it's possible to circumvent them with user permission?

red_trumpet 5y ago
> Starting with Chrome 94, Chrome no longer allows HTTP requests to local IP addresses. What kind of scenario does that prevent?
- jand 5y ago
  Enumeration and more - as far as i understood. My evil website can no longer access the top secret stuff you are developing on localhost. My evil website can no longer enumerate the http servers in your local LAN.
  - franga2000 5y ago
    "This website would like to scan your local network and communicate with other devices" "Allow Once/Deny/Block"
    - wildrhythms 5y ago
      Well maybe I want to grant the site access to a particular internal IP without the ability to send requests everywhere... at what point would Chrome just have its own separate firewall?
      - franga2000 5y ago
        The modern browser is already an operating system by all definitions I know so yes, it might as well have a firewall. But that isn't very elegant, so I propose version 2.0: "This site has requested communication with a local device. Please select it from this list:" [the user is presented with a list of devices discovered by zeroconf/dns-sd/mdns/upnp matching the service descriptor given by the page] Turns out, this was an actual spec [0] pushed by Opera of all companies. Here's a quote from the spec: > window . navigator . getNetworkServices ( type , successCallback [, errorCallback ] ) > > Prompts the user to select discovered network services that have advertised support for the requested service type. > > The type argument contains one or more valid service type tokens that the web page would like to interact with. > > If the user accepts, the successCallback is invoked, with zero or more NetworkService objects as its argument. > > If the user declines, the errorCallback (if any) is invoked. [0] https://www.w3.org/TR/2012/WD-discovery-api-20121004/ https://www.w3.org/TR/2012/WD-discovery-api-20121004/
    - Thorrez 5y ago
      The problem with that is the site the user is on is http:// http:// . Security at that point is pretty iffy. You kind of need to say "foo.com or some MITM attacker pretending to be foo.com wants to scan your local network. Allow Once/Deny/Block". Full disclosure I work at Google, but not on Chrome.
      - franga2000 5y ago
        Of course that would be a problem, but that simply isn't the case. It certainly wasn't the case for Portal or any other site I've seen that used this feature. Limiting this to only secure contexts would solve your problem and is what Google is technically doing. The issue is that requests from HTTPS->HTTP sites in aren't allowed either ("Mixed Content") and so effectively, Chrome is disallowing ALL public->local requests, since HTTPS on a local site is broken by design. > If your website needs to issue requests to a target server on a private IP address, then simply upgrading the initiator website to HTTPS does not work. Mixed Content prevents secure contexts from making requests over plaintext HTTP, so the newly-secured website will still find itself unable to make the requests. The solution, of course, is clear to the Chrome devs - certificate pinning. Unfortunately, they implemented it in an absolutely ridiculous way that limits you to WebTransport for absolutely no other reason other than they want to force developers to use it as soon as possible before the other browser vendors (*vendor) implement it. As I mentioned in a sibling comment, there is absolutely no reason to not simply add a "CACert" option to XHR,fetch,WebSocket... and let developers use the existing protocols.
        Thorrez 5y ago
        >It certainly wasn't the case for Portal or any other site I've seen that used this feature. What do you mean? The only change Chrome is making is limiting it from http:// http:// sites. If Portal is saying Chrome is breaking them, then they must have been making connections from http:// http:// sites. The mixed content limitations have been there for a long time already, which must be why they were using http:// http:// . I've never used Portal myself so I don't have direct evidence they were using http:// http:// , but this is the only logical explanation I can come up with for why they would say Chrome is breaking them. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd...
- tannhaeuser 5y ago
  Wat? Won't Chrome allow this at all (eg when entered via the URL bar, as long as there's one, that is) or just when linked from a non-same domain page?
  - Thorrez 5y ago
    Chrome will allow it. Links will also work from any site. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... I believe the change is that http:// http:// pages on public websites won't be able to talk (such as via XHR/fetch, embedded images/scripts/css) to private IP address or sites with domains that resolve to private IP addresses. One obvious workaround is to change the requesting page to https:// https:// instead of http:// http:// . This is somewhat difficult because then there's the problem of mixed content, since it's often difficult to get an https:// https:// certificate for the server that runs on the private IP address. There are 2 other workarounds listed on the Chrome blog post: WebTransport and and Reverse embedding (which means running the site on a private IP address instead of a public IP address). It looks to me like those could work in the Portal case. Full disclosure I work at Google, but not on Chrome.
- Thorrez 5y ago
  First thing, that quote is wrong. Chrome will still allow HTTP requests to private IP addresses if the site you're on also has a private IP address. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... To answer your question: HTTP is vulnerable to MITM attacks. For example your ISP can modify any page you visit, steal passwords, cookies, oauth tokens, etc. If the site is forced to switch to HTTPS, your ISP can no longer pull off this attack. Full disclosure I work at Google, but not on Chrome.
- zetafunction 5y ago
  From https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... > The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks.

red_trumpet 5y ago

> Starting with Chrome 94, Chrome no longer allows HTTP requests to local IP addresses. What kind of scenario does that prevent?

jand 5y ago
Enumeration and more - as far as i understood. My evil website can no longer access the top secret stuff you are developing on localhost. My evil website can no longer enumerate the http servers in your local LAN.
- franga2000 5y ago
  "This website would like to scan your local network and communicate with other devices" "Allow Once/Deny/Block"
  - wildrhythms 5y ago
    Well maybe I want to grant the site access to a particular internal IP without the ability to send requests everywhere... at what point would Chrome just have its own separate firewall?
    - franga2000 5y ago
      The modern browser is already an operating system by all definitions I know so yes, it might as well have a firewall. But that isn't very elegant, so I propose version 2.0: "This site has requested communication with a local device. Please select it from this list:" [the user is presented with a list of devices discovered by zeroconf/dns-sd/mdns/upnp matching the service descriptor given by the page] Turns out, this was an actual spec [0] pushed by Opera of all companies. Here's a quote from the spec: > window . navigator . getNetworkServices ( type , successCallback [, errorCallback ] ) > > Prompts the user to select discovered network services that have advertised support for the requested service type. > > The type argument contains one or more valid service type tokens that the web page would like to interact with. > > If the user accepts, the successCallback is invoked, with zero or more NetworkService objects as its argument. > > If the user declines, the errorCallback (if any) is invoked. [0] https://www.w3.org/TR/2012/WD-discovery-api-20121004/ https://www.w3.org/TR/2012/WD-discovery-api-20121004/
  - Thorrez 5y ago
    The problem with that is the site the user is on is http:// http:// . Security at that point is pretty iffy. You kind of need to say "foo.com or some MITM attacker pretending to be foo.com wants to scan your local network. Allow Once/Deny/Block". Full disclosure I work at Google, but not on Chrome.
    - franga2000 5y ago
      Of course that would be a problem, but that simply isn't the case. It certainly wasn't the case for Portal or any other site I've seen that used this feature. Limiting this to only secure contexts would solve your problem and is what Google is technically doing. The issue is that requests from HTTPS->HTTP sites in aren't allowed either ("Mixed Content") and so effectively, Chrome is disallowing ALL public->local requests, since HTTPS on a local site is broken by design. > If your website needs to issue requests to a target server on a private IP address, then simply upgrading the initiator website to HTTPS does not work. Mixed Content prevents secure contexts from making requests over plaintext HTTP, so the newly-secured website will still find itself unable to make the requests. The solution, of course, is clear to the Chrome devs - certificate pinning. Unfortunately, they implemented it in an absolutely ridiculous way that limits you to WebTransport for absolutely no other reason other than they want to force developers to use it as soon as possible before the other browser vendors (*vendor) implement it. As I mentioned in a sibling comment, there is absolutely no reason to not simply add a "CACert" option to XHR,fetch,WebSocket... and let developers use the existing protocols.
      - Thorrez 5y ago
        >It certainly wasn't the case for Portal or any other site I've seen that used this feature. What do you mean? The only change Chrome is making is limiting it from http:// http:// sites. If Portal is saying Chrome is breaking them, then they must have been making connections from http:// http:// sites. The mixed content limitations have been there for a long time already, which must be why they were using http:// http:// . I've never used Portal myself so I don't have direct evidence they were using http:// http:// , but this is the only logical explanation I can come up with for why they would say Chrome is breaking them. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd...
tannhaeuser 5y ago
Wat? Won't Chrome allow this at all (eg when entered via the URL bar, as long as there's one, that is) or just when linked from a non-same domain page?
- Thorrez 5y ago
  Chrome will allow it. Links will also work from any site. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... I believe the change is that http:// http:// pages on public websites won't be able to talk (such as via XHR/fetch, embedded images/scripts/css) to private IP address or sites with domains that resolve to private IP addresses. One obvious workaround is to change the requesting page to https:// https:// instead of http:// http:// . This is somewhat difficult because then there's the problem of mixed content, since it's often difficult to get an https:// https:// certificate for the server that runs on the private IP address. There are 2 other workarounds listed on the Chrome blog post: WebTransport and and Reverse embedding (which means running the site on a private IP address instead of a public IP address). It looks to me like those could work in the Portal case. Full disclosure I work at Google, but not on Chrome.
Thorrez 5y ago
First thing, that quote is wrong. Chrome will still allow HTTP requests to private IP addresses if the site you're on also has a private IP address. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... To answer your question: HTTP is vulnerable to MITM attacks. For example your ISP can modify any page you visit, steal passwords, cookies, oauth tokens, etc. If the site is forced to switch to HTTPS, your ISP can no longer pull off this attack. Full disclosure I work at Google, but not on Chrome.
zetafunction 5y ago
From https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... > The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks.