Closed Bug 1843759 Opened 1 year ago Closed 1 year ago

Security: Statusbar shows wrong link target

Categories

(Firefox :: Security, defect)

defect

Tracking

()

RESOLVED DUPLICATE of bug 229050

People

(Reporter: FrIdGe, Unassigned)

Details

(Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(1 file)

Attached file test link replacing.html (deleted) —

Hello,

As publicly known, a well-spread best practice for security in regard to surfing within the internet and clicking links is to move the mouse pointer over the shown link and check the then shown plain text link in the status bar (usually the lower left corner of the browser window). There the user can find the link target hovered.

Also, the user might right-click the link and copy it to the clipboard, for e.g. manually checking it in https://safebrowsing.google.com/ or any of the several online virus scanner services.

All this should be done to avoid being accidentally redirected to a malicious website and/or falling victim to a phishing site.

Problem:

Here:

  • Firefox Windows
  • Firefox Android

The presented plain text URL can be "falsified" quite easily and thus lead the user to a malicious and/or phishing site etc. These pages may exploit zero-day vulnerabilities and/or do other harm to the user. I assume I do not have to explain that.

I noticed this behaviour while visiting a "regular" page which had such a strange handling implemented. Please simply give it a try by opening the attached HTML-file.

Indeed, you may decline a fix because the faked link is just and only opened after useraction (here: clicking). But stop, that is only the half of the truth.
The problem here is clearly the fact, that e.g. https://accounts.google.com is shown to the user prior clicking, but after clicking a script is leading to https://testsafebrowsing.appspot.com/s/phishing.html. Without any hint, without any confirmation, without nothing.

From the technical sight this might be intended behaviour, as the faked site is opened by a script AFTER clicking the item, ...

... but from security sight this is leading security measures to absurdity, in particular if the shown target is a HTTP or HTTPS site and not a placeholder like as observed "#" or "onClick()".

Expectation:

For security reasons it would be a good thing if the browser would check for differences between the shown (HTTP/HTTPS and other relevant prefixes) from the tag <a href=...> and the in fact opened link. A messagebox showing the discrepancy and asking for explicit confirmation would be a good solution for me. Only after explicit confirmation the "faked" target has to be opened, instead the initially shown link target.

In a nutshell, misleading the user has to be prevented from the base on. Unfortunately, things cannot stay the way they are at the moment.

And to be honest: No user checks the link of the opened website again if he has already done it via the link target. If this clearly contains a legitimate link without homoglyphs, i=1, o=0 etc, the page is safe. That is consensus.

But unfortunately this consensus is reduced to absurdity by the misleading handling.

Thank you in advance for checking and fixing - for my and the security of millions of users.

Best regards

Flags: sec-bounty?

This is, unfortunately, baked into the current web. There are an almost limitless number of ways to fake where a link is going, but the simplest is to add a click event handler that cancels the event and the manually navigates the page somewhere else. All the links on most of the most popular sites (social media, search engines, web mail) do this, apparently for analytics purposes. Any browser that tried to "fix" this would be so broken on the sites that most people want that it would immediately be abandoned.

[This should be closed as a duplicate but I unfortunately don't have time to find the old bugs right now. Clearing the security flag so the regular bug triagers can see the bug]

Group: firefox-core-security
Flags: sec-bounty? → sec-bounty-
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 229050
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: