28

We are using a browser based email client and the email content is in HTML.

One of my employers told us that if we receive a suspicious email with links, we have to hover over the link (to check that it is not spoofed) before clicking it. Hovering over triggers an action to display the underlying link in the browsers status bar. However, would someone be able to spoof this action and try to do something funny?

This is a similar thread but it discusses thumbnails of attachments and not links in the email.

Community
  • 1
JOW
  • 2,319
  • 2
  • 16
  • 24
  • Don't some browsers do pre-fetching of links the user might visit? Could that be harmful? – muru Mar 05 '17 at 10:33
  • 1
    Don't overlook one obvious, significant risk... If you encourage a large group of people to hover, there's a high probability that some people will accidentally click. – leekaiinthesky Mar 07 '17 at 18:37
  • @muru, pre-fetching sometimes happens in various ways, but I can't imagine a browser would just visit any link (including ones that users hover over). That'd be a bad idea, since many links might have side effects (for a non virus example, imagine hovering over a delete link!). Pre-fetching would have to be more intelligent, wouldn't it? ie, service specific. You can prefetch the first google result because many people click it. Or the next image in a known image host. Etc. – Kat Mar 07 '17 at 22:36

2 Answers2

53

One of my employers told us that if we receive a suspicious email with links, we have to hover over the link (to check that it is not spoofed) before clicking it.

When you mouseover a link, the value of the href attribute is displayed in the status bar. Since this is the link target, it can give you an idea about where the link is going.

would someone be able to spoof this action and try to do something funny?

Generally, yes. The actual link target can be "spoofed" using Javascript: It is quite common for websites to exchange the href value with another link as soon as the user clicks on it. For example, you can observe this when visiting Google search results. When you mouseover one of the links, it will be displayed as https://security.stackexchange.com/... but as soon as you click it, that event is captured and you visit an intermediate site first (https://www.google.com/url?...) which redirects you to the actual target.

But any well-designed (web-based) mail client will not execute any JS in HTML e-mails. Active script content in e-mails is dangerous - not only because it potentially results in an XSS flaw in the mail client but because it can also be used to run JS-based exploits against the browser or simply inform the sender that you have opened the mail.

So, if your mail client disallows JS in e-mails - which it most likely does - then the link displayed on mouseover is indeed the correct link target. But you should be aware of other attempts to deceive you, such as homograph attacks or an overly long URL that disguises the actual target domain. It's not as easy to analyze an URL in the status bar as it is from looking at it in the address bar. In a more advanced attack, the attacker could also have compromised a legitimate site beforehand (e.g. through a persistend XSS flaw) and you won't be able to tell from the link at all that the site now actually hosts dangerous content.

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • 32
    I hate that Google does that, because sometimes I just want to see the full link without actually going to the page. – JAB Mar 03 '17 at 18:55
  • @JAB Yeah. The workaround is to inspect the DOM before clicking on the link or clicking on "copy link address". (Right-click and "Inspect", or use something in the console like `Array.from(document.getElementsByClassName('r')).forEach(x => console.log(x.firstChild.href))`. There's probably an extension that already does this.) – ShreevatsaR Mar 03 '17 at 20:06
  • 5
    to be specific: the href cannot be forged since they removed `window.status`, rather google intercepts the click()s and does something else. In fact, if you just right-click (and cancel) a link you can see the href change from the clean actual url to the redirect URL, and the "tooltip" then shows the redirect url... – dandavis Mar 03 '17 at 20:20
  • 2
    Another homograph attack not listed is with i's. For example: the URL googIe.com ("googie") is not easily distinguishable from google.com with most sans-serif fonts. – oldmud0 Mar 04 '17 at 00:09
  • 4
    @JAB: If you're using Firefox or similar, there is [Google search link fix](https://github.com/palant/searchlinkfix). – user21820 Mar 04 '17 at 04:09
  • @ShreevatsaR: There is; see above comment! – user21820 Mar 04 '17 at 04:14
  • Unfortunately, the concerns raised here don't really apply to any real case -- most mail clients block JS in mails, and in case of mixed homographs, most mail clients display it in punycode instead of their original form. –  Mar 04 '17 at 04:44
  • 1
    @JAB I have created a simple Greasemonkey script, [see at superuser.com](http://superuser.com/questions/328271/how-to-disable-google-search-result-link-redirect-on-right-click-in-chrome#958162). – Gras Double Mar 04 '17 at 11:02
  • It might also be the case that what appears to be a single hyperlink consists of multiple hyperlinks with different targets. Example: [Vis](http://good-site.example.com/)[it ou](http://bad-site.example.com/)[r site](http://good-site.example.com/) -- this can be detected if the UA uses suitable styling, and often by clicking-and-holding, after which you have to release the mouse button somewhere else (the clicked link will get an outline, unless the UA prevents this). – unor Mar 09 '17 at 19:58
11

This could only be achieved with JavaScript. You can set the link to anything, and then write an onclick action that sends the user somewhere else:

<a href="http://example.com" onclick="window.location = 'http://www.google.com';return false;">click</a>

But if you allow JavaScript to be executed by your browser based email client, you are vulnerable to persistent XSS, which means that you have bigger problems.

As an aside, telling users to do [inconvenient thing] will almost never work as security mechanism. A better solution would be to strip out all a tags and substitute the actual link instead.

tim
  • 29,018
  • 7
  • 95
  • 119
  • +1 for substituting the link. Your message will look like hell, but at least there's no more trickery allowed. – Mast Mar 04 '17 at 14:06