Issue metadata
Sign in to add a comment
|
Security: URL bar spoof via sites with long response time (from NTP)
Reported by
chromium...@gmail.com,
Jun 17 2017
|
||||||||||||||||||||||
Issue description
VERSION
Chrome Version: 61.0.3132.0 (Official Build) canary (64-bit)
Operating System: All
REPRODUCTION CASE
1. Visit chrome://newtab
2. Open the Devtools
3. Run the code:
var x = window.open('https://www.facebook.com:91')
x.document.write("Hello world!")
Loading websites with non-existent ports takes 1 minute to show a error msg, which could still be enough time to trick some users, and it's at least fairly easy to do.
,
Jun 18 2017
,
Jun 19 2017
#c1 - I don't think it is specific to the NTP, but specific to cross-process navigations. The NTP to any web page is one that can be triggered by JS in the renderer process. The page should be going blank within 4 seconds or so, which will clear any markup written by the original document. kenrb@ added this when fixing issue 497588 . I think it is safe to mark this as a duplicate of that one.
,
Jun 19 2017
The 4-second timeout doesn't fire, and I think it isn't relevant here because there is no commit from the facebook.com:91 navigation. (The timer only limits the time between commit and first paint.) Is the issue here that for a cross-process top-level navigation, we put the URL in the omnibox without a commit? In general, is there a way for a page to force a window.open() into a different process? The NTP is not a viable attack vector in practice.
,
Jun 19 2017
I agree with Ken-- the 4 second timer isn't related to this, and there's no unresponsive renderer involved. This is specific to the NTP, not all cross-process navigations. The reason it works is that NavigationControllerImpl::GetVisibleEntry() allows browser-initiated pending entries to be displayed before they commit, and because we treat all navigations from the New Tab Page as browser-initiated rather than renderer-initiated. This is generally safe because the NTP is not accessible to attackers. As a result, I'll mark this Security_Impact-None and close it, but please do let us know if there's a way to attack it from the web. Thanks for the report!
,
Sep 26 2017
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 est...@chromium.org
, Jun 17 2017Components: UI>Browser>Navigation UI>Browser>Omnibox
Labels: Security_Severity-Low Needs-Feedback Security_Impact-Stable