Alberto Trivero: The aim of this white paper is to analyze security implications of the new HTML 5 client-side storage technology, showing how different attacks can be conduct in order to steal storage data in the client’s machine.

There were two interesting points for me in that - the first was that storage isn’t directory protected, so LiveJournal or myspace shouldn’t use it, because their URL’s are of the form: http://www.livejournal.com/user1 or http://www.myspace.com/user2. I thought that was pretty damning, and shows a weakness in the spec.

The second showed that if there are XSS vulnerabilities, the database can be exploited - but I think that isn’t the right way to look at it. If there are XSS vulnerabilities, can’t I pretty much do whatever I want? E.g, the example given was:

But if I can do that, can’t the contents of my evil javascript grab the user’s cookies, or grab the user’s password out of the DOM, or do just about anything anyways? The local storage isn’t the problem, the XSS vulnerability in ‘page.php’ is.

Hmm, I was sure I remembered some more discussion of that whitepaper on IRC, but I can’t find it in my logs, and now I think it must have been some other (very similar) document...

storage isn’t directory protected

Security on the web is fundamentally origin-based, not directory-based. If Web Storage tried to apply directory-based security, people could write <iframe src="/some-other-directory"> and use iframe.contentDocument.appendChild(iframe.contentDocument.createNode('script')).setAttribute('src', 'some-malicious-script') to run scripts within the security context of that other directory, circumventing any protection.

The second showed that if there are XSS vulnerabilities, the database can be exploited

Indeed - XSS lets you do anything that the page itself can do, so it’s entirely unsurprising that it lets you access local storage. The solution is simply to escape all your input and output properly. In practice everybody will get it wrong, since everybody is getting it wrong today and the new features won’t change the vulnerabilities, so it’d probably be useful to encourage authors not to store particularly sensitive information on the client (just like with cookies).

Browser storage: Do we need SQL? Or would a JSON approach be better?

Ian Hickson: “I expect I’ll be reverse-engineering SQLite and speccing that, if nothing better is picked first. As it is, people are starting to use the database feature in actual Web apps (e.g. mobile GMail, iirc).” When I read that...

Sat 11 Apr 2009

Browser storage: Do we need SQL? Or would a JSON approach be better?

Ian Hickson: “I expect I’ll be reverse-engineering SQLite and speccing that, if nothing better is picked first. As it is, people are starting to use the database feature in actual Web apps (e.g. mobile GMail, iirc).” When I read that comment to...

This circulated internally and the consensus was that it didn’t show any new attacks that weren’t essentially XSS attacks. Basically if you have an XSS + client side storage bad things can happen, but thats true of XSS in general. It doesn’t necessarily show any new potential vulnerabilities as opposed to XSS, which is an issue with the web itself that once you get into the page you can do anything you want.

I do have one lingering concern that I don’t know what to do about. Having a Web Storage mechanism will enable people like me, who aren’t security experts, to design applications which capture more sensitive data which could be exposed with the right XSS attack. When such happens (and I see that as a when, not an if) there will be a lot of righteous finger pointing.

But if that turns out to be the biggest concern, I don’t see that as blocking in any way. At most, I see a call out to see if anybody can express that concern in a way that is clear enough to merit inclusion in the spec.

Mon 13 Apr 2009

A sane way to protect locally persistent data is to try and protect it the same way server resident data is protected. For example, if an authentication token is required in the form of a cookie to access protected parts of the site, the same token must be good to protect data that came from those protected parts.

My proposal, in effect, is to ensure that data access can only take place if the authorization token that the server verified in order to provide the private data is, in fact, present at the time of accessing that same data.

Read more about my proposals on persistent local storage, its synchronization, as well as securing access to it on my blog [link]

Tue 14 Apr 2009

Limiting access to locally persistent data

Sam Ruby worries about security of locally persistent data , for example, in WebStorage : Having a Web Storage mechanism will enable people like me, who aren’t security experts, to design applications which capture more sensitive data which could be...

Browser storage: What is the correct API? SQL? JSON?

(The following is repost from my personal blog). Ian Hickson: “I expect I’ll be reverse-engineering SQLite and speccing that, if nothing better is picked first. As it is, people are starting to use the database feature in actual Web apps (e.g....