A couple of security vulnerabilities with Google lately illustrated how serious HTML injection, cross-site scripting and cookie theft can be… when the cookie is the Google cookie. This got some of us thinking.
Let me start out by saying that I think Google’s security, past and present, is very good. HTML injections are very common on many websites, but very rare on Google’s server. (Plus, all of this is not a Google-specific problem; it’s the problem of any future web office, or “web operating system” – nevermind who’s implementing it.)
However, it starts to show that Google, by integrating more and more services on Google.com*, all able to share the same Google Account sign-in, is also exposing its users to growing risks. (The exploits mostly require us to visit a specific URL – but who really checks every Google URL they visit, only “trusting” whatever they bookmarked?) And no security team is perfect; if we’d hypothetically assume a 95% security on average web applications, and a top-notch 99.99% perfect security on Google web applications, that still leaves us with that remaining 0.01% chance people can inject code into Google to get hold of your Google cookie, and then access some of your Google data.
At this moment, much of the data Google stores for us seems trivial. Who’s really using Google Docs & Spreadsheets for important data? Well, I know some of us are, but not that many yet. Also, many Google services only expose rather non-sensitive data on you in the first place; your Google Reader reading habits, or which modules you included on the personalized Google homepage, are probably nothing top secret. Some services, on the other hand, contain very private information – like Gmail, which interestingly enough was seemingly successful in providing cookie theft counter-measurements. Or your Google search history.
What I think may be more important than single security incidents though (except for their ability to educate us on the problem) is the general architecture of the “Google Office” – its potential future risks, once more of our data is contained within it, and once more of its services are cross-integrated (for example, the integration of Gmail onto the personalized homepage resulted in an additional privacy problem when someone was able to reproduce your Google Account cookie). In fact, now may be the last good time to discuss these things before the Google Office goes into production full steam.
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?
What are your thoughts?
*For example, when you enter www.gmail.com, you’ll be redirected to gmail.google.com. This way, Google is able to better cross-integrate their services; they can always access the same cookie if they want to. On a side-note, Google’s architecture also often allows you to just replace the sub-domain you’re on, and the application will still work; you can simply change news.google.com/news to gmail.google.com/news and still view Google News. Google’s websites are very much “integrated,” and they often share data: as an example, you can enable a feature that lets you view the Google Talk chat history from within Gmail. Or, you can show off your search history trends on the personalized homepage. Naturally, these features are intended to bring advantages to users, and they’re all used by us voluntarily.
**This (see previous post) was at least the second XSS hole found with Google Base – I saw the full exploit posted in a by-the-way comment on Digg (while it was still unfixed), among other places -, another one dates back to 2005. Jim Ley argued, “I can’t understand why Google don’t have at least some security testing”, but I believe you also need to consider that Google Inc needs to manage thousands of developers. Jim demanded from Google to “host the Beta on a seperate domain.”
Tag:
Add to 
Bookmark Murdok:
Philipp Lenssen from Germany, author of 55 Ways to Have Fun With Google, shares his views & news on the search industry in the daily Google Blogoscoped.
