Issue metadata
Sign in to add a comment
|
Spoofable URLs in omnibox
Reported by
zachbor...@gmail.com,
Nov 20 2016
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36 Steps to reproduce the problem: 1. Attacker includes html in a page: <a href="http:///www.evil.com/%E2%80%A9https://www.google.com/">Visit Google Homepage</a> 2. Victim sees https://www.google.com/ in status bar What is the expected behavior? Victim sees full url (http:///www.evil.com/%E2%80%A9https://www.google.com/) in status bar. What went wrong? The paragraph separator character (e2 80 a9) causes the status bar to display the last part in the url separated by the paragraph separator character. Did this work before? N/A Chrome version: 54.0.2840.98 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 23.0 r0
,
Nov 21 2016
Thanks for the report. Status bar isn't a security indicator, it's fully controlled by the page (which is also why it's rendered inside the page rather than browser chrome). Please see https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Where-are-the-security-indicators-located-in-the-browser-window- and https://www.chromium.org/user-experience/status-bubble#TOC-Lack-of-Security
,
Dec 10 2016
meacer: I think OP's Comment 1 demos a valid security vulnerability, since, according to the screenshot, he was able to hide part of the URL in the address bar. The FAQ says "[...] are not security concerns unless Chrome is **misrepresenting a URL or origin after navigation has completed.**".
,
Feb 6 2017
The ellipsis hint can be also be defeated.
,
Feb 6 2017
Makes this "disturbingly clever" attack[1] worse because the paragraph separator wraps all trailing data to the next line in the omnibox rendering it hidden. Reproduce: <a href="data:text/html,https://accounts.google.com/ServiceLogin?continue=https%3A%2F%2Fmail.google.com%2Fmail%2F&service=mail%E2%80%A9<script type=text/javascript src=data:text/javascript;base64,ZG9jdW1lbnQudGl0bGU9IllvdSd2ZSBiZWVuIHNpZ25lZCBvdXQiO2w9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnbGluaycpO2wudHlwZT0naW1hZ2UveC1pY29uJztsLnJlbD0naWNvbic7bC5ocmVmPSdodHRwczovL3d3dy5nb29nbGUuY29tL2Zhdmljb24uaWNvJztkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgnaGVhZCcpWzBdLmFwcGVuZENoaWxkKGwpOw==></script>">Click me</a> [1] https://twitter.com/tomscott/status/812268998742118400
,
Feb 6 2017
Comment #2, #3, #4: Spoofing the path portion of the URL isn't in and of itself a vulnerability, which is what the screenshot in comment #1 shows. If you could spoof the origin (which is https://example.com), please file a separate report. Comment #5: I'm unable to reproduce that problem (omnibox showing two lines). Can you please describe the steps?
,
Feb 9 2017
Comment #2: Is status bar with javascript disabled considered a security indicator? Comment #5 was just for illustration purposes.
,
Feb 9 2017
Comment #2: Is status bar with javascript disabled considered a security indicator? No. It's fully controlled by the page so its contents cannot be trusted. Please see https://www.chromium.org/Home/chromium-security/security-faq#TOC-Where-are-the-security-indicators-located-in-the-browser-window- Comment #5: Understood, thanks for clarifying.
,
Feb 9 2017
> Comment #2: Is status bar with javascript disabled considered a security indicator? I missed the "javascript disabled" part, but it shouldn't be any different. Any UI inside the content area should be considered untrusted. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by zachbor...@gmail.com
, Nov 20 201697.8 KB
97.8 KB View Download