By now it's common news that Google has been hit by what seems like half a dozen or more cross site scripting security flaws in the past month. If you missed the news, you can read blog posts like More Google security failures and Wow, more Google XSS problems which contain links to some of the stories of recent exploits. The bugs in those blog posts aren't exhaustive, I've seen some blog posts about exploits that don't seem to have hit the mainstream tech blogs such as the one mentioned in the blog post Pending Members - Google Groups XSS Bug [Part 2].
Anyway, the fact that Google is having problems with XSS issues isn't terribly interesting and should be an expected part of the growing pains as they go from a service that doesn't store any user data to one that aims to be the repository of all their user's data. That requires an entirely different approach to security. What I did find interesting was a blog post on the Google Blogoscoped blog entitled On Google Security which stated
Today, it almost seems as if every single product team in the Googleplex has the “power” to accidentally introduce a Google Account risk with an HTML injection hole, or another kind of cross-site scripting issue. An exotic Blogger bug was able to reveal your Google Docs, even if you’re not blogging with Blogger – an improbable Google Base bug was able to reveal your personalized homepage, even when you’ve never worked with Google Base**. I would argue: these things happen, individual developers and developer teams make errors. It’s impossible not to. There are ways to automatically test against HTML injections, but such tools too need to be handled by humans. The real problem, and solution, might be on the higher level of the system architecture – the way Google integrates its services and handles cookie data. Right now, the Google Office product partly resembles a mighty convenient & long chain... a chain which is only as strong as its weakest link. Is this a trade-off we’ll just have to make with future web apps, or are there ways to improve on the situation... either by users, or those building browsers, or those developing web apps?
Today, it almost seems as if every single product team in the Googleplex has the “power” to accidentally introduce a Google Account risk with an HTML injection hole, or another kind of cross-site scripting issue. An exotic Blogger bug was able to reveal your Google Docs, even if you’re not blogging with Blogger – an improbable Google Base bug was able to reveal your personalized homepage, even when you’ve never worked with Google Base**. I would argue: these things happen, individual developers and developer teams make errors. It’s impossible not to. There are ways to automatically test against HTML injections, but such tools too need to be handled by humans.
The real problem, and solution, might be on the higher level of the system architecture – the way Google integrates its services and handles cookie data. Right now, the Google Office product partly resembles a mighty convenient & long chain... a chain which is only as strong as its weakest link. Is this a trade-off we’ll just have to make with future web apps, or are there ways to improve on the situation... either by users, or those building browsers, or those developing web apps?
Those who ignore history are doomed to repeat it. None of the problems listed are unique to Google. Any portal that provides multiple services that require the user to login is vulnerable to these problems. This includes competing portals like Yahoo!, MSN and AOL. All of these services have had to encounter and protect users against the very same problems Google is having difficulty dealing with today.
It is likely that with time, Google will stumble upon the same set of best practices that are common knowledge amongst its portal competitors who have been in the game a lot longer. Thinking that this is a problem that affects "the future of Web apps" ignores the history of the Web.
In the meantime, if you are a Web developer at Google, I'd suggest reading Chapter 12 of Writing Secure Code by Michael Howard. After that, take a look at You know about XSS. How about XSRF/CSRF? which happens to use a Google service as an example of Cross Site Request Forgery attack (XSRF).
That which doesn't kill us only makes us stronger. ;)