I thought this was sensationalist the last time it came up, and I still do.<p>This is an attack which targets people who are carefully checking the link URL before clicking, but who then ignore the actual content of their URL bar. That has to be a pretty limited group, right? And this is far from the only way to spoof a link in JavaScript, so to really make this impossible would mean disabling swaths of functionality used widely across the web, i.e. not gonna happen.[0]<p>And it's counterproductive. Since the birth of the web we've been trying to drill into people's skulls not to trust <i>anything</i> except what it says in your URL bar after "https:". We need to avoid anything that would give users any other impression.<p>That said, there is a useful message here, not "this is a problem with JavaScript" but "this is another reason you must personally validate the domain name before entering any personal information."<p>[0] On a large scale, that is. Obviously some people here are comfortable with disabling swaths of JavaScript across the web.
While this should probably be fixed as prescribed by the author, it's relatively easy for a no-goodnik to accomplish the same goal without touch the href:<p><pre><code> $("a").click(function(e){
e.preventDefault();
document.location="http://evilsite.paypa1.com";
});
</code></pre>
In either case, a right-click to open or copy/paste sidesteps, though that's just a kludge.
This is not a hack it's basic Javascript.<p>If a malicious hacker can insert some script in a trusted page, security is pretty much completly broken and you have other worries. The fact that you can make links in this page point to other malicious pages seems like a small problems as most people won't even check the domain before clicking the link.<p>I would think that some users are most likely to check the address bar after clicking the link. But my dad would probably woudn't see anything.
you kidding right? while we have real world problems (URL detections, cookies etc check homakov.blogspot.com) you ask w3c to do what? To deny redirecting to other websites and changing href after click? I can tell you more horror JS tricks, but they are not fixed yet.
I work on the IE team at Microsoft, and I really don't think this is an exploit. If you can control the script for the click event, then you already have control of the page and can do worse (think: cross-site scripting). In this case, if you browse to my site and I'm a bad guy and want to send you to evil.com, I'd just craft a page that makes you think the whole page is honorable, rather than hope you click on a link. In other words, anyone who can hack the click event already owns you.<p>I'm very happy to reassess if you have an example where you do not control the content of the page, but somehow still control the content of the click. That would be really serious and worth fixing.<p>-John Jansen
Principal Test Lead
Internet Explorer
I use this trick to mask email addresses in mailto: links, i.e. something like:<p><pre><code> <a onClick="this.href=
['mailto',[['john','doe'].join('.'),
['gmail','com'].join('.')].join('@')].join(':')"
href=#click-to-email>
</code></pre>
I don't know how good my solution is in protecting from spammers' scrapers but I'd be happy to hear about any alternatives.
In addition to countless other oversights, setTimeout would not work as you suggested in the post as the page would be unloaded before it ever executed. And, as others have already mentioned, there are numerous other ways to accomplish the exact same effect with 'more legitimate' methods (e.g. event.preventDefault(); window.location = ...).<p>Various browsers such as Chrome will warn/block you from visiting known malicious sites, but it comes down to being aware of where you are before entering personal information.<p>I think a better proposal might be getting browsers to warn users if the url they are visiting is sufficiently different from the original href attribute (i.e. different host). Something like this could easily be done with a browser extension (and could handle more cases such as preventDefault + window.location = ...).
Firefox 21 (Aurora), I got sent to PayPal - just realized that I had NoScript on, though. Allowed scripts for bilaw.al, tried again, and I got sent to the dummy page.<p>I got sent to the dummy page on Opera 12.13 and Chrome 25. Just updated to Opera 12.14 and I still got sent to the dummy page. Running Windows 7.
You can set up a span with a style that has a link-like look (color, underline), use "cursor:pointer" in the style to make the pointer turn to a hand over it. Use a mouseover/out event catcher to trigger a tooltip that mimics the mouseover behavior on links, then capture the click event on the span to send the user to another page.<p>You can use JavaScript to swap out all the links for spans like these.<p>If you're on a site that's using intentionally deceptive JavaScript or getting malicious JavaScript injected, whether or not links go where you think they will is the least of your problems.
I just tried clicking your "Paypal" link in Chrome 25, Firefox 19, and IE9. All of them allowed the href to change and went to what could have been the phishing site. Then I went back and tried right-clicking the "Paypal" link and open in a new tab. All 3 browsers went to Paypal.<p>I like your suggestion to have behavior changed so the browsers don't allow the href to be changed to another domain without warning the user. Until that happens, maybe opening links in a new tab (or window) is a good practice.<p>Enjoy!
The reason for onclick is exactly the mentioned "problem".
I use <a> tags to show them as links, but without reference, only with onclick events to load the actual request.
So if any browser manufacturer tries to kill this behaviour (like x-site scripting bullshit) the world will go oom...<p>So, if you do not like the javascript events -> disable javascript interpreter in your browser!<p>It would make more sense to kill IE, ActiveX, Flash and Java-Plugins...
right click open in new tab takes you to the original link. So this must be done in session or something and the alt-open in next tab take the plain link URL?
So did you just discovered DOM manipulation with JavaScript ? What would a browser fix be like in your opinion ? Disallow JavaScript to add event listeners and/or modify Node properties ?<p>Google Analytics hooks on links to track clicks and exit pages and so on. Would you really enjoy an alert every time you click on something ?
I am amazed how you people come up with crap like this.<p>Enjoy your 5 minutes of traffic while they last
I dislike loggin in to sites that I have been referred to by other sites in general. Not sure if there is a solution for paypal? Like getting an transaction id from a shop, then logging on to PayPal and paying that transaction id?<p>Might be something worthwhile to provide a solution for (possibly even a valid use case for QR codes - pay with phone on a web site)? But then, not many people will care, I suspect :-/
I noticed that at least one other person suggested opening the link in a new tab. This seems to defeat this hack in Chrome and IE 9. It probably defeates it in all browsers, since the new tab is in a different context than where the javascript is being executed and therefore can not be redirected by the javascript.
Fun fact: On Chrome, Opening the link in a new tab does not redirect to the phishing site. However, normal clicking does. Context changing seems to make this work, as chrome delegates the href to a new process, and does not execute the JS embed.
This may be the dumbest blog post I've ever read. The fact that this is possible (and necessary) speaks more to the general glacial nature of the HTML standards and JS to provide the functionality we expect of our web apps.
Right clicking the link and choosing "Open in new tab" with Chrome does not execute the JavaScript. This is good and bad. Good because it solves your problem, bad because it makes the link unpredictable.
So many sites use this for various reasons like appending tracking codes (my former employer did this for Omniture tracking).. I just don't see this suggestion to disable the functionality catching on.
Before I turned off noscript, I was very confused about how bilawal came into possession of paypal.com.<p>It took me a few seconds before I realized how stupid that entire line of thought was.
"If someone has control of the DOM the game is already over"<p><a href="http://www.frameloss.org/2012/10/28/hover-fail/" rel="nofollow">http://www.frameloss.org/2012/10/28/hover-fail/</a>
Firefox 19.0.2 on Linux shows the JS Pishing link on mouseover, Firefox 19.0.2 on Windows 7 doesn't! So, Firefox 19.0.2 on Linux is the only safe browser.
Don't want to sound rude, but I've known about this for literally years.<p>I think anyone who makes single page web apps uses this "hack" on an everyday basis.
hmmm nice though and this is the mainly reason of Phishing page because when we make a Phishing page then we have to use this step to change the URL when victim click on that.... that's why phishing is happening ...<p>so read this news carefully and be aware for futue...
This is incorrect. Once you get to see the url in the bar, it's too late if you've been redirected to a site with malware. This is an extremely serious security flaw and downplaying it is not going to help anyone.<p>There is no use for this security hole other than to deceive people. Period.