New forms of offline client-side storage, such as those specified by the emerging HTML 5 set of standards, could open entirely new kinds of attacks to Web application users, said Michael Sutton, vice president of security research for cloud security firm ZScaler.

"As sites start to adopt Google Gears and HTML 5, this whole concept of stealing data from client-side relational databases will become a much, much bigger issue," said Sutton, speaking Sunday at the ShmooCon hacker conference. "In my opinion [they are] a lot easier to attack."

As ever more applications are being developed that run entirely over the web, a number of new technologies have been introduced to put small relational databases on users' machines. A database on the client machine can store user data, allowing applications to be used while not on the Internet.

While such offline storage extends the flexibility of web applications, it also opens up an entirely new type of vulnerability for users, one that allows snoopers to copy and change the content of these databases, Sutton said.

Sutton examined two examples of client-side storage now gaining traction, Google's Gears and the persistent Web Storage specification in the World Wide Web Consortium's HTML 5.

Right now, only Chrome, Safari and Mobile Safari, the iPhone browser, support the HTML 5 storage specifications, thanks to the fact they all use the HTML 5-friendly WebKit browser engine.

Though Google is phasing Gears out in favor of HTML 5, it provides a glimpse of how HTML 5 off-site storage could work for most users, Sutton noted.

Gears is a browser plug-in that allows web applications to work off-line. With the user's permission, the plugin installs a copy of SQLite, a lightweight relational database, on the local machine, which applications can use to store their data.

Just as malicious hackers have harvested data from server-side databases using techniques such as SQL injection, so too could they target these client-side databases, using similar methods. In fact, accessing the client database would be easier in many ways.

Normally with SQL injection, the attacker will not know the database structure beforehand, the names of the tables and columns and datatypes. All that must be sussed out through multiple guesses. In contrast, someone wishing to fish through the database supplied by a social networking service could simply download an identical copy of the database from that service, which would reveal the database structure. The attacker could then query the tables to retrieve information.

"It really is easier from the attack perspective," Sutton said.

Also, server-side SQL injection attacks rely on websites that do not filter malformed SQL requests coming from users. An attacker can send malicious commands to the database engine, using an input box of some sort on a web page. Only without a filter in place will the command be executed on the database engine.

On the client side, no such elaborate technique is needed. "I don't need a vulnerability in the way a traditional SQL injection would work," Sutton said. Instead, the attacker can just issue standard SQL queries to gather information.

Although now still largely theoretical, such attacks may prove to be a significant problem in the years to come. "This isn't a passive sniffing, this is active. I don't have to wait for the information that I care about, I can actually query the database," Sutton said.