Firefox3.1/localStorage Security Review

From MozillaWiki
Jump to: navigation, search

Overview

localStorage is a replacement for globalStorage. There are two major differences from globalStorage:

  • Access control is same-origin, rather than same-host
  • The StorageItem interface is not used (localStorage["foo"] returns a

string, not an object with "value" and "secure" attributes.

Background links

Security and Privacy

Is this feature a security feature?

The change in access control is a security feature.

What potential security issues in your feature have you already considered and addressed?

localStorage doesn't share a storage area with globalStorage[samehost].

Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

How are transitions in/out of Private Browsing mode handled?

Unchanged from globalStorage.

Exported APIs

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

http://hg.mozilla.org/mozilla-central/file/6955c8360d08/dom/interfaces/storage/nsIDOMStorage2.idl

Does it change any existing interfaces?

Adds a localStorage attribute to nsIDOMWindow.

Module interactions

What other modules are used (REQUIRES in the makefile, interfaces)?

No change from globalStorage.

Data

What data is read or parsed by this feature?

What is the output of this feature?

What storage formats are used?

No change from globalStorage.

Reliability

What failure modes or decision points are presented to the user?

Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

No change from globalStorage.

Configuration

Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

Are there build options for developers? [#ifdefs, ac_add_options, etc.]

What ranges for the tunable are appropriate? How are they determined?

What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

No change from globalStorage.

Relationships to other projects

Are there related projects in the community?

  • If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
  • Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

N/A.

Review comments

  • currently if cookie lifetime is session-only we turn globalStorage/localStorage into a lame current-page-only memory store. It would be better to throw an error (QUOTA_EXCEEDED_ERR is mentioned in the spec for this case) or return null for locationStorage itself. Something that lets developers switch to using real sessionStorage instead, or telling users to enable the feature.
  • test that blocking cookies for a host does block localStorage for that host
  • test that localStorage is truly origin-based -- i.e. windows on different ports or schemes should not be able to access each other's localStorage even if the same host.
  • use of globalStorage[] should put a deprecation warning on the error console. Probably just the first use per window to avoid perf problems (object creation).
  • add default prefs to all.js for missing values (e.g. quota).
  • Should we put a length limit on keys? It's counted in the quota so we think we're OK.
  • test both keys and values with embedded nulls
  • test both keys and values with invalid UTF-8 sequences and invalid UTF-16, including ending on partial sequences.
  • we feed UTF-16 to sqlite, make sure it handles this OK and converts to utf-8 OK.
Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox3.1/localStorage_Security_Review&oldid=136036"