Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
Option-Click in Scroll Bars for Jump Scrolling

In Mac OS X in general, and thus in most native Mac OS X applications, hold down the Option key and click anywhere in a window's scroll bar to jump to that spot (rather than scrolling one screen). If you like this behavior, you can make it the default in the Appearance preference pane. For "Click in the scroll bar to:" select "Jump to here."

 

 

Related Articles

 

 

Beware Tabnabbing, a New Type of Phishing Attack

Send Article to a Friend

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.

 

READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <http://tidbits.com/member_benefits.html>
Special thanks to Thierry Almy, William Stanley, Keith Holzman, and
Ken King for their generous support!
 

Comments about Beware Tabnabbing, a New Type of Phishing Attack

James Rankin  2010-05-28 16:26
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.
Adam Engst  An apple icon for a TidBITS Staffer 2010-05-28 16:39
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.)
James Rankin  2010-05-29 20:18
"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. ;)
Adam Engst  An apple icon for a TidBITS Staffer 2010-05-30 08:07
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?
James Rankin  2010-05-30 10:39
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. :)
Betty Fellows  2010-05-28 21:35
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.
Thanks again
Gary Goodenough  2010-05-29 08:05
I wonder if a "SneakyPage" would be fooled by 1Password?
Adam Engst  An apple icon for a TidBITS Staffer 2010-05-30 08:05
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.
David Teare  2010-05-30 09:59
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.
Adam Engst  An apple icon for a TidBITS Staffer 2010-06-01 07:18
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!)
David Weintraub  2010-06-03 08:45
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)

Ian
Bereanboarder  2010-06-08 11:15
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.
Adam Engst  An apple icon for a TidBITS Staffer 2010-06-10 12:22
Try Prism too - I've noticed that same problem with Fluid on some sites.
Rob Pluta  2010-06-08 15:12
" 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?
Adam Engst  An apple icon for a TidBITS Staffer 2010-06-10 12:24
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.