Beware Tabnabbing, a New Type of Phishing Attack
I can never decide whether I’m happy when a good guy discovers and publicizes a new way of potentially exploiting Internet users. After all, it’s better that we learn about the problem before it appears in the wild, but there’s always a worry that the bad guys wouldn’t have figured it out on their own without the hint. The latest trick, dubbed “tabnabbing,” comes from Aza Raskin, Creative Lead for Firefox (and son of Jef Raskin).
Here’s how it works, and you can watch it happen yourself by loading the proof-of-concept (which is also the page where Raskin explains the exploit). Although Aza Raskin tested primarily with Firefox, I was able to verify that the exploit also works in the Mac versions of Safari, Camino, Opera, and OmniWeb, though not quite in the same way in each. The current version of Google Chrome (5.0.375.55) appears to be immune to the problem, though it’s possible that Google fixed it quickly, since others have previously reported Chrome as vulnerable.
SneakyPage could pretend to be Gmail or Hotmail or Citibank or any other commonly used site. The specifics don’t matter; all it has to do is make you believe that the tab contains a legitimate login form for a service you use.
If there’s no guarantee of safety – at least until browser makers figure out a solution – how can you protect yourself? I see a few realistic options that don’t require extra effort and could even make your life easier:
- If you ever switch to a tab and it’s displaying a login screen, be very wary. No, scratch that. Just close the tab – it’s not worth thinking about whether it might be an attack.
- Rely on auto-fill, either via the browser’s own auto-fill feature or a program like 1Password, to enter login credentials, and if the auto-fill doesn’t work (as it wouldn’t in the case of a faked login page because the domain wouldn’t match), close the tab, access the site again from a bookmark or manually typed URL, and try again.
- Create bookmarks for sites that require logins, and always use your bookmark to visit those sites. Even if you see a login form just waiting for you in a tab, load your bookmark instead.
- Better yet, make site-specific browsers for sites that require logins to protect sensitive data, and use those sites only via their site-specific browsers. A site-specific browser enables you to turn any Web app into a standalone Mac application with its own windows and menus and Dock icon. For instance, I have a site-specific browser for Google Docs, and another for the Manymoon project collaboration site. The main site-specific browsers I know of are Fluid, which relies on Apple’s WebKit and thus works like Safari, and Mozilla’s Prism, which works like Firefox; both are free. As an added bonus, using site-specific browsers reduces the confusion that can
occur when you have too many tabs open; it also lets you think of and interact with a Web app like any other desktop application.
- Use a dedicated client for login-based sites where possible. This is merely an extension of the site-specific browser suggestion, but there are dedicated applications for certain Web sites, like Mailplane for Gmail and Waveboard for Google Wave. If you like the idea of breaking Web apps out into Mac applications, why not get extra features from a dedicated client?
Meanwhile, back at the conundrum I posed at the beginning of this article, what is a good guy who discovers such a trick to do? This isn’t the same as finding a browser bug that enables a security exploit, since in that case it makes sense to report the bug privately so the browser maker can fix the bug before the bad guys exploit it. Browser makers don’t always do this quickly enough, but that’s the theory.
In this situation, though, the browsers are acting largely as they’re supposed to, which is why tabnabbing works across multiple browsers. Similarly, the CSS browser history leak isn’t new, and it too works across multiple browsers. So I suppose that full public disclosure, as a way of encouraging multiple browser makers to agree on ways of blocking these vulnerabilities, does make the most sense, especially in situations like this, where user education is the best defense. Consider yourself educated, and do what you can to encourage Apple and Mozilla and the others to prevent tabnabbing.
Still, it does make one long for the early days of the Internet when it wasn’t necessary to worry about such things.
I very rarely follow one link to another from the same tab, only to then open up a new tab when I feel the need to. What I normally do is to use the command key in order to open a new tab when following an interesting link, say.
…So, for me, it's normally always one tab per new link, as I rarely link from one page to another. Still, if I were to command-link to a malicious script enabled web site surely this script could not record the history of links from the other tabs.
It's not the history of of links from one tab that's important, it's merely leaving a tab containing the malicious script open, which would be happening in your usage approach, unfortunately. The more tabs you open and leave open, the more likely you are to be vulnerable should this exploit go wild. (And I'm really in this group - I have tons of tabs open all the time.)
"it's merely leaving a tab containing the malicious script open, which would be happening in your usage approach, unfortunately."
...Ah, but I don't. That's just it! As I said, I mostly always create a new tab when following a new link. What I didn't say is that I kill 'em once I've done with 'em. So, it would be unlikely for me to have a whole heap of (mixed) tabs open.
This article mentioned two very different things; one about this 'tabnabbing' thing, and something about the tabnabbing script taking on the already understood role of faking one web site for another through the use of link history and identification, and that's why I mentioned its history. :)
And anyway, I generally search for one specific thing, and though it may be that I'll have a whole heap of tabs open at once it would still be odd to find oneself logging into one's email account, say. :)
Might be an idea to use two browsers if one get's too worried about what this script could or would do. ;)
Yes, if you close tabs after using them, you wouldn't be vulnerable. Although the question then is, are you gaining much from tabbed browsing in general?
Yes, I believe I do. Having one's own web site (with reputable sources, like this) in which to hop off in different directions allows me to have open only those tabbed links that I trust, and to delete, or to highlight and copy those that I've done with.
Btw, I use a number of Firefox add-ons; 'Yooper' to highlight stuff, and a combination of 'Pixlr Grabber' and 'Screengrab!' to copy stuff I don't intend to hang around for. :)
Thanks for the heads up. This is the first I've heard of this. I will be very careful now, making sure I close a tab and never entering my id and password in a tab I haven't just opened.
I wonder if a "SneakyPage" would be fooled by 1Password?
I think it would be, since 1Password (as far as I know) keys off URL, and I don't think the URL changes in this sort of attack. I'll ask them.
The "SneakyPage" cannot fool 1Password because the URL of the page does not change. Since 1Password only allows Logins to be filled if their domain matches the current page, you would not be able to fill any.
Just realize that who's fooling whom has been a bit confusing in this thread.
To be clear, 1Password and other auto-fill features won't work on a SneakyPage because the domain won't match what's expected. And if they don't work, that's a hint that the page is not what it seems. That said, they won't warn you that there's a problem, either - they just won't auto-fill.
I've added a bullet point above noting that auto-fill features and utilities are another line of protection against tabnabbing (and one that makes life easier!)
This isn't just with tabs. The same thing happens if you have two browser windows.
Even with Firefox I've even tried it without changing tabs and it also does it - so it's doubly dangerous.
If you select a different window on the desktop (but NOT change tabs in the browser) the script still detect this and does the page-switch.
Very intriguing. So simple as well.
It's a concern how the less savvy are going to treat (or be treated by tabnabbing)
I downloaded Fluid. It works for many sites but not the ones I really need it to work on. Paypal, Ameritrade, and International Bank and Commerce all refuse to work in a Fluid window. Instead they just relaunch Safari with a new login window. Good security, but hardly any more convenient than opening a new window myself. Perhaps there a preference I haven't set? I don't know. There were others with similar issues on their support site but no answers posted.
Try Prism too - I've noticed that same problem with Fluid on some sites.
" Better yet, make site-specific browsers for sites that require logins to protect sensitive data, and use those sites only via their site-specific browsers."
Now *that* is cool. The Prism app gave me a certificate error which the fluidapp did not. Does anyone know if it's safe to ignore that cert error?
It's probably fine, as long as you're typing in the URL manually the first time, so there's very little chance you could be on a site attempting to mimic the real one.
It's not entirely uncommon to get certificate errors, and how they're reported to the user varies by browser.