Dec. 8, 2009

Posted by in General, Google | 2 comments

Security in Syndicated and Federated Systems

In an amusing story earlier this year, a technology news reporter writing on a particular security problem unwittingly demonstrated the issue by publishing an article. ReadWriteWeb posted a story on cross-site scripting holes on McAfee’s web site, and the article included some sample code that could be used in an attack. Unfortunately, the New York Times syndicates some articles from RWW, including this one on XSS, and at the time did not filter code in RWW reports. Consequently, the sample code actually rendered in the New York Times version of the article, producing another example of cross-site scripting.

In broad strokes, a syndicated system occurs when one application or network loads content from another (one-way) while a federated system involves two applications or networks exchanging content in a fully interoperable fashion (two-way). RSS is a syndicated setup – your reader simply loads an XML feed from the site you subscribe to. E-mail is a federated system – many SMTP servers exchange messages with each other.

Both syndicated and federated systems have to deal with a potential security problem: outside content. Any time you load data (particualrly in a web application) that’s not under your control, you need to put in filters to avoid such issues as cross-site scripting. The problem here is not a matter of trust – I’m sure the New York Times considered ReadWriteWeb a trusted source. The problem is that other sources of content may not always provide what your application is expecting. Rather than assume the data’s formatted and encoded correctly, assume it’s not and take appropriate action. This is merely one example of the type of thinking security researchers routinely employ – and a mindset developers need to use more often.

I recently came across another minor example of syndication leading to XSS. The search engine Cuil recently announced that they were launching an opt-in feature to index the posts of your friends on Facebook and include those posts in your search results. Aside from the privacy ramifications (you may be surprised to learn that settings for uninstalled apps and Facebook Connect sites don’t seem to apply to Cuil’s search results), I wondered how secure Cuil’s implementation would be in practice.

Overall, the feature seems to work like most Facebook Connect sites, and thus poses no inherent security problems. However, I did find quickly that Cuil was not encoding the results from Facebook. That is, a friend could post a status saying, “testing <script>alert(document.cookie)</script>” and searching for “testing” in Cuil would load the alert dialog. Obviously the impact of such an attack would be minimal, as it requires jumping through a few hoops first, but it again illustrates accidental XSS via syndicated content. Note that XSS in a Facebook Connect application would open the door to a FAXX-style attack.

An example of a federated system that causes me some concern is Google Wave. When I first started looking at Google Wave from a security standpoint, I admit that I did not fully understand the architecture of the product. In essence, Wave includes two distinct components – a server and a client. On the server end, Wave is an XMPP service that can communicate with any compatible setup. On the client side, Wave is the web interface hosted at for loading messages from servers.

Once I understood this division, I thought it even more important to discuss the security implications of gadgets within waves. I fully expect Google to address most, if not all, of the issues I raised regarding gadgets. (In fact, last time I checked, it appeared they had changed the domains of container iframes, stopping cross-gadget access). But if Wave really does catch on, Google’s client interface will not be the only one on the market. Since gadgets render as HTML/CSS/JavaScript, Wave clients will almost assuredly have some sort of web browser component. If the company that invented Wave did not factor in some of the security considerations I and others have noted in their original client, there’s a good chance other developers will not take into account similar issues unless people raise awareness.

However, security in Wave clients deals with only one direction of a federated system. I’m still wondering how certain aspects of federated waves will work in practice. For instance, from what I understand, each thread of messages in Wave will be stored on the server hosting the thread. What will happen if that server becomes suddenly unavailable? How will corporate record-keeping and e-discovery And while Google’s Wave servers will likely be quite secure, what about other servers?

Granted, some questions about Wave servers could be raised about similar systems, such as e-mail. But several of the decentralized aspects of Wave distinguish it from a typical e-mail setup, and could prove to be good experiments in light of proposals for decentralized social networking. I’ve long supported the idea of distributed social networking, but also felt it could lead to many performance and usability problems not found in a walled garden (I’ve been meaning to write a blog post entitled “In Defense of Walled Gardens” for at least a year). Wave may be one of the first large-scale attempts at building a distributed application somewhat akin to social networking.

  1. The issue mentioned with executing content remotely when it was sourced from another application is not a difficult problem to fix. I’ve seen this a number of times when rendering CDATA content with XSL; no matter how the content is enclosed/sanitized, CDATA and notably disable-output-escaping needs output sanitizing as well.

    I’d be interested in your brewing article, “In Defense of Walled-Gardens.” I am not for these large centralized services with user lock-in, and federation is an appealing concept, be it an old concept when we look at email. The benefit is openness and detachedness.

    I can’t say how many times I’ve wanted to post a reply to a number forums topics, but am unable without registering and logging in. The issue is, I don’t want multiple accounts on services with redundant functionality. Social networks are a great example because they generally all provide the same features, but each requires usership to interact, they are all closed communities.

    If you do write the article, I hope to see some analysis of the OpenMicroblogging specification, which imo is a decent open solution, and I think it keys on the main factor federated social system must rely on for “security” and that is the social relation opt-in. A user subscribing to another [possibly federated] user’s content is making that decision, essentially yielding authorization for a publisher to post to the subscriber’s inbox. If the publisher decides to exploit this fact, or is compromised, what is the exact security threat? I believe it varies between systems, especially when comparing OMB and Wave.

    OMB is generally rendered in one specific way, while Wave will allow self-defined rendering with widgets/html/js/css. In that light, I don’t necessarily feel the architecture is a threat, but I do think the content possibilities need a sanitizing method at a more fundamental level in the overall system.

    Federation is a long-standing, open solution, email proves that. When the concept of “walled gardens” expires and the focus shifts to federated solutions, I think we will have the right answers.

    This is why I enjoy the best open+social community, the blogosphere.

  2. Houses are expensive and not everybody can buy it. But, business loans was invented to aid different people in such kind of hard situations.


  1. Tweets that mention Security in Syndicated and Federated Systems | Social Hacking -- - [...] This post was mentioned on Twitter by Moui and theharmonyguy, SocialMediaSecurity. SocialMediaSecurity said: Security in Syndicated and Federated Systems ...
  2. Security in Syndicated and Federated Systems | Social Hacking Search Engine - [...] the rest here: Security in Syndicated and Federated Systems | Social Hacking ...

Leave a Reply