Calling Action Script from the DOM

There is plenty of literature already on how to call Action Script functions from the browser's DOM. The concept is simple:

1. Write the Action Script function


2. Use ExternalInterface.addCallback to register the function for scripting


3. Get a handle on the Flash player


4. Call the function

However, this is not the case when using IE. Because of a timing issue, the Action Script function is not being registered within IE; therefore producing a Javascript error. The workaround for this issue is to manually register the ActionScript function by calling __flash__addCallback(<Flash object>, <name of Action Script function>).

Flirting with browser MIME types

While reading another blog, I ran into a paper that describes how different MIME types are rendered by the different browsers. It provides a nice reference section that points out the MIME types that would force the browser to render HTML content (hence, useful in the hunt for cross-site scripting vulnerabilities).

The paper can be found here.

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.