On Wed, Aug 18, 2021 at 11:18 PM Matt Menke <[email protected]> wrote:
> On Wed, Aug 18, 2021 at 4:53 PM Yoav Weiss <[email protected]> wrote: > >> >> >> On Wed, Aug 18, 2021 at 8:47 PM 'Matt Menke' via blink-dev < >> [email protected]> wrote: >> >>> Contact [email protected] >>> >>> ExplainerNone >>> >>> Specificationhttps://url.spec.whatwg.org/ >>> >>> Summary >>> >>> Most hostnames that aren't valid IPv4 addresses, but end in numbers are >>> treated as valid, and looked up via DNS (e.g., http://foo.127.1/). Per >>> the Public Suffix List spec, the eTLD+1 of the hostname in that URL should >>> be "127.1". If that is ever fed back into a URLs, "http://127.1/ >>> <http://127.0.0.1/>" is mapped to "http://127.0.0.1/"; by the URL spec, >>> which seems potentially dangerous. "127.0.0.0.1" could also potentially be >>> used to confuse users. We want to reject URLs with these hostnames. >>> >>> >>> Blink componentInternals>Network>DNS >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EDNS> >>> >>> Motivation >>> >>> Most hostnames that aren't valid IPv4 addresses, but end in numbers are >>> treated as valid hostnames, and looked up via DNS. Example hostnames: >>> 127.0.0.0.1, foo.0.1, 10.0.0.09, 08.1.2.3. These can be problematic for the >>> following reason: * "http://foo.127.1/"; has an eTLD+1 of "127.1", per >>> the public suffix list spec. If that's ever used as the hostname in a new >>> URL, however, as in "http://127.1 <http://127.0.0.1/>", it will then >>> get mapped to "http://127.0.0.1/";, per the URL spec, which is a >>> different host, which is not safe. * "http://127.0.0.0.1"; and " >>> http://1.2.3.09";, both of which are looked up via DNS rather than >>> failing or being treated as IPv4 hostnames, also seem potentially >>> confusing. While no exploit is currently known here, we want to remove >>> support for these as a preventative security measure. The URL spec has been >>> updated so that any URL with a hostname ending in a number that's not an >>> IPv4 address (including, e.g., http://foo.1./, but not http://foo.1../) >>> is considered invalid. Since this is part of the URL spec, not the DNS >>> spec, we want to reject these URLs are the GURL layer, for URLs with >>> appropriate protocols (http, https, ws, wss, file). For consistency, we >>> should also fail DNS lookup attempts of these sorts of hostnames. >>> >>> >>> Initial public proposalhttps://github.com/whatwg/url/pull/619 >>> >>> TAG reviewNot required for an Intent to Deprecate, I believe. >>> >>> TAG review statusNot applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> Any URL with an affected hostname will fail to load, and will need to be >>> migrated to another hostname. URLs of this form do appear to be in use, >>> though it's not clear under what circumstances. No entry in the public >>> suffix list is affected. Affected URLs make up no more than 0.0003% of >>> hostnames looked up via the host resolver on any platform, and are >>> basically not used in any file URLs, according to our metrics. >>> >> >> Do we have reason to believe these hostnames are not legitimate ones? >> > > Unfortunately, we have no insight into them - they could be mistyped URLs > sent to typo squatting ISPs that OSX lets through but the Windows host > resolver blocks, and various flavors of Linux treat differently. Or they > could be mapped via a hosts file, or they could be hostnames that only > resolve on public networks. Could be some network tool that uses them when > installed locally, but is only available on certain platforms. No reason > to think one possibility is more likely than the others. > Do we have UKM for them that would enable us to test a random sample? I'm concerned about blocking those hostnames if they are legitimate, as that's something that a web developer can't do anything about. So even if the number of hosts is small, I'd like to get more certainty that they are *not* legitimate hosts before blocking them. > > >> >>> On OSX and Android, about 90% of host resolver lookups for these >>> hostnames succeed, 60% do on Linux, and 2% on Windows and ChromeOS. >>> >> >> Do you know where those failures are coming from? >> > > Could be typos, could be the Windows and ChromeOS host resolvers don't let > them through. Since we've had no filed bugs about them, I suspect the > failures are not deliberate navigations or intended network requests. I'm > much more interested in where the successes are coming from, myself. > > >> >> >>> To allow for emergency disabling in case of wider than expected >>> breakage, I intend to add a feature for it, and do a 50% field trial on >>> pre-release channels, though plan to just enable the feature, rather than >>> do a gradual rollout to stable, given the low usage. >>> >>> >>> Gecko: Positive ( >>> https://github.com/whatwg/url/pull/619#issuecomment-890826499 >>> <https://www.chromestatus.com/admin/features/launch/5679790780579840/1?intent=1> >>> ) >>> >> >> Can you file an official position request? https://bit.ly/blink-signals >> > > Done for Mozilla: > https://github.com/mozilla/standards-positions/issues/568 > > Should I also do this for WebKit as well? They have in process CLs, so > not sure if it's still needed. > Agree that in-flight patches for WebKit are a sufficient positive signal. > > >> >> >>> >>> WebKit: In development (https://bugs.webkit.org/show_bug.cgi?id=228826) >>> >>> Web developers: No signals >>> >>> Activation >>> >>> This breaks anything using one of these domains, and requires migrating >>> to other hostnames. >>> >>> >>> Security >>> >>> None >>> >>> >>> Debuggability >>> >>> These will act like any other invalid URL. Behavior is context >>> dependent. Since this is logic deep within GURL, and GURLs are created in a >>> great many places, console warnings specifically for this seem not >>> practical. >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ?No. Javascript URL construction is tested, but URLs are used in a >>> great many other places, which don't have test coverage, since DNS lookups >>> for these domains must succeed in the first place for the tests to be >>> meaningful. >>> >>> Flag name >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/1237032 >>> >>> Estimated milestones >>> DevTrial on desktop 95 >>> DevTrial on Webview 95 >>> >>> Link to entry on the Chrome Platform Status >>> https://www.chromestatus.com/feature/5679790780579840 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://www.chromestatus.com/>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvq%2Bfnau%3DE%2BONhe0kr9HOpN84eCpoub84%3DswKzPkrGzi5A%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvq%2Bfnau%3DE%2BONhe0kr9HOpN84eCpoub84%3DswKzPkrGzi5A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVtseGpTWUS_Unu9SkAKdqFp7x6Ttk36oYhPipfej0FGA%40mail.gmail.com.
