Interesting, thanks for the report. We do indeed strip userinfo for security display in HTTP URLs, and this does bypass that protection. 

We are currently considering changing the display of Filesystem URIs for display, and should also resolve this issue.

Deleted: UserInfoNotStripped.png 15.0 KB

	UserInfoNotStripped.png 15.0 KB View Download

If we choose to mitigate this directly, I think we need to adjust 

components/url_formatter/url_formatter.cc's  FormatUrlWithAdjustments such that if (format_types & kFormatUrlOmitUsernamePassword && url.SchemeIsFileSystem()) we also strip out the userinfo embedded in the inner URL.

Having said that, I think we're leaning toward forbidding userinfo in HTTP(S) URIs entirely (as some other browsers do) and I suspect that we could ban construction of filesystem URIs with embedded HTTP userinfo with no real-world compatibility impact.

Also related: Bug 714339

Can an Enamel person make sure what platforms this happens on, and also assign the bug to themselves? :)

This would seem to be a High, per the severity guidelines. https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md "Complete control over the apparent origin in the omnibox", depending on how liberally we interpret that. (I.e. do we reasonably expect people to notice that the apparent origin is light gray text. I'd think no, hence High.) If I'm wrong, please feel free to change it.

Assigning to Mustafa, since he already owns bug 714339.

OS-All sounds about right, filesystem scheme shouldn't be OS specific.

palmer: I'd argue this is different from the example given in the severity guidelines ( bug 76666 ). Even an attentive user wouldn't be able to tell the difference with that bug, whereas this one requires them to not notice that the whole URL is grayed out and that there is a "Not Secure" warning.

I agree with #7 that this seems like a Medium at worst, but I will note that you can suppress the explicit "Not Secure" warning by running your attack from a HTTPS URI.

+rbyers,jsbell for bug visibility

Dropping severity per #7 and #8.

As a fix, we are considering blocking content-initiated top-frame navigations to filesystem URLs.

I have a pending CL that will strip userinfo from filesystem: URLs at the GURL level (during canonicalization): https://chromium-review.googlesource.com/c/chromium/src/+/974380

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff69a10a306f029b25759e78e0c3cc98a3fa840c

commit ff69a10a306f029b25759e78e0c3cc98a3fa840c
Author: Nick Carter <nick@chromium.org>
Date: Wed Apr 04 00:15:17 2018

[GURL] (2 of 2) Strip username/password/port when canonicalizing, if the scheme doesn't support them

The goal of this CL is to inhibit port numbers and usernames in internal schemes
like "chrome-extension" and "chrome". Currently, navigations to chrome-extension:// URLs
with ports actually get suprisingly far; it seems like no good can possibly come from
that.

A new SchemeType is added: SCHEME_WITH_HOST_AND_PORT (no user information).
This is only used when canonicalizing the inner URL of filesystem: -- e.g.,
filesystem:http://user@host:20/temp/foo now canonicalizes to
filesystem:http://host:20/temp/foo; whereas filesystem:chrome://user@host:20/temp/foo
canonicalizes to filesystem:chrome://host/temp/foo

Bug: 606001, 809062 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I77c5ba3d2fe964deb8aadae95a06519ce038c472
Reviewed-on: https://chromium-review.googlesource.com/974380
Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org>
Reviewed-by: Tommy Li <tommycli@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Nick Carter <nick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547882}
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/components/password_manager/core/browser/android_affiliation/affiliation_utils.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/components/url_formatter/url_fixer_unittest.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/gurl_unittest.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/scheme_host_port.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_canon.h
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_canon_filesystemurl.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_canon_relative.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_canon_stdurl.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_canon_unittest.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_util.cc
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_util.h
[modify] https://crrev.com/ff69a10a306f029b25759e78e0c3cc98a3fa840c/url/url_util_unittest.cc

I believe that r547882 effectively fixes this issue. As it's an invasive change to GURL canonicalization, it's probably not a great merge candidate given the M66 timeline, but let me know if a solution in M66 is important.

I believe this is duplicate of  Issue 696446 .

Yes, this is a duplicate. Merging into  Issue 696446  and also dropping view restrictions since the other bug has been open for over a year.