Category Archives: followup

I just received confirmation from the Google Security Team that the bug I discovered in the iGoogle Facebook Gadget which allowed attackers to log into an other user’s Facebook account bypassing all authentication, has been fixed. So now that the hole has been closed, let’s look at what was happening, shall we?

The gadget uses the Facebook’s Javascript API to the connect with Facebook, asking you for permission to access your FB data. In the process of getting that authorization, the gadget exchanges tokens with Facebook, some of which should absolutely be kept safe from prying eyes. And that’s where things went wrong: the gadget had the authentication info in the URL. So if a user of the iGoogle Facebook gadget clicked a link to an external site in the news feed, the request for that page had a referrer that contained all authentication-info.

And that’s exactly what happened on last week, when I spotted this referrer in my blog stats:

You can guess what happened when I opened that URL; the iGoogle Facebook gadget initialized using the embedded credentials, automatically logging me in as the guy that was unlucky enough to have clicked the link to my blog.

But how could this vulnerability have been exploited, you may ask? Well, easy enough; create a page that is viral enough for people to share or like (likespam or even likejacking) and wait for users of the iGoolge Facebook-gadget (there’s over 1 million of them after all) to follow the links, feeding your webserver logfiles with credential-rich referrers.

As Google confirmed this bug indeed has been fixed. The new version of the gadget, which was deployed late last week, does not leak credentials in the referrer-URL any more:

Next on my list was getting the “shared folder“, which I configured in Virtualbox (look ma, no samba), to automount in my Ubuntu-guest with read-write permissions for my non-root user. I ended up adding this line to /etc/fstab (the dmode and fmode-options did the trick eventually):

Up until version 2.7.1, running WordPress on an intranet was a real pain in the ass. It connects to the outside world to look for updates, to check comments for spam (using Akismet) or to fetch RSS-feeds for widgets if you configured those on your blog, … But as you typically don’t have direct internet-access on an intranet and as there was no way of letting WordPress know about a proxy, your blog timed out while it was trying to fsockopen those external sites.

Off course some WordPress-plugins do not use the HTTP API yet (e.g. Lifestream and wp-security-scan rely on Simplepie, which does not use the proxy-aware wp_remote_get-function), so you might have to be careful when installing plugins that need internet-access.

the title and favicon of the most recently closed tab, allowing you to reopen it

a button containing the text in your copy/paste-buffer with contextual actions;

if URL: go to that site

if physical address: put it on a map

else: search for that text on google

more actions might be added and the system will be extensible, taking from Ubiquity

a list of six of your most visited sites, with thumbnail and title and with the most recent rss-items of that site

Although the developers claim that it’s “a rough-cut prototype” and that “the visual design isn’t right”, I already prefer this sober and functionally rich new-tab-behavior over the shiny “top sites” implementation in Apple’s Safari4. I sure hope this will slip into Firefox 3.5 in the next few months!