Client-side SQL Injection Attacks
A couple of days ago, Google unleashed a new product called Google Gears. At the beginning I was sceptical about the purpose and the actual benefit of this project but I soon realised that indeed it is very powerful and it does save developers from a lot of trouble when dealing with AJAXy applications. The two most useful/interesting Google Gears (GGears) features are the relational persistent storage and the worker pool. Both of these features are quite interesting. Let's see why?
The relational persistent storage allows developers to mange databases and tables on the client the same way we do it on the server. The backend is SQLite which quite obviously supports SQL queries. Here is the problem: if user provided data is passed as part of any of the queries without being sanitized then we have a SQL Injection. This is not everything though. There are two ways attackers can take advantage of the Gears' persistent storage. The first one is through a XSS attack on the domain that makes use of Gears' persistent storage. This one is very nasty since attackers are able to control the queries that are sent to the backend. They can dump, modify and completely destroy any database or table.
The worker pool is also quite interesting and can be used for malicious purposes too. This is how Google describes the worker pool:
In web browsers a single time-intensive operation, such as I/O or heavy computation, can make the UI unresponsive. The WorkerPool module runs operations in the background, without blocking the UI. Scripts executing in the WorkerPool will not trigger the browser's unresponsive script dialog.
Google Gears is actually very useful. However, I am thinking to disable it for now. The project is still in beta, so I hope that by the time it reaches a first release some of the security problems will be resolved, although I cannot really see how that will happen since we are not talking about bugs in Gears, but fundamental insecurities that can occur by using features in unintended way by taking advantage of insecure codding practices.
Even if your SQL queries are right but you trust the user input,why would anyone trust user input? (When attempting to avoid the obvious, of course)