Issue metadata
Sign in to add a comment
|
Basic Authentication in URLs is effectively broken
Reported by
k...@luminance.org,
Jun 12 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 Example URL: Steps to reproduce the problem: 1. Visit a page using basic authentication with the credentials in the URL that has embedded resources, i.e. http://u:p@localhost/ What is the expected behavior? Subresources should load What went wrong? Subresources fail to load because Chrome maps all relative URLs like <img src="foo.png"> to "http://u:p@localhost/foo.png", which is blocked by the new "fix" for issue 435547 that was not implemented correctly. Did this work before? Yes 58.x.x.x, immediately before the 59.0.3071.86 update installed Chrome version: Version 59.0.3071.86 (Official Build) (64-bit) Channel: stable OS Version: 10.0 Flash Version: This effectively breaks basic authentication scenarios unless you make the user enter the credentials themselves. I use this for local developer tools and testing (i.e. selenium) setups (literally connecting to 127.0.0.1 or localhost) in order to avoid the user having to manually enter the u/p. Without the basic auth anyone on the local network would be able to access the tools just by port scanning, which is not great. The 435547 fix is reasonable in principle but you've just broken basic auth completely, as far as I can tell. At least if you whitelisted localhost or allowed opting-in with CORS, this would be okay. It also makes very little sense that the page itself loads but the subresources do not - if you're really going to break basic auth, just break it completely so users don't get confused. Supposedly https://bugs.chromium.org/p/chromium/issues/detail?id=504300 whitelists basic auth in XHR but that also does not work anymore.
,
Jun 12 2017
,
Jun 12 2017
This is deliberate, so I assume this will be WontFixed. See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/lx-U_JR2BF0
,
Jun 12 2017
The announcement said that subresources with inline u/p would be disabled. The subresources in this case are relative URLs, as stated in the bug report. This behavior was not described in the announcement, and given the stated intent to whitelist XHRs, seems the opposite of intent. It just seems like basic auth was not tested at all before this was rolled out.
,
Jun 12 2017
1. We do indeed intend to limit basic auth to user-entered values, assuming that actual numbers line up with what use counters are telling us. 2. I agree that we shouldn't do that until we also block top-level navigation, which we haven't done yet. So, duping this against https://crbug.com/731618 which has a patch out for review.
,
Jun 12 2017
Ah, sorry for the dupe. That looked like it was about autocomplete?
,
Jun 12 2017
Yeah. I think they meant "completion of relative URLs" as opposed to "autocomplete", but it's describing the same issue you're raising here. In any case, I expect https://chromium-review.googlesource.com/c/530308 to resolve the issue once it's reviewed and lands.
,
Jun 12 2017
(Also, with regard to basic auth in Selenium, I'd suggest skimming through https://wicg.github.io/cors-rfc1918/ which intends to address the attack vector you've identified. Ideally, that mitigation would remove the necessity for basic auth in this particular use case.) |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by k...@luminance.org
, Jun 12 201747.0 KB
47.0 KB View Download