Google Gears Security Thoughts

Dietrich Kappe, Monday, June 18, 2007 @ 5:40 am

The new Google Gears comes with a long set of security warnings and disclaimers. Nitesh Dhanjani over at O'Reilly's ONLamp.com had some initial thoughts about the security of Google Gears:

If I had to pick ..., I’d guess that we are most likely to hear of existing XSS or browser vulnerabilities being abused to steal (or manipulate) Gears databases.

I agree with Nitesh: the attack vectors will remain the same, but the consequences will be much greater. Some folks, such as those working on the Dojo framework, are addressing some of the offline storage issues with encryption:

Right now Dojo offline adds a DES encryption library with functions to encrypt and decrypt. The example used encrypting/decrypting SSNs. He also pointed out that doing this in javascript can be computationally intensive and hasn’t been that feasible before. Right now though using Google Gears worker threads they can encrypt/decrypt in javascript at about 80k/second.

You could also roll your own from  this implementation of AES, RC4, RSA and a number of other algorithms. While this approach solves the stolen laptop problem, it doesn't solve the XSS problem, i.e. as long as you can inject Javacript into a page, you can bypass this security. After all, the plain text has to pass through the sandbox, where it is fair game. In this case, Google Gears just papers over the shortcomings of browsers.

It is possible that WorkerPool could be used to limit the kinds of modifications that are made to the encrypted data:

The WorkerPool behaves like a collection of processes, rather than threads. Workers do not share any execution state.  Changing a variable in one worker has no effect in any other worker.  And created workers do not automatically inherit script code from their parents.

Members of a WorkerPool interact with each other only by sending message strings. Workers can also pass richer data types, by first converting objects to strings using JSON.

We can hide the encryption details in a WorkerPool member and communicate with it via messages. We still pass plain text data through the main browser execution context, but we can at least regulate the access to the encrypted database -- i.e. no bulk downloads or modification.

As a final thought, what's bad for ActiveX is also bad for Google Gears. The fact that the project is open source and thus not a black box, mitigates this criticism only somewhat. To make me comfortable with Google Gears, all of the XSS volnerabilities will have to be closed first.

Technorati Tags: ajax, google gears, security, dojo, encryption

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Google has always been in love with your data, and I am sure Google would definitely look into it pretty soon. I am sure you would like to comment on the Privacy and Security( http://www.dekoh.org/wiki/view/PrivacyAndSecurity )of Dekoh too.

   Comment by beyondwww, Monday, June 18, 2007 @ 7:22 am

Leave a comment