Bestehen Bedenken im Hinblick auf VPN-Sicherheitslücken? Erfahren Sie, wie Sie von unserem VPN-Migrationsangebot inklusive 60 Tagen kostenlosem Service profitieren können.

Zscaler Blog

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Abonnieren
Security Research

Gmail And HTML 5

image
MICHAEL SUTTON
April 07, 2009 - 4 Lesezeit: Min

If you accessed Gmail today on your iPhone or Android based phone using a web browser, you will have noticed some differences. It has a few more bells and whistles but of particular interest is the addition of offline access. Gmail went offline a few months ago thanks to Gears (formerly Google Gears). Mobile Safari on the iPhone doesn't however have a Gears plugin, so how was this accomplished? The answer lies in the yet to be finalized HTML 5 specification and specifically the client-side database storage functionality that it calls for. While HTML 5 remains a work in progress, WebKit based browsers, such as Safari and Mobile Safari have already adopted database storage. This permits developers to create and subsequently read from/write to a fully capable, locally stored, relational database which is accessed via the web browser. I view today's Gmail release as a watershed moment for offline web applications as this is the first mainstream web application that I've seen using the technology.

I view offline access as an inevitable next step for web applications. We have continued to blur the line between desktop applications and their web based counterparts. Technologies such as AJAX, Flash, Silverlight, etc. have continued to push the limits on what browser based applications are capable of but despite all of the added functionality, web apps suffer from one inherent limitation - they disappear when you go off the grid. Well, that's about to change.

Local Gmail Storage

Since the iPhone (un-jailbroken) doesn't permit raw file access, I'll walk through Gmail's use of HTML 5 via Safari on a standard OS X platform. First off, in order to get Google to deliver the HTML 5 version of Gmail, we'll change the User-Agent header to match that used by the iPhone as follows:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20

Now when we visit Gmail, the iPhone version of the app is displayed. At this point, local database storage has automagically been setup. One concern that I have here is that the end user is not informed of this. Gears will at least require the end user to acknowledge that a local copy of data is being set up. While I'm not a fan of leaving security decisions in the hands of the average end user, I do feel that users should be informed that they're now carrying around a local copy of their email, which could be accessible if their phone were ever lost.

Now let's see exactly what has been stored locally. On OS X, the database is set up in the following location:

/Users/[username]/Library/Safari/Databases/http_mail.google.com_0/000000000000000x.db

Separate databases will be established for each separate Gmail account accessed, with each receiving an incremented numerical value. The database leverages the SQLite format. As such, database content can be viewed with an application such as the SQLite Database Browser. Below are details the tables that are created, along with a description of the data contained within:

 

  • action_queue - Purpose unclear
  • cached_contacts - Top 20 contacts, including email addresses and names
  • cached_conversation_headers - Abbreviated content from email messages including the full subject, sender's name and first sentence or two of the message
  • cached_labels - User defined labels which can be assigned to email messages
  • cached_messages - Similar to cached_conversation_headers
  • cached_queries - Purpose unclear
  • config_table - Application version number
  • hit_to_data - Purpose unclear
  • log_store - Purpose unclear

Security Concerns

I've commented in the past that Gears and HTML 5 represent fantastic technologies but as with most new technologies, when poorly implemented, they can lead to increased security risk. Applications communicate with local data storage via JavaScript calls. The calls are restricted by a same origin policy to ensure that only the application which created the data, can then subsequently access it. However, as I demonstrated at Black Hat DC this year, when sites are affected by XSS vulnerabilities, a remote attacker could gain access to local database storage and perform client-side SQL injection attacks. Now fortunately, I have no reason to believe that Gmail is currently suffering from any XSS vulnerabilities, but they certainly have numerous times in the past. What I'm more concerned about is the fact that XSS remains an all too common vulnerability and as other developers adopt local database storage either via Gears or HTML 5, we are sure to see plenty of vulnerable sites, which will place end users at risk. This isn't just a privacy concern, it's also a data integrity issue as an attacker can write to the database just as easily as they can read from it.

Overall, I feel that the HTML 5 specification has a great deal to offer and it's encouraging to see some early adoption. It will be up to developers to ensure that powerful features such as local database storage do not unnecessarily expose end users to increased risk.

- michael

 

form submtited
Danke fürs Lesen

War dieser Beitrag nützlich?

dots pattern

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Mit dem Absenden des Formulars stimmen Sie unserer Datenschutzrichtlinie zu.