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.

Imagine you're browsing the Web and you end up at a particular page, call it SneakyPage. It doesn't look evil, and it may in fact be a totally legitimate site that has been compromised by a bad guy. But it contains a tiny bit of malicious JavaScript that loads with the page, and that JavaScript does nothing unless you switch to another tab, leaving the tab holding SneakyPage open.

At that point, the malicious JavaScript springs into action, replacing the SneakyPage tab's favicon, title, and page content. Remember, you're off in another tab, or even in another program, so you're not paying attention at this point.

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.

At some point later, you come back to the tab, see the login form, and decide that yes, you do want to log back in to check your email or your account balance. Once you do so, SneakyPage's JavaScript snags your login credentials for future nefarious purposes and redirects you to the actual site, so you're none the wiser that you've just fallen victim to a phishing attack.

"But," I can hear you saying, "how would the malicious script be able to guess that I use Gmail or Citibank or whatever?" The problem is that it's possible to figure out if a user has visited specific sites, thanks to the way most sites identify visited links by changing their colors via CSS. So the malicious JavaScript we're postulating could determine if you use any of a set of particular Web sites, and then fake an appropriate one. LWN.net has an article describing this browser history leak in more detail, and if you don't believe it, visit StartPanic.com for a personalized demonstration.

The elephant gun solution is to turn off JavaScript entirely, or, for Firefox users, run the NoScript extension, which enables you to block JavaScript on all sites but those you allow (Google Chrome has this capability too). Unfortunately, turning off JavaScript entirely renders the modern Web nearly unusable. And NoScript is an option only for Firefox users, and even then, many people find it - or Google Chrome's similar feature - too intrusive for everyday use.

Worse, security researcher Aviv Raff has figured out a way to simulate the exploit without using JavaScript. Brian Krebs links to Raff's proof-of-concept from his Krebs on Security blog post; it's best to start there since the proof-of-concept morphs a mockup of Krebs's post into a Gmail login screen. The NoScript extension may protect against Raff's approach as well, but regardless, the type of users who would be fooled by tabnabbing aren't as likely to be the sort of people who would be running NoScript.

So how much of a worry is tabnabbing, and what can you do? My gut feeling is that if you stick to mainstream legitimate Web sites, you have little to worry about. However, that doesn't mean that avoiding sleazy destinations like file download sites is a guarantee of safety. In September 2009, the New York Times Web site served a rogue advertisement that purported to scan for viruses. If a criminal organization was somehow able to sneak a tabnabbing JavaScript into an ad and place it on legitimate sites via an ad network, it could wreak havoc.

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.