Issue metadata
Sign in to add a comment
|
Clicking on URL Suggestions Does Not Update the Current URL
Reported by
0xso...@gmail.com,
Sep 10
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3547.0 Safari/537.36 Steps to reproduce the problem: 1. Navigate to "https://example.net". 2. Edit the URL to become "https://example.". 3. Click on the "https://example.com" URL suggestion. What is the expected behavior? The current URL should be updated to "https://example.com" after the navigation is completed. What went wrong? The current URL remains as "https://example.net" even after the navigation to "https://example.com" is completed. Did this work before? N/A Chrome version: 71.0.3547.0 Channel: canary OS Version: OS X 10.13.6 Flash Version: This could be a potential vulnerability. A malicious attacker who owns "example.net" could present content that appears to be from "example.com" (and do phishing attacks) if a user happens to navigate to his domain via a ZeroSuggest URL suggestion which is pulled from search engine results (could also be influenced by the attacker).
,
Sep 10
This doesn't look like zero suggest. (It looks like you've entered text into the omnibox; these aren't suggestions displayed on focus.) Adjusting tags. This looks vaguely similar to bug 830491. reporter: It looks like the omnibox is displaying the right thing: the page the user is currently on. It looks like example.com redirected (?) to example.net. Are you sure this is a vulnerability and not a dev-tools bug that still has the old pre-redirect location?)
,
Sep 11
Re #2: No, the omnibox is indeed showing the wrong URL (there are no HTTP redirections between the two origins). And no, this bug is not related to the dev-tools either (I can repro on a fresh profile without opening the dev-tools and on different websites).
,
Sep 11
Thanks for the clarification!
,
Sep 11
I cannot reproduce this in 69.0.3497.92 nor on 71.0.3550.0. Reporter: does it still reproduce for you on the latest canary? Also adding needs Test-Confirmation.
,
Sep 12
Re #5: Yes, 71.0.3550.0 on macOS is still affected. Can't reproduce on Windows (probably reproducible on macOS only).
,
Sep 14
The NextAction date has arrived: 2018-09-14
,
Sep 18
I can reproduce this, but only with the old Cocoa UI. With Views enabled, regardless of the other chrome://flags UI settings, this issue doesn't occur. Views is expected to go to 100% very soon. Setting a next date to look at this again just in case some problem with the Views launch occurs. If the launch completes in the meantime, this issue can be closed.
,
Sep 18
I'll check this on the next action date.
,
Sep 25
The NextAction date has arrived: 2018-09-25
,
Sep 25
M69 is at 100% in Stable as of Sep. 19 and MacViews has been at 100% across all channels since Sep. 20. Given that this issue does not exhibit in MacViews, I'm going to close this now.
,
Jan 1
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 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mpdenton@google.com
, Sep 10Components: UI>Browser>Omnibox>ZeroSuggest UI>Browser>Omnibox
Labels: -Pri-2 Security_Severity-Low Security_Impact-Head Pri-1
Status: Untriaged (was: Unconfirmed)