Apr 8, 2008

Google Gears and Information Disclosure

While reading some of the new stuff around Google Gears, I noticed a blog article by the Gears Team regarding the integration of Google Gears with Google Docs (or Office as I like to call it). It is quite interesting to see how Gears will impact the service offered by Docs. However, it also brings to question the confidentiality of the cached information.

Take for instance a simple user-based web application. The application consists of the logon page and some important user information. When Gears is deployed in this scenario, the caching can be directed via one of two ways:
  • Dynamically generate Gears manifest to reflect the user's session ID. This is usually done when the web application uses the session ID as part of the URL. Because Gears caches resources based on URL, it is important to update the manifest when the URL for a to-be-cached resource has changed.

  • Look for a specific cookie. The latest version so far (0.3.13.0) allows developers to direct the serving of a page by demanding that a specific cookie is present before the serving can occur. This is done by using the requiredCookie attribute in the Gears manifest.



What is the problem with these 2 scenarios?
Because both cases expose the problem of caching using random IDs, retrieving cached data back from Gears relies on either keeping browser history or making session lifetime longer. While the first approach is a concern only at the client, extending the lifetime of a session is generally considered a bad security practice. Additionally, it is not quite clear whether/how Gears allows developers to clear data from the local cache. As a result, anybody with local access to the browser may retrieve data that is otherwise protected by a web application.


Why this matters?
As a final note, combine all of this with a popular web application of choice and public machine such as a library/university computer or a simple Internet kiosk. I believe you'll soon get the idea.

No comments: