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? > 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? > 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 > > 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/CAL5BFfWSBPXrO6M2P4vY0agDsoM95Nebp4OT7G3Ft30qucjKuw%40mail.gmail.com.
