1270314 - Link target can be spoofed by rewriting the HTML on :hover and changing back onclick, even for Copy Link Location

Status: RESOLVED DUPLICATE of bug 257307

(Core :: DOM: Security, defect)

Description

[Paul]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160425114621

Steps to reproduce:

Visit a page that uses Revcontent's click tracking, e.g.:

http://www.medicaldaily.com/creative-thinking-psychopath-test-arts-384117

Find the "Powered by Revcontent" section (in the above link it should be on the right, titled Latest News; this may be blocked by ad blockers).  Hover over a link and note that the target displayed appears legitimate (a link to the same site).  Right-click on it and Copy Link Location.


Actual results:

The copied link location is spoofed to trends.revcontent.com. That is the actual link in the HTML at load time; code that runs on a :hover event spoofs it to the link displayed by the brower, but this is undone when the link loses focus or is clicked.


Expected results:

The link copied should be that which is displayed by the browser.

Comment 1

[Alice0775 White]

Maybe duplication of Bug 229050

Comment 2

[Paul]

Good point, I did look at that bug, but thought that Copy Link Location should be trustworthy.

Comment 3

[Ciprian Muresan [:cmuresan], Ecosystem QA, OOO until the 3rd of Jul needinfo @mcoman or @poiegas]

Can you help us find a suitable duplicate for this bug? I'm thinking either Bug 257307 or Bug 229050 from comment 1.
What do you think?

Comment 4

[Paul]

I looked at both of those before filing, but neither captures the Copy Link Location problem.

As a power user I've been aware of the onclick issue in those bugs for many years, and when it's come up I've used Copy Link Location to circumvent it. I filed this bug because Copy Link Location is also getting fooled, and it shouldn't be, there should be *some* way of getting the URL without going through source code or writing it down by hand.

Comment 5

[Ciprian Muresan [:cmuresan], Ecosystem QA, OOO until the 3rd of Jul needinfo @mcoman or @poiegas]

If I'm understanding your last comment correctly, you're saying that Copy Link Location used to work in the past and now it does not. If so, could you please try and find a regression range using the Mozregression tool? Information on the tool is available at http://mozilla.github.io/mozregression/.

Comment 6

[Paul]

I'm just reporting how it behaves now. This behaviour violates the Law of Least Astonishment. It could always have been like this (though I haven't noticed it in the past), but it is still a bug. Does that make sense?

Comment 7

[Ciprian Muresan [:cmuresan], Ecosystem QA, OOO until the 3rd of Jul needinfo @mcoman or @poiegas]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0

The issue is reproducible on the latest Firefox release (46.0.1, Build ID 20160502172042) and on the latest Nightly (49.0a1, Build ID 20160512030253). The issue is not a regression as I could trace it back Firefox 3.6.

Comment 8

[Daniel Veditz [:dveditz]]

This ad script is not using the :hover CSS style. It has the typical pair of mouseover and mouseout events which swap the href in and out (using values stored in custom data- attributes on the link). The bit that's frustrating your Context Menu items (copy link) is that there is also a mousedown event handler putting the tracking link back in the href.

This behavior sucks, but it's in the realm of what bug 257307 covers.

Comment 9

[Paul]

Thanks for investigating and explaining. I agree that bug covers it; didn't see it before.

An add-on like this one could help in this instance (if it worked), but perhaps there can be no general solution:

https://addons.mozilla.org/en-US/firefox/addon/copy-url-on-mouse-over/