New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 656449 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Status Bar Obfuscation

Reported by haiderka...@gmail.com, Oct 16 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce the problem:
1. Open the HTML file (Testing.html file i have attached)
2. You will see a hyperlink of google.com, So hover your mouse.
3. See the Status Bar(located at the lower left of the browser) and you will see the link where it should be redirected.
4.Now, click the hyperlink and you will be redirected to another website which is not the expected website.

What is the expected behavior?

What went wrong?
Status Bar Is Not Properly Validating Things

Did this work before? N/A 

Chrome version: 53.0.2785.143  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 23.0 r0
 
POc.jpg
92.3 KB View Download
Testing.html
221 bytes View Download
Cc: sureshkumari@chromium.org
Labels: Needs-Feedback
 haiderkamal71@  AFAIK if an event causes both a default action and execution of a event handling script,the execution of event handling will execute first.
That is why it is taking to ebay.com which is mentioned in the onclick event handler.
Hover will display the actual link provided for href attribute which google.com in this case.
So I feel it is working as intended.

Could you please check my comments and let me know if i miss anything from my end.

Thanks,
Please Think As A Attacker.It is Not Good For Such A High Class Browsers.It should shows that what is behing.for exapmle Please Go To www.brave.com and download their browser and check how they have fixed it.they has recently patched this.
Project Member

Comment 3 by sheriffbot@chromium.org, Oct 24 2016

Labels: -Needs-Feedback Needs-Review
Owner: sureshkumari@chromium.org
Thank you for providing more feedback. Adding requester "sureshkumari@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Comment 4 by woxxom@gmail.com, Oct 24 2016

There's simply no way of showing what the final url will be if you allow javascript on the page. The browser can't blindly pre-evaluate the final URL because it'll break links that use one-time tokens. And disabling js by default in the browser will simply break half of the web. People who value their security use NoScript/uBlock and similar extensions that allow blocking of some/all js on pages. For the rest of users there will always be a method to trick them.
Labels: -Needs-Review OS-Linux OS-Mac
Owner: ----
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on windows-7, Mac 10.11.6 and Linux Ubuntu-14.04 using chrome stable version 54.0.2840.99 and latest canary 56.0.2919.0. 

This is non-regression issue observed from M-30 # 30.0.1550.0 . Hence marking it as Untriaged to get more inputs from dev team.
Please find the attached screencast.

Thanks..
656449.mp4
928 KB View Download
Components: UI>Shell>StatusArea
Is this is Patched..?
Its still working Not Fix.
Owner: manucornet@chromium.org
Status: Assigned (was: Untriaged)
Bulk-assigning unassigned status area bugs to me.

Sign in to add a comment