Vulnerabilities in HTML 5 and Future

HTML 5 comes with alot of promise for the web.  It has lot of new features that could make Web Browsers and Apps much more powerful than they ever were.

Let’s go by an example. Try accessing Gmail on iPhone or Android phone,  you will have notice some differences from what it used to be a month ago. The new thing worth noticing is the introduction of the offline access.

Gmail went down, offline in September, but credits to Gears, Gmail was still up and running with select Browsers. On the other side, iPhone Safari doesn’t have a Gears plugin, so how was it still running?

The answer lies with the HTML 5 standard, more specifically: the local database storage. Though HTML 5 is still in-progress, WebKit powered browsers, such as Safari, Mobile Safari, (and Firefox) have already adopted local database storage. This opens a new door of opportunities for developers to create and innovate subsequently to read from/write to a fully capable: Locally stored, Relational SQL database via the web browser itself.

Current Gmail’s iPhone release is the first web app that I’ve seen using the technology.

I foresee offline-access as an important feature for NextGen web applications: for speed and availability. Like Google believes with Chrome OS , we have, practically, continued to decrease the gap between desktop apps and their web  counterparts using technologies such as AJAX, Flash, JavaFX, Silverlight, etc. which have continued to push the hard limits.

But, despite all of the added functionality, web apps suffer from inherited old limitation – They don’t exist when you go off the line. Well, that’s about to change with HTML 5.

HTML 5 App with Local Storage:  Gmail

The iPhone doesn’t allow raw file access(I’m talking of Virgin iPhone), I’ll demonstrate Gmail’s use of HTML 5 via Safari on a standard OS X platform. First thing first, in order to get Google to serve the HTML 5 version of Gmail, we’ll change the User-Agent of our PC to match that used by the iPhone.

To fake iPhone’s Safari using Safari in Windows or Mac,  In Safari, click on Preferences, then go to Advanced tab. Check the checkbox for Show Develop menu in menu bar option. Exit from the Preference dialog window, a new “Develop” menu will show in the menu bar. Click on Develop, and then select User Agent in the pull down menu. Click to select Mobile Safari 3.0 – iPhone. Here is the resultant User-Agent:

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

Now next time we visit Gmail, the iPhone specific version of the app opens. And, the local database storage is automatically setup.

One thing that raises concern here is that the end-user is NOT informed of this. Data is being stored locally in plain text, and user is un-aware.  On the other side, Gears will at least mandate the end-user to acknowledge before it actually makes a copy of data, offline. The phone will carry a local copy of their email, which could be accessible to just anyone, if the phone was ever lost.

Now let’s see exactly what has been stored locally. The database is set up in the following location:

Windows: C:\Users\taranfx\AppData\Local\Apple Computer\Safari\Databases\https_mail.google.com_0\0000000000000001.db

Mac: /Users/taranfx/Library/Safari/Databases/http_mail.google.com_0/0000000000000001.db

New databases will be created for each separate Gmail account logged-in, each one gets an incremented number instead of “1” that you see over there.  Now you might be thinking Which Database is that? It’s SQLite database. Surprisingly, there is no encryption, no protection, the database content can be viewed with any SQLLite compatible app: I used SQLite Browser. And the Results were alarming:

1. cached_contacts – Top 20 frequent contacts, including email address, names
2. cached_conversation_headers – Abbreviated content from email messages including the full subject, sender’s name and first sentence or two of the message.
3. cached_labels – User defined labels which can be assigned to emails.
4. cached_messages – Similar to cached_conversation_headers
5. cached_queries – Certain queries
6. unclearconfig_table – Application version number
7. hit_to_data – ??
8. log_store – Some logging info.

All are  shown in the screenshot below:

Now if someone gets access to your machine or mobile, you can guess the level of risk you are under.

Verdict:

Gears and HTML 5 represent great technologies, but  poorly implemented, and hence result in increased security risk.

Applications interface with local data storage via JavaScript API calls.  The calls, as per the specification,  are  restricted by the same origin policy to ensure that only the application which originally created the data, can then subsequently access it. When sites are vulnerable to XSS vulnerabilities, a remote attacker could gain access to local database storage and perform any type of  client-side SQL injection attacks.

Gmail might be currently suffering from any XSS vulnerabilities, as they had numerous times in the past. What’s more critical is the fact that XSS remains a too-common vulnerability and as developers adopt local database storage via HTML 5, we are sure to see plenty of vulnerable sites, which will place everyone at risk.  It is not just a privacy concern, it’s also a data integrity concern: What if an attacker can manage to write to the database just as easily as they can read from it?

Nothing more or less, I feel that the HTML 5 specification has a great deal to offer and it’s good to see it’s early adoption. But the fate of the game lies in the hands of the developers , who will have to ensure that powerful features such as local database storage do not expose end-users to increased threat.