Thursday, February 19, 2009

Practical Example of csSQLi Using (Google) Gears Via XSS

Comment: I would like to go out of my way to thank Paymo.biz for the professionalism that they displayed in promptly responding to vulnerabilities brought to their attention to ensure that their users were protected. Within 24 hours, they had responded to my initial communication and shortly thereafter were sharing proposed protections which were then quickly implemented on production systems. Web application vendors can learn from their example.

Yesterday, at the Blackhat DC security conference, I spoke about the dangers of persistent web browser storage. Part of the talk focused on how emerging web browser storage solutions such as Gears (formerly Google Gears) and the Database Storage functionality included in the emerging HTML 5 specification, could be attacked on sites with existing cross-site scripting (XSS) vulnerabilities. The overall message is that while such technologies have built in controls to protect against attacks such as SQL injection (SQLi), when secure technologies are implemented on insecure sites, protections become meaningless.

Both Gears and HTML 5 Database Storage, permit web applications to store content in local relational databases, which reside on the local file system by leveraging the SQLite database format. This provides powerful functionality as web applications can now be taken offline as was recently done with Gmail. At the same time, it adds a new attack vector as persistent data can now potentially be attacked on the desktop, not just the server. Given that we're dealing with a relational database, is client-side SQL injection (csSQLi) possible? Unfortunately, the answer is yes and it's not simply a theoretical attack, it's very practical thanks to the significant prevalence of XSS vulnerabilities.

Both Gears and HTML 5 Database Storage leverage client-side JavaScript to create and interact with local databases. Therefore, if an XSS vulnerability is present, it's all too easy for an attacker to compromise the confidentiality and integrity of locally stored data by reading from or writing to the local database. Web applications with local databases via HTML 5 are presently rare due to the fact that only WebKit based browsers have implemented the functionality (i.e. Safari). This however seems poised to change with recent announcements that offline Gmail access is being developed for the iPhone and Android based phones via HTML 5 Database storage. Gears enabled applications on the other hand have already started to spring up and csSQLi has therefore become a reality.

Paymo.biz, a time tracking application was previously vulnerable to csSQLi due to the existence of XSS vulnerabilities on the site. The associated image details how JavaScript could be injected to read from the local database and in this proof of concept simply write the data to an alert box. Step #1 is specific to this situation as the XSS injection point occurs within paragraph tags which need to be closed. Gears is a JavaScript API, so in step #2, the API is included in order to expose necessary functions. In step #3, the local database is opened. In traditional (server side) SQLi the database structure must first be determined either through error messages or other brute force means. With csSQLi this is not a challenge since the database structure is exposed. To determine the names of tables, columns, etc. an attacker simply needs to first access the application himself to establish a local copy of the database on his own machine. Executing the SQL statement is conducted in step #4 and once again csSQLi is far less challenging than a server-side SQLi attack. Thanks to having XSS facilitate the attack, the SQL command can be composed from scratch - no need to inject commands into the middle of an preexisting SQL statement. The results of this particular injection can be seen in the associated screen shot which simply displays default data from a newly configured database.

While Gears has not yet been widely adopted, I expect this to change in the coming months, especially with the exposure that the technology will receive thanks to recent integration with Gmail. As users recognize the power of being able to take web applications offline, developers are sure to investigate adding Gears to their own applications. It's important to note that this attack has nothing to do with insecurities within the Gears technology itself. As mentioned, the attack is made possible when Gears is implemented on a site with existing XSS vulnerabilities. Unfortunately, XSS is a vulnerability which is far too prevalent on the web today. As such, it is inevitable that we'll see sites vulnerable to csSQLi. I hope that this early example illustrates the risks associated with offline browser storage and the importance of ensuring overall application security before adding this powerful functionality. Don't avoid Gears...embrace it...but do so securely.

A full copy of the slides from my talk entitled A Wolf in Sheep's Clothing - The Dangers of Persistent Web Browser Storage is available here.

- michael

6 comments:

Acidus said...

Ajax Security, Chapter 9 "Offline Ajax Applications," page 260 (and a little of Chapter 8, "Attacking Client-side Storage")

:-)

This is excellent work Michael, far beyond what Bryan and I came up with. Great job!

Michael Sutton said...

Thanks Billy. Your work was also referenced in a great paper on HTML 5 abuses entitled Abusing HTML 5 Structured Client-side Storage which served as a valuable resource for the research.

freakface said...

The next question I would want to ask is can the exploit be used to attack other Gears databases on the same client? Can gmail, or docs, or calendar be compromised by a hacker who is embedding malicious code into a site that appears to be hosting online games, for example?

Michael Sutton said...

freakface - fair question. Fortunately, Google seems to have done a good job of enforcing a same origin policy as I'm not aware of any attacks which would permit such access.

Anonymous said...

First I would like to say your presentation of this security lapse is sober and sensible. But question the assertion about the discrepancy of risk between client-side and server-side XSS.

Many a RIA system will volunteer data to the client browser via a simple to deduce ajax URL api.

So having injected malicious JavaScript into the client the hacker can either raid a client-side SQLite DB with prior knowledge of the schema or construct a server data ajax request.

You are correct in saying the hacker probably has zero knowledge of the DB schema on the server, but the ajax api will provide data anyhow.

Is the Gears discrepancy of risk as great as your article claims?

Michael Sutton said...

Anonymous,

Thanks for the feedback. To correct one point, you mentioned client-side (cs) vs. server-side (ss) XSS. This attack doesn't actually leverage csXSS, rather it leverages ssXSS to conduct csSQLi.

Your point about insecure AJAX having the ability to leak ss data is fair - I've certainly seen many applications where this is the case. What is accessible in such a case is really application dependent though. One insecure AJAX call does not necessarily mean that you can read the full data set on the server side.

Likewise, the risk posed by csSQLi is dependent upon the application that is being attacked. If the DB stores otherwise public data the risk is minimal. If however it stores email, passwords, financial data, etc. the risk can be significant. Lastly, while risk is application dependent, in general, when ssXSS exists in a Gears enabled site, the entire csDB is accessible, and understanding DB structure is a trivial challenge.