I've attached a minimized POC.

Deleted: spoof.html 145 bytes

spoof.html 145 bytes View Download

Deleted: spoof2.html 92 bytes

spoof2.html 92 bytes View Download

There's definitely some weird behavior here, but I don't see an omnibox URL spoof in either the video or when repro'ing locally.

I don't see any spoof either. Please file a new bug providing a reproduction case that shows either the url or content being spoofed.

#2,3 I guess I didn't get my point across. The content displayed in the video under https://api.stripe.com is all attacker-controlled. I created a fake page of the stripe website and used in this PoC. The HTML files attached in comment 1 doesn't spoof the content for simplicity's sake (but it's possible to see how the spoof works from it). By the way, repro'ing from https://lbherrera.github.io/lab/stripe.html didn't work? I tested on two different machines running Windows.

* I've also attached the minimized PoC that spoofs the content

Deleted: spoof.html 145 bytes

spoof.html 145 bytes View Download

Deleted: spoof2.html 358 bytes

spoof2.html 358 bytes View Download

Reactivating per #3.

aarya: Let's please not close bugs immediately even if there is no obvious vulnerability. There might still be something worth investigating, as is the case here :)

What's happening is:
1- Tab 1 opens an auth dialog from api.stripe.com when the link is clicked.
2- Tab 2 contains contents of api.stripe.com. When the user types api.stripe.com, a new auth dialog should be displayed, but somehow the navigation hangs (probably because there is already an auth dialog over tab #1). At this point, the attacker's page switches to displaying spoofed stripe.com contents.

#6: Also, if we only open one auth dialog on Tab 1 the navigation hangs for roughly 20 seconds. By opening 6 auth dialogs inside iframes on Tab 1 the navigation hangs until one of the 6 dialogs gets closed (allowing the spoof to last longer). My guess is that there's a limit to how many of them can be displayed at one given moment.

Eric, can you please help with an owner for this.

@creis: Can you verify my analysis below? Thanks!

Thanks for the report! If I am understanding the report properly, I would rephrase its concern as:

=====
Say you start on site A, but then initiate a navigation to site B:

At this point while the load is in progress, the URL box displays the address for site B, however, the rendered page content is still that of site A (and remains interactive).

This means a user could be fooled into thinking they are interacting with site B during the load, while in fact they are still interacting with site A (which is attacker controlled). The attacker can make this more convincing by changing the content of their page to resemble site B once the navigation request begins (by hooking onbeforeunload and other such techniques).
=====

This is a general problem with the web page loading model, and not specific to HTTP auth (the mechanism used in these repros to control the speed of site loads).


@creis: Can you comment on the security model for loading, and whether it is desirable to keep the disconnect between URL box and content? I am tentatively closing this as working as intended, since the lock for HTTPS at least didn't show until the load committed with the new content (which is consistent with our UI story).

Lastly regarding HTTP-auth: this bug is not really about HTTP auth. The way the repro works is by opening 6 instances of a slow loading site (it is slow to load because it blocks in HTTP auth dialog). This in turn saturates the socket pool, which has a limited number of open sockets it will allow per origin. Once saturated, the final load for the new origin stalls at the socket pool layer waiting for a free socket, rather than stalling at the HTTP auth dialog. A similar repro can be achieved without the use of HTTP auth, so that is not a requirement (you just need to slow down the page load enough so the attacker's content remains displayed).

This is a really nice report.  And at first, it does seem like a very convincing spoof, which makes me want to do something about it.  eroman@ may be right, though, at least from a navigation perspective.  Maybe there's something to explore from the UX side, though?

More details:

The HTTP auth interstitial problem shown here is basically due to issue 6697, where subsequent visits to a URL blocked by an interstitial will hang until the interstitial is dismissed.  estark@ has some plans to refactor interstitials so that they will be committed error pages instead of overlays that block navigation, and I think there's still some open questions about HTTP auth interstitials and whether we need them at all (vs. just committing about:blank before showing the auth dialog).

However, eroman@ is absolutely right that the HTTP auth dialog is just one way to exploit the underlying problem, by forcing a (small) class of URLs to be slow.  Other slow URLs have the same problem.  For example, go directly to https://lbherrera.github.io/lab/stripe2.html (page 2 of the attack) and type in https://www.facebook.com:1234, which takes a long time to error out.  That gives you a chance to spoof Facebook.

As eroman@ noted, this is fundamentally because the address bar is trying to serve two jobs at once: show you where you are as well as where you're going.  Because of this, we only show the pending URL for "browser-initiated" navigations, not ones started by a page within the renderer process.  (And that's a mitigating factor that would make this, at worst, medium severity.)

However, I think it's worth checking with Enamel/UX/omnibox folks (estark@, emilyschechter@, ainslie@, pkasting@) if there's anything we can do to make this kind of attack somewhat less compelling, since it is reasonably convincing.  Various mediocre straw man ideas:
1) Similar to the "Secure" chip that we have on the left of the URL, show a "Loading" chip for uncommitted URLs.  (This would probably be confusing, since a page can still be "loading" after it commits, and it's half-redundant with the throbber.)
2) Stop showing the pending URL if the user interacts with the page while a navigation is in progress.  (This would make editing pending URLs hard, though.)
3) Show *two* boxes, one for committed URL, and one for where you're going.  (Ha!  Just kidding.)

With the current nature of the address bar, I'm not sure there's much we can do from a navigation perspective.  Is this worth pursuing from a UX perspective?

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

ping estark@ to hear an opinion on creis@'s thoughts in comment #11.

Wow, sorry I completely missed this bug. Somehow my email labelling went awry and it got lost...

Brainstorming some ideas to add on to #11:
- Would it be completely crazy to cancel a pending navigation if the user interacts with the page? (or maybe only for certain interactions, like typing/clicking but not scrolling...?) We could add UMA metrics to see how often that happens and how many navigations would get cancelled.
- How about graying out the URL while it's still loading? At the very least, we probably shouldn't be emphasizing the hostname before the navigation has committed, and dimming out the entire URL to some extent might help a little bit.

#14: Thanks-- I like the idea of visually distinguishing pending URLs from committed URLs.  Graying might be an option (though I worry about low contrast being bad for older users).  I think Safari used to show a progress bar in the address bar itself (behind the URL) during load-- maybe there's some kind of similar Material design effect we could do?

I wouldn't recommend canceling the pending navigation on interaction.  Users may be reading a bit more while waiting for a slow link to load, and it'd be frustrating to have that cancel it.  Same for a download link where the user knows they won't actually be leaving the page (before Chrome does).  It also may not help with the "call this phone number" scams, which don't require interaction.

For reference, there's additional cases in  issue 698156  (and bugs duped to it) which might benefit from a better distinction between pending and committed URLs.

emilyschechter had the idea of putting the loading throbber in the omnibox in place of the (i), which I like and we're going to talk to Max about. I don't feel super optimistic about visually differentiating pending URLs, though. If the user is tricked despite the throbber and the lack of lock icon, I'm not sure we can realistically train them to pay attention to some other indicator. Let's see what Max thinks of putting the throbber in place of the (i) though...

... though, thinking about it more, putting a throbber in the omnibox might be confusing because the omnibox throbber would stop when the navigation commits, which would be before the tab throbber stops...

Comments 17-18: To be fair, that is a more accurate representation of what's going on.  The navigation does finish before the document finishes, and the omnibox would stop spinning roughly at the time that the displayed URL corresponds to what's shown in the tab.

That said, I could also understand if that's too much animation at once.

 Issue 881747  has been merged into this issue.

Note that the desire to distinguish between pending and committed URL has come up again in issue 721184 and  issue 852725 , now that drag-n-drop is "paste, but don't go" rather than "paste and go."  Would be nice if the user could tell the difference between being on the committed page and only having the new URL present (typed or dragged) without even a navigation in progress.

Issue 910306 is another new report in a similar vein (distinguishing drag-and-drop URLs).