Chrome URL Spoofing: Dragged URL does not start navigating
Reported by
evi1m0.bat@gmail.com,
Jun 14 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.25 Safari/537.36 Steps to reproduce the problem: 1. Open PoC: https://server.n0tr00t.com/chrome/drag_url_spoof.html 2. Drag hyperlinks to the URL address bar 3. URL Spoofing What is the expected behavior? What went wrong? First question: URL Spoof Vulnerable Second questions: Preview effect at drag and drop, url: https://goog...com/?search Did this work before? N/A Chrome version: 68.0.3440.25 Channel: beta OS Version: OS X 10.12.6 Flash Version: Shockwave Flash 30.0 r0
,
Jun 14 2018
I think this is to do with when the URL gets committed to the omnibox, I don't think any attack would be possible here, but triaging Low in an abundance of caution... creis can you take a look here?
,
Jun 14 2018
#2 @wfh Ha, I think the cost of drag and drop attack is not very difficult, but it doesn't matter. It's really a problem to solve. For example, in Firefox, the effect of the address bar after drag and drop has not changed, but is waiting to load.
,
Jun 16 2018
Interesting. The original report here is a duplicate of issue 698156 , which is a WontFix for the reason below: ---- I don't think there's likely to be anything we can do here. Drag n drop is basically no different than having the page tell the user to "copy this link and paste it in the address bar." When the user initiates any navigation in the address bar, we intentionally show that URL until it commits or fails, even if the navigation is slow. It's true that the currently visible page can change its appearance during this time, but it doesn't have much control over where the user is trying to navigate. Mitigating factors: the spinner is still going, and Chrome doesn't show the lock icon for HTTPS URLs until the pending URL commits. Note that pages themselves can't initiate this attack on their own-- when they start a navigation, we don't show the pending URL until it commits. Also note that navigations might not commit (e.g., they might turn out to be a download or 204 response, leaving you on the current page), so we can't clear the current page during a slow navigation. Nasko or Peter, do you have any thoughts on improving what Chrome does here? If not, I think this can be marked WontFix. ---- *However*, this report has caused us to discover a new issue, which I think needs some attention on the omnibox side. Unlike the screenshot in the original report, if I drag the link to the omnibox on Windows, Linux, or ChromeOS, the address bar changes but the navigation does not begin! Thus there's no spinning icon, and it does look more like you've arrived already (though there isn't a lock icon for HTTPS URLs). You can also see this by dragging any link on any page to the omnibox, from Chrome 69 to Chrome 69 (and probably earlier). Mac seems to be the only place that dragging a URL is triggering the navigation. Hitting Escape when focus is in the omnibox resets the page back to what you were on, confirming that dragging is just putting the text there as if the user typed but didn't hit enter. pkasting@, do you know anything has changed in the omnibox code about dragging URLs, and why we wouldn't be starting the navigation? Marking Needs-Bisect to see when this regressed. I still think this isn't more than Severity-Low since it requires user interaction (and thus they know they put the URL there), but it does remove one of the mitigating factors for spoof attempts like this (i.e., that the spinner should be going).
,
Jun 19 2018
We intentionally changed the behavior of DnD to the omnibox to "paste, but don't yet go". This was done for bug 791259 . I don't think there's a bug here.
,
Sep 26
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
,
Nov 21
Issue 907497 has been merged into this issue.
,
Nov 30
Issue 910306 has been merged into this issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by evi1m0.bat@gmail.com
, Jun 14 2018PoC: ``` <html> <body> <script> window.onbeforeunload = function(){ document.write("<h1>URL Spoofing...</h1>"); } </script> <li>Drag hyperlinks to the URL address bar</li> <li> <a href="https://www.google.com:2233/?aaaaaabbbbbbccccccddddddeeeeeeaaaaa">https://google.com</a> </li> </body> </html> ```59.1 KB
59.1 KB View Download