Google's Month of Security Flaws: "

By now it's common news that Google has been hit by what seems like half a dozen ormore cross site scripting security flaws in the past month. If you missed the news,you can read blog posts like More Googlesecurity failures and Wow, moreGoogle 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 exploitsthat don't seem to have hit the mainstream techblogs such as the one mentioned in the blog post PendingMembers - Google Groups XSS Bug [Part 2].

Anyway, the fact that Google is having problems with XSS issues isn't terribly interestingand should be an expected part of the growing pains as they go from a service thatdoesn't store any user data to one that aims to be the repository of all their user'sdata. That requires an entirely different approach to security. What I did find interestingwas a blog post on the Google Blogoscoped blog entitled OnGoogle 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 Bloggerbug 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, evenwhen you’ve never worked with Google Base**. I would argue: these things happen, individualdevelopers and developer teams make errors. It’s impossible not to. There are waysto automatically test against HTML injections, but such tools too need to be handledby 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 GoogleOffice product partly resembles a mighty convenient & long chain... a chain whichis only as strong as its weakest link. Is this a trade-off we’ll just have to makewith 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 areunique to Google. Any portal that provides multiple services that require the userto 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 sameproblems Google is having difficulty dealing with today.

It is likely that with time, Google will stumble upon the same set of best practicesthat are common knowledge amongst its portal competitors who have been in the gamea lot longer. Thinking that this is a problem that affects 'the future of Web apps' ignoresthe history of the Web.

In the meantime, if you are a Web developer at Google, I'd suggest reading Chapter12 of Writing Secure Code by Michael Howard. After that, take a look at Youknow about XSS. How about XSRF/CSRF? which happens to use a Google service asan example of Cross Site Request Forgery attack (XSRF).

That which doesn't kill us only makes us stronger. ;)

(Via Dare Obasanjo aka Carnage4Life.)

Bookmark/Search this post with:
| | | | | | | |