14 DAY TRIAL // On Tuesday, Google announced that a revamped Gmail engine for iPhones and Android-enabled devices had been deployed, the most significant change being e-mail offline access/caching. This is achieved by employing the new HTML5 client-side database storage API and, as a result, could be vulnerable to attacks instrumented via cross-site scripting.
"And if the data network drops out on you, rest assured that Gmail won't. You'll still be able to open recently read messages and to compose over a flaky, or non-existent, network connection," Joanne McKinley, engineer at Google Mobile, writes. Now, that's pretty impressive, considering that we're speaking about Gmail as a web-based service running in the browser.
Michael Sutton, vice-president of security research at Zscaler, a provider of cloud security solutions, points out that the new Gmail offline access feature leverages on the client-side database storage API introduced by the new HTML5 specification, the next version of the World Wide Web's core language.
However, even if the specification is still in drafting stages, parts of it have already been implemented in some browser engines. Such is the case with WebKit, the engine developed by Apple for its Safari browser, which supports the new client-side database storage API. This allows webmasters to create and read from local databases inside the client operating systems.
"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," Michael Sutton says. "I view offline access as an inevitable next step for web applications," he adds.
Tricking Gmail into believing that it is being accessed by an iPhone, by modifying the User-Agent header sent by Safari running on a standard OS X, allows for a deeper inspection of the mechanisms at work. The new Gmail engine creates a database in SQLite format for each e-mail account accessed of the form 000000000000000x.db, stored under Safari's Databases/http_mail.google.com_0/ folder.
The database tables reveal what kind of information is being cached. For example, cached_contacts contains the top 20 contacts, including email addresses and names. Abbreviated content from email messages, including the full subject, sender's name and first sentence or two of the messages, is stored in cached_conversation_headers, full messages in cached_messages and assigned e-mail labels in cached_labels.
All this data is accessed by Gmail via JavaScript calls, which, as Mr. Sutton explains, "are restricted by a same origin policy to ensure that only the application which created the data, can then subsequently access it." That's all good and nice, but could someone, somehow, by-pass this restriction? Well, apparently yes. By exploiting a simple cross-site scripting (XSS) weakness, an attacker would be able to trick the browser into "thinking" that requests to the local database come from Gmail.
Now, Gmail is no stranger to XSS, as it suffered from such flaws multiple times in the past and this could just as well happen in the future. Additionally, as Michael Sutton points out, the fact that users are not asked about this local database being created on their devices is another questionable behavior.
"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," the researcher notes. "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," he concludes.
