Hacker News new | ask | show | jobs
by pserwylo 4783 days ago
I often think about creating a browser and email plugin/extension to help with this:

- Look at all link tags.

- If it looks like a URL (has a scheme at the beginning, or something which resembles a hostname, or a bunch of path or query parameters), inspect the actual link.

- If they have different hosts, warn the user, and perhaps give them the option of just visiting what the contents of the link tag say (rather than the href attribute).

- Maybe do some magic with onclick events too.

I don't care that it wont be right 100% of the time. I don't care that some times I'll be warned when in fact it is perfectly fine. What I do care about is that when I click a link, I go to that link.

It would be quite helpful for attacks like this, but I'm also interested from a privacy perspective.

Google, Facebook and others go to great lengths so that when you mouse over a link, it looks like it will take you directly to the webpage it says it will, but actually redirects via themselves first. I often find myself copying a url from Facebook and pasting into the address bar, because I don't want them to know which articles I read (yes, I know, if I'm that paranoid, I probably shouldn't use Facebook, blah, blah).

6 comments

<a href="http://google.com/ onclick="document.location.href='http://www.hackersite.com/>http://google.com/</a>;

Oh, so you check that? How about I just position an invisible element overtop of the valid looking link? Or use the click handler to do a preventDefault/setTimeout?

The only way I can think of to even remotely feasibly try and catch this is to just track the last URL clicked if it looks like a FQDN, then compare that against the browser's URL on the next document.onready.

Of course, if the site has any sort of open redirection, then that's useless.

However, after all of this... The attackers can just switch to using links which don't have the FQDN in their label.

No sane e-mail client executes Javascript from mails.
My brain is a bit fried, but what about a rule that "if the text contained in the <a> tag is a FQDN, it should match the FQDN in the href exactly"?

What are the false positives?

Things like Google results that go through a redirector for click tracking.
So, another practice that should be highlighted and made to stop.
The easiest way to recognise the link text as a FQDN would be to check for http:// or www., but even without them (i.e. google.com/foo) users will still assume it's a URL. If attackers get creative with unicode (e.g. google۔com using U+06D4), it could be pretty difficult to identify text that looks like a link.
This is where my appliaction of a "privacy" idea to a "security" problem falls down.

With privacy, I try to be pretty vigilant, but I don't do everything in my power to prevent tracking. I am more worried with companies collecting large swathes of data on my behaviour rather than the odd tidbit. I'm quietly hopeful that analytics, advertising et al. companies will not go to such ingeniously dodgey methods for tracking peoples behaviour (though being hopeful is very different than expecting them not to be dodgey).

But who knows, as a filter that might catch a portion of phishing links, it may have some use.

I would just be happy if clicking any link in an email just popped up dialog first with "Do you want to go to the following URL" with the real URL. I always copy URLs from emails and paste into the browser to be sure I'm getting the URL I think I am, and this is basically just giving me the same preview. For less qualified users, maybe it could bold/highlight the domain name (stripping the subdomains where all the phishing magic happens) and ask "are you sure you want to go to phishingdomain.com".
I believe Thunderbird's phishing detection does something along the lines of matching link text with link destinations. Mostly noticed it because mail from Mozilla tend to trip it...

It also (by default) disables scripts in mail anyway, so onclick events aren't a problem. In fact, I would be surprised if any mail client enables script by default; that just seems like a horribly bad idea.

One word: mutt.
People who fall for attacks like this don't install protective extensions, or if they do, they become complacent assuming that those extensions will always protect them.