Widgetjacking: Why more social widgets mean less secure Wi-Fi

See how your Facebook, Google, and other accounts can now be broken into through social widgets and see a new feature in Disconnect that protects you. Get Disconnect and the feature on our homepage.

Two years ago, a Firefox add-on named Firesheep demonstrated the longstanding trouble with Wi-Fi security. Eavesdropping on wireless traffic was and is probably the biggest security threat to most web users.

Wireless eavesdropping

When you connect to a wireless network, your computer or mobile device sends and receives data similarly to a radio. Unless the data is encrypted by the network or sites you go to, anybody else with access to the network might be “tuning in” to view your search history, read your email messages, steal your credit-card info, and so on.

A wireless network can add encryption by using one of a few different security protocols, but these protocols have proven easy to defeat and public Wi-Fi like at a coffee shop, library, or airport uses none of the above. Sites can add encryption by using the HTTPS protocol rather than HTTP, but only login pages tend to require HTTPS (so that usernames and passwords are protected).

Because a site will set cookies to authenticate you after you log in, an attacker could just capture your cookies when you visit an unencrypted, non-login page then break into your account with them. This attack is called “session hijacking” or “sidejacking”.

Sidejacking drew mainstream attention when Firesheep came out. Since then, things have gotten better and worse.

After Firesheep

On one hand, a larger chunk of wireless networks support encryption and the stronger WPA2 protocol in particular. Google and Twitter started to switch HTTPS on by default and Facebook on optionally (although lots of major social sites including YouTube, Yahoo, and LinkedIn still have minimal HTTPS coverage).

On the other hand, the shift to “cloud computing” has changed the makeup of the web. The advertising, analytics, content, and social business of sites is being passed onto third-party services, creating a new and increasing attack vector for the bad guys to exploit.

A new attack vector

Last year, I gave a talk at the DEF CON security convention about the prevalence and consequences of social widgets. My research indicated widgets from facebook.com could be found on 33 percent of the top 1,000 sites, from google.com on 25 percent, and from twitter.com on 20 percent.

According to BuiltWith, which unsurprisingly tracks what technologies sites are built with, Facebook Like buttons are up 63 percent in popularity year over year across the top 10,000 sites, Google +1 buttons up 33 percent, and Twitter Tweet buttons up 35 percent. (I aggregated widgets by domain and BuiltWith doesn’t, so comparing my numbers to theirs is fruitless except to suggest widget integration is trending up and to the right).

At DEF CON, I walked through the privacy pitfalls of social widgets. But in light of their expanding footprint, widgets also turn out to have a serious security pitfall.

You used to be able to avoid getting sidejacked by not going to sensitive sites when connected to public Wi-Fi or an otherwise insecure network. Now, widgets are part of so many sites that the threat has been spread all over the web.

Besides being widespread, widgets are usually embedded without HTTPS and unencrypted widgets leak your cookies the same way unencrypted pages do. I.e., your accounts on Facebook, Google, et cetera can be hijacked through social widgets even without you going to these sites.

An attacker could, for example, take control of your Facebook, YouTube, and LinkedIn accounts if you view nothing but a TechCrunch page (such as this one this one). As an analogue to sidejacking, we call this attack “widgetjacking”.

We put the video above together to show how the attack can be done and how a security feature we’re releasing in Disconnect works to defend against an attack. We tried to fully disclose the vulnerability without creating a tutorial for would-be attackers by leaving some bits out of the video and we don’t recommend reconstructing the attack yourself except with consent (in the United States, at least, intercepting Wi-Fi signals may be considered wiretapping.)

The “Secure Wi-Fi” feature will upgrade the major sites in Disconnect and their widgets to HTTPS whenever possible so your data is encrypted. See the video and our FAQs to get details and see our homepage to get Disconnect and the security feature for Chrome, Firefox, or Safari.

Firesheep’s developer wrote that “websites have a responsibility to protect the people who depend on their services” by enabling HTTPS and that “they’ve been ignoring this responsibility for too long”. Two years later, there aren’t good arguments against HTTPS anymore, social widgets are putting users at greater risk, and HTTPS is overdue to be made the default.

Update (November 20, 2012): We rolled “Secure Wi-Fi” for Safari back due to a performance bug on startup. We should have a fix to push soon, so make sure you’re autoupdating as per this FAQ.

Posted by Brian Kennish
This entry was posted in News and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

18 Responses to Widgetjacking: Why more social widgets mean less secure Wi-Fi

  1. Wvillage says:

    Great article and a must have for anyone who have kids. Any ballparks on a time line for Disconnect on smartphones and tablets? Kid-safing these devices are a nightmare but digital-stalking is truly scary.

  2. Thilo says:

    Great article, but one mistake. If you have switched on HTTPS within Facebook, then this does not work. Because there are 2 cookies (c_user, xs), which then are only sent over HTTPS, even when the widget is just using HTTP. The Javascript then takes care, that the connection is forwarded as an HTTPS request, which is enforced by Facebook.

    I did not tested it with other widgets.

    • If you’re opted into “Secure Browsing” on Facebook, your authentication cookies get encrypted (i.e., they aren’t leaked). That’s why sites that authenticate and, even more, sites that syndicate their content should always use HTTPS. Till they all do, we think supporting the “Secure Wi-Fi” feature to force them to require HTTPS makes sense.

  3. Cloud says:

    Just a quick question. How do you enable secure wifi feature in safari? There is no option for me to enable that or it automatic enable it?

  4. Jim Fenton says:

    Great that you highlighted this vulnerability. Hope that it will get some of the lagging sites like LinkedIn and others you mentioned to implement HTTPS more widely.

    I have also been concerned that some sites’ cookies are sent over any type of connection and should be set to be sent only for encrypted connections. At least some of Facebook’s cookies are set for encrypted connections only, which indicates they might be doing the right thing there but not knowing how the cookies are used, it’s hard to tell. Is anyone watching this cookie attribute? Otherwise, it’s possible that an attacker without your extension might snag a cookie prior to the HTTPS redirect.

    • We’ve looked at a few sites that give users the option to always use HTTPS and they seem to set the secure bit for authentication cookies properly. These sites do still leak user data through other cookies, but nothing too sensitive (just things like language preference).

  5. sonicoliver says:

    Hey, I think your site is down?

  6. Andreas F says:

    Hi Brian

    Heard about this on http://twit.tv/show/security-now/386

    I would want my browser to (optionally) refuse to send unencrypted those cookies that were retrieved over an encrypted connection. Is that possible with a modern browser?

    Best regards,

    • Cool.

      Sites that support SSL *should* be setting the secure bit, which tells the browser to do what you propose, on their sensitive cookies. Unfortunately, many sites don’t and forcing them to (some other extensions do) often breaks these sites.

  7. Czerno says:

    Websites (and prescriptors as well) please never forget that some people have to or want to browse using HTTP (not S) /only/ !

    So, please do NOT try to enforce HTTPS unless confirming the user’s browsing in recognised, and HTTPS capablen browser (through user-agent, for instance).

    The “HTTPS everywhere” motto if applied indiscriminately is a BAD thing eve, if under good intentions.

  8. Mark Longson says:

    Is there a way to tweak the google app a little. If Im on Facebook and try to view an embedded video it will not display it, which proves the app is working. so my question is does a cookie get sent to youtube(google) along with my gmail log in cookie?

    If not can there be options like on no script to allow certain sites or would that defeat the full operation of google disconnect?
    I how you understand what I am asking?
    Cheers Mark

  9. Thanks a lot for sharing this with all folks you actually know what you’re talking approximately! Bookmarked. Kindly also consult with my site =). We will have a hyperlink alternate agreement among us

  10. hellothere says:

    Thanks for the article. The endcryption of Cookies can hide the person identity from snoopy but how about if the snoopy know the identity of the victim ex: Facebook name / email address? the attacker can masking himself to log in to victim account too.

    Most website didn’t put the ability to automatic close a session if two account lo-gin detected maybe because they assume it as different application (ex: browser & application ) especially if it came from one ip-address (public WiFi). Neither they use diff password for diff device/app.

    As I know, only Paypal and Google implement this ability.

  11. Amazing overcom! I will apprentice all at once while you fix your internet site, exactly how could possibly i signed up for the web site web-site? The account assisted us a suitable offer. I’ve been slightly comfortable in this your current broadcast provided vivid translucent idea

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>