Attacking Local Browser Storage 28
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 (Score:5, Funny)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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... (Score:2)
Just wondering, was her name Alison?
Yeah, this wasn't basically obvious? (Score:3, Insightful)
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: (Score:2)
Well, that is what XSS is for... (Score:2)
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.. (Score:5, Funny)
I don't get it (Score:2)
Did anyone get the details of how the demo attack was being carried out?
Re: (Score:2)
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 (Score:1)
Javascript DB connection == EVIL (Score:3, Informative)
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: (Score:2)
You don't get it do you? (Score:4, Informative)
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 (Score:3, Informative)
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 (Score:1)
Learn from Microsoft. Start patching.
The only secure system is one without any interface.
Curing XSS (Score:2)
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.
In an ideal world a browser that doesn't understand the tag would d
Re: (Score:2)
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