I thought this was sensationalist the last time it came up, and I still do.
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]
And it's counterproductive. Since the birth of the web we've been trying to drill into people's skulls not to trust anything except what it says in your URL bar after "https:". We need to avoid anything that would give users any other impression.
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."
[0] On a large scale, that is. Obviously some people here are comfortable with disabling swaths of JavaScript across the web.
It can be used to lead you to a page that exploits the browser, before you realize you're not on the expected site.
There are, most of the time, undisclosed zero day attacks in the wild, for most browsers and plugins.
I should add that I check the URL bar when I enter information, but not always when I browse casually. I always check the target of links, though, and this could trick me.
I wouldn't be surprised if some users never read the URL bar... people who can't tell a browser from a search engine, for example.
The danger of this, is not (IMO) people inserting personal data or financial data on the end page (which would be avoided by paying attention to the URL bar), but in targeted attacks where the page serves up a IE/Flash/Java exploit compromising the users machine. At this point it doesn't matter what the end result is, as the damage is done. Also, an attacker can simply redirect to to the orig page/target after exploitation in such a way that the majority of casual users wouldn't notice, as there is no user interaction at the end.
Example a link to an article or PDF report of interest is Hijacked via this method (where the hover is correct but actual target is malicious) the user quickly hits the exploit site and is compromised/malware dropped while the exploit site displays a splash page of some sort briefly, it then forwards to the orig. destination.
I don't see the majority of non paranoid users detecting this, even if they are in the right mindset, as they end up at the proper site with nothing more than quick, and now ubiquitous, splash/ad page in between.
EDIT: I'm not necessarily advocating any change, this behavior can be tracked and blocked in a properly secured infrastructure, but this is where I see the potential for harm.
The point remains that this kind of thing is entirely possible via "legitimate" methods, too.
If the bad guys can inject Javascript into your page, it's game over, period. The attack vector is meaningless; there are tons of them. If I can inject my Javascript into your page to hijack your clicks, why would I bother with that rather than just putting an invisible iframe into the page that delivers the payload without any user interaction required? It's going to get me far better results, doesn't rely on undocumented behavior, and isn't contingent on a user failing to notice a splash screen.
cjc1083's proposed attack vector is an interstitial page which drops a Java/Flash 0-day on you and forwards you to your original target site, leaving you compromised and none the wiser. My point is that if you can even do the redirect in the first place, it's much simpler to just iframe in the attack page and do the drop directly rather than waiting on user input to do it in a manner that they might notice.
Are you suggesting that if you point my browser to a malicious URL [Chrome on Win 7] I will get malware "just like that", without clicking anything? How's that possible, exactly? (I have no Java installed.) I understand there could be a _security_ flaw in the browser itself, but are you telling me there are security flaws that mean "malicious URL opened = arbitrary malware will now run on user's OS"???
Possibly, yes - Flash and Java are both commonly-exploited attack vectors for this. Not having Java is a good start, but Chrome ships with Flash embedded in it (and to Google's credit, they keep it aggressively patched by pushing updates), but if someone were running an exploit against an unpatched zero-day, then you could go to a harmless site which is running federated ads, which the attacker has purchased ad views for, and which they use to serve their Flash-based payload which runs the exploit and provides some measure of your access to your computer (often to add an additional payload that can be used to back-door you). The damage is done.
To protect yourself against this, you should go into Chrome's about:settings/content and set Plugins to "click-to-play", so that you have to manually allow a plugin to execute, preventing this kind of drive-by attack.
>Since the birth of the web we've been trying to drill into people's skulls not to trust anything except what it says in your URL bar after "https:".
While perhaps this should be true, I don't think it is. I don't recall any internet instruction manual advising people to check the domain and browsers don't exactly emphasize the domain.
It was purely gathering thoughts to what I consider a flaw. Sure, it's not the only way to do it -- but this is it in it's simplest form.
False redirections is the principle. I'm not sure how to fully eradicate it in that sense, but I think to bring attention to the possibility is somewhat beneficial rather than sensationalist.
The only reason that I don't like it isn't for attacks, but for undisclosed affiliate schemes. Even if I'm watching my address bar once I get there I may have been 301'd before I could notice the bar changing.
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]
And it's counterproductive. Since the birth of the web we've been trying to drill into people's skulls not to trust anything except what it says in your URL bar after "https:". We need to avoid anything that would give users any other impression.
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."
[0] On a large scale, that is. Obviously some people here are comfortable with disabling swaths of JavaScript across the web.