4 ms·

Yes, it's possible localhost servers can have security issues, but: * This only affects servers that do indeed serve the "anybody can talk to me" CORS headers.

Yes, it's possible localhost servers can have security issues, but: * This only affects servers that do indeed serve the "anybody can talk to me" CORS headers. For anything else, standard cross-origin restrictions apply. A simple localhost server that has ignored this issue and isn't aware of CORS at all is generally not vulnerable. * This change doesn't actually increase this risk, it decreases it! Localhost requests from pages were already allowed, CORS notwithstanding, it was just not possible from HTTPS sites as it was mixed content. * This is a pretty common pattern for lots of popular software that has a desktop component - e.g. Spotify, Zoom - so there's a clear use case for it. * There's ongoing work to restrict this further, see https://web.dev/cors-rfc1918-feedback/ https://web.dev/cors-rfc1918-feedback/, proposed by the Chrome team. In short, HTTPS will be required, and a new `Access-Control-Request-Private-Network: true` header will be sent (and an `Access-Control-Allow-Private-Network: true` response required) to force servers to opt in to any requests that cross from public origins to private ones.

est31 6y ago
> This only affects servers that do indeed serve the "anybody can talk to me" CORS headers. Again, even if these CORS headers are not sent, the browser still does a request to the server in order to find out whether the headers are being sent. Check running python3 -m http.server in your terminal, and then do var v = fetch("http://localhost:8000/hellllllo http://localhost:8000/hellllllo") in your browser's console. You will get a big red CORS error in the console, because the builtin python http server does not send these headers. But the web server will still receive and respond to the "hellllllo" GET request! It will show up in your terminal's log. For some insecure servers, getting a specifically crafted request might be enough to exploit security bugs. Like I said, take a server that has a limited size buffer for the URL after which it overflows letting you write data to whatever is beyond that on the stack. > This change doesn't actually increase this risk Alright you have a point here, but it's still bad this feature exists in the first place. > This is a pretty common pattern for lots of popular software that has a desktop component Because it's used doesn't mean it's a bad idea. > There's ongoing work to restrict this further Huh that's very nice. Indeed this would resolve my concerns: In the future, whenever a public website is trying to fetch resources from a private or a local network, Chrome will send a preflight request before the actual request. Preflight requests are hardcoded and barely have any attacker controlled data (except for the ip address maybe, as 127.0.0.2 is as valid as 127.0.0.1).
bigbubba 6y ago
> This only affects servers that do indeed serve the "anybody can talk to me" CORS headers. That's simply not true, it can effect things that aren't even web servers at all: https://en.wikipedia.org/wiki/Inter-protocol_exploitation https://en.wikipedia.org/wiki/Inter-protocol_exploitation

est31 6y ago

> This only affects servers that do indeed serve the "anybody can talk to me" CORS headers. Again, even if these CORS headers are not sent, the browser still does a request to the server in order to find out whether the headers are being sent. Check running python3 -m http.server in your terminal, and then do var v = fetch("http://localhost:8000/hellllllo http://localhost:8000/hellllllo") in your browser's console. You will get a big red CORS error in the console, because the builtin python http server does not send these headers. But the web server will still receive and respond to the "hellllllo" GET request! It will show up in your terminal's log. For some insecure servers, getting a specifically crafted request might be enough to exploit security bugs. Like I said, take a server that has a limited size buffer for the URL after which it overflows letting you write data to whatever is beyond that on the stack. > This change doesn't actually increase this risk Alright you have a point here, but it's still bad this feature exists in the first place. > This is a pretty common pattern for lots of popular software that has a desktop component Because it's used doesn't mean it's a bad idea. > There's ongoing work to restrict this further Huh that's very nice. Indeed this would resolve my concerns: In the future, whenever a public website is trying to fetch resources from a private or a local network, Chrome will send a preflight request before the actual request. Preflight requests are hardcoded and barely have any attacker controlled data (except for the ip address maybe, as 127.0.0.2 is as valid as 127.0.0.1).

bigbubba 6y ago

> This only affects servers that do indeed serve the "anybody can talk to me" CORS headers. That's simply not true, it can effect things that aren't even web servers at all: https://en.wikipedia.org/wiki/Inter-protocol_exploitation https://en.wikipedia.org/wiki/Inter-protocol_exploitation