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 wave.google.com 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.