Attacking Local Browser Storage

CrazyCanucklehead writes "At the Blackhat security conference in Washington, DC, researcher Michael Sutton has detailed how common XSS flaws in web applications employing (Google) Gears and HTML 5 Database Storage can leave local databases wide open to attack. This comes just as Gears is starting to take off, and just yesterday Google demonstrated a beta version of offline Gmail on phones, thanks to HTML 5 support in WebKit-based browsers, such as those used by Android and the iPhone. Sutton drove home the point by walking through a real world example on commercial site Paymo.biz, which has thankfully since been fixed."

Doing everything through the web is dumb

[Gizzmonic]

Why do we need to do spreadsheets or word processing through the web? It's a dumb idea. AJAX stuff will never be secure, especially compared to local applications. I hate the idea of "the cloud." I wish the Internet would go away, maybe then my fat girlfriend wouldn't have found that other guy on WoW. I hate you Internet!

Re:

[mcgrew]

Well, I don't need it and you might not either, but I can see someone with a web-enabled cell phone, a laptop, and a box at their home wanting to access their stuff from anywhere. Say I kept my check register online, I could update it any tome and who would want to access it?

Or for taking notes or something.

Re:

[Vectronic]

I think it's Taco's way of making himself feel special, seems to be only during his "runs" of articles...

Perhaps its a test, to see if articles with 0 submissions get more clicks, dunno...

Re:

[phantomfive]

Of course, since local applications have always been super-secure. (sarcasm).

I have no problem with security, since I have coded my own browser, called froam, that runs each page in a separate process in a separate VM, then for safe keeping, I store the data from each thread in a separate hard drive. The storage costs are getting expensive but it is all worth it knowing I have out-microsofted microsoft at their own game. (Ha! and each desk has its own chair! Take that Balmer!!)

Whatever.

Just wondering...

[jonaskoelker]

Just wondering, was her name Alison?

Yeah, this wasn't basically obvious?

[Giant Electronic Bra]

In essence it isn't a NEW vulnerability, just whenever javaScript can do some new thing on your browser then hey presto! So can someone else's javascript do that marvy new thing. Just proves that XSS attacks live on, and always will.

Re:

[LDoggg_]

Sure, someone else's javascript can do that marvy new thing if you're dumb enough to include their javascript in your page.

Well, that is what XSS is for...

[Giant Electronic Bra]

Obviously, if a site is perfectly secure then it has no problems. My point was, there isn't a new vulnerability here, just a wider scope for exactly the same old ones to do more. EVERY additional feature javascript gets is one more thing an XSS exploit can do. Doesn't make it a new exploit any more than adding a new table to your database makes an SQLI exploit "new", it just means there is more data there to be messed with.

There goes my great plan..

[dave562]

..to develop an app for the IRS that would allow their agents to take work home on their mobile phones. I guess they're just going to have to do things the old fashioned way and lose laptops with the data on it.

I don't get it

[quickOnTheUptake]

The article wasn't clear to me. How was this code getting executed? It looked like it was being put into the original document (like edit the source and reload from cache, in which case the result seems like normal behavior to me).
Did anyone get the details of how the demo attack was being carried out?

Re:

[LDoggg_]

It was not clear at all. It looked like they logged in to paymo and started messing with javascript on the page. Anyone could do that with firebug and hose their own account if they wanted.

Where was code being executed from another site to cause problems with someone else's account?

Did the article have a problem with loading potentially harmful javascript code from google's server?

Slashdotted Comments

[Flyin Fungi]

Slashdot's Storage must of been attacked! I still see zero comments on stories.

Javascript DB connection == EVIL

[Foofoobar]

Why would anyone connect to a database from a javascript where everyone can view your connection and play with it at will just by building a custom script? Database calls should be controlled through a backend... especially when delivering via the web.

Even binary desktop apps connect to the server that gets that data and generally don't do DIRECT database calls. Client side database calls are just a bad idea no matter what language you use and what platform you are developing for.

Re:

[LDoggg_]

This isn't javascript connecting to a remote database. This is javascript talking to the local database built into HTML5 for local storage. No worse than making elaborate cookies unless the database for some reason is capable or executing things outside of its sandbox.

You don't get it do you?

[SmallFurryCreature]

WHAT BACKEND?

This is LOCAL storage used from the browser. There is NO server, the server is a lie!

Your comment just shows you don't have a clue what this story is about. Basically this story is the same as the one in the dark ages when cookies were readable by other domains then they originated on.

Browser connects to server, downloads javascript, javascript creates storage on the client, this storage should ONLY be readable by code that originated from the domain that created the local storage. This is apparantly not the case.

The javascript is NOT connecting to the server side storage, that would indeed be silly.

It IS only accessible from the domain that

[Giant Electronic Bra]

created it.

And when someone adds some javascript to that site which shouldn't be there (XSS vuln) then their code is running from the place authorized to look at your local data.

It really ISN'T that earth shattering, there is no 'new' vulnerability, just a new feature of javascript that the attacker can exploit once he has his script running on your browser.

update.google.com

[aoheno]

Or is it still beta? Never mind.

Learn from Microsoft. Start patching.

The only secure system is one without any interface.

Curing XSS

[rdebath]

Curing XSS should be as easy as bolting a door!

The problem is that any part of a site can say "trust domain.xex for this important code". But security needs to be simple to use and a full site audit is not simple.

My suggestion is a simple tag at the top of an html page that say two things.

1. This file is a top level page and may not be rendered inside a frame.
2. Only use files from "this" list of hosts to render anything in this window.

In an ideal world a browser that doesn't understand the tag would d

Re:

[guruevi]

On 1: Why would I as a developer need to specify what others do with my page? If others can include my page in their site that's their problem. This can easily be circumvented by not adhering to that standard or other means (like filtering the page through a makeshift proxy (could even be in JS) that removes the tags).

On 2: What developers have to do is better input/output control. XSS attacks are circumvented simply by failing the request (server side) anytime somebody specifies something with :// as the p