[whatwg] Potenial Security Problem in Global Storage Specification

[Jerason Banes]

On 6/1/07, Gervase Markham <gerv at mozilla.org> wrote:
>
> Ian Hickson wrote:
> > Yeah, this is mentioned in the security section:
> >
> >    http://www.whatwg.org/specs/web-apps/current-work/#security5
> >
> > ...along with recommended solutions to mitigate it.
>
> All of those mitigation measures seem to be non-ideal.


I disagree. The third item in the list describes the solution which I had in
mind:

"Blocking access to the top-level domain
("public<http://www.whatwg.org/specs/web-apps/current-work/#public0>")
storage areas: user agents may prevent domains from storing data in and
reading data from the top-level domain entries in the
globalStorage<http://www.whatwg.org/specs/web-apps/current-work/#globalstorage>object.
For example, content at the domain
www.example.com would be allowed to access example.com data but not  comdata."

That effectively restricts the storage to a single domain and is in line
with how cookies work today.

Have any browser makers expressed opinions on which of them they are
> planning to implement?


That's a good question, but I'm not sure if it's one that the WHATWG can
answer? I do know that Firefox 2 already implements the Storage spec. Info
on that here:

http://developer.mozilla.org/en/docs/DOM:Storage

I wasn't able to find any docs that describe the Storage security model used
in Gecko, so I ran a few tests. What I found was that any attempt to access
globalStorage[''] or globalStorage['com'] from the context of a website
resulted in a security error. You can try the test for yourself here:

http://java.dnsalias.com/temp/storage.html

After loading the page, open the Javascript Error console. You should see a
security exception listed.

I presume that the restrictions are relaxed for signed pages as well as
those that are run at a higher privilege level. (e.g. XULRunner apps.)

Is there a document somewhere outlining the actual benefits of this
> feature, even as potentially restricted?
>

The specification has this explanation: "Web applications may wish to store
megabytes of user data, such as entire user-authored documents or a user's
mailbox, on the clientside for performance reasons."

And it's not just performance reasons. If I wanted to work on a Google
Spreadsheet on a plane, for example, offline caching of the data would allow
me to continue my work without an internet connection. Then when I reconnect
to the internet and load the document, the client would sync its stored
changes with the server.

My understanding is that this is Google's justification for their new
"Gears" product. Which is basically the same as the WHATWG Storage +
Database specifications, but with auto-sync and an incompatible API.

Thanks,
Jerason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070601/13bd68fb/attachment-0001.htm>