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 exposed with the right XSS attack.

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.

Let's work through this example:

Some JavaScript requests URL X from its server. GET X
Server challenges the browser for auth. 401 WWW-Authenticate: Cookie form-action="/login?redirect=X"
Browser shows the form-action page. GET /login?redirect=X
User enters credentials and submits the form. POST /login/do
Server checks credentials and responds with the redirect and an auth token. 303 Set-Cookie: C=Y, Location =X
Browser redirects to the original location along with the cookie. GET X Cookie: C=Y

Now when the page asks browser for persistent storage, it should be able to identify the cookie used to secure the data stored locally. For example:

window.createDatabase('myDB', 'C').

The browser automatically uses the current value of the cookie 'C' to restrict access to 'myDB'. Next time, when I access 'myDB' by doing:

window.openDatabase('myDB', 'C')

then the browser verifies that the current value of cookie 'C' is the same as that recorded when 'myDB' was created. If it is not, the request would fail.

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.

This protects against scenarios where different directories are protected differently on the server. It also avoids asking the JS code any questions about the current value of a cookie and does not pass any cookie values to the JS code.

Of course, if the cookie goes bad after a while, the locally persistent data is also useless. Unless the local data is somehow flushed out to the server periodically, this could be a big deal. Otherwise, you can just refresh from the server using the current auth token and go from there.