Security/Reviews/Firefox4/IndexedDB Security Review

From MozillaWiki
< Security‎ | Reviews‎ | Firefox4
Revision as of 17:07, 28 September 2010 by Bent.mozilla (talk | contribs)
Jump to navigation Jump to search

Overview

Indexed Database API

Background links
  • IndexedDB Spec[[1]]
  • Wiki page for other tracking [[2]]
  • Main tracking bug bug 553412

Security and Privacy

  • Is this feature a security feature? If it is, what security issues is it intended to resolve?
    • Not a security feature.
  • What potential security issues in your feature have you already considered and addressed?
    • Cross origin reads of indexedDB databases were a concern. We've guarded against this by saving database files in a per-origin directory. This directory's name is comprised of scheme+host+port, escaped, gathered from principal of the script that calls indexedDB.open(). Database files within these directories are named based on a hash of the database name and then at most 20 letters from the beginning and end of the database name.
    • Third party abuse will be prevented by disallowing third party use of indexedDB entirely.
  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
    • No. There are only 2 prefs introduced here and they all have guards and fallbacks.
      • dom.indexedDB.enabled: Whether or not indexedDB databases may be opened. Defaults to true.
      • dom.indexedDB.warningQuota: The disk size in megabytes that one origin can consume before the user is prompted for permission. Defaults to 50.
  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
    • We're relying on the SSM giving us a reliable subject principal.
    • We're assuming that no combination of origin and database name can collide with another origin's databases.
    • We're relying on cross origin wrappers to protect cross origin use of databases once they're created.
    • Each transaction is run on its own thread within a thread pool. We therefore limit the number of threads that the feature may use.
    • All indexedDB data is stored as text in SQLite databases (using JSON to convert to and from JS objects). All SQL statements are hardcoded in C++ and all parameters are bound by name to prevent injection.
  • How are transitions in/out of Private Browsing mode handled?
    • IndexedDB is completely disabled in private browsing mode.

Exported APIs

  • Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • Does it interoperate with a web service? How will it do so?
    • No.
  • Explain the significant file formats, names, syntax, and semantics.
  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
    • Documentation in MDC and on the spec should be sufficient
  • Does it change any existing interfaces?

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)?
    • DOM, Content, Storage

Data

  • What data is read or parsed by this feature?
    • JS Objects prepared by web sites.
  • What is the output of this feature?
    • SQLite files maintained by the browser.
  • What storage formats are used?
    • SQLite databases.

Reliability

  • What failure modes or decision points are presented to the user?
    • We prompt before a web site is allowed to create a database. The user must explicitly allow the creation.
    • We prompt again if the total size of all databases in an origin exceed a certain size.
    • In certain cases a web page may notify the user that other pages need to be closed before databases can be upgraded. We expect this to be very rare.
  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
    • Perhaps. If a database file is corrupted we destroy and recreate it on next use.

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
    • Two prefs, mentioned above.
    • Manually modifying a site's permissions via the Page Info dialog.
  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]
    • No.
  • 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)?
    • Documentation on MDC

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?
    • SQLite. They provided experimental quota management for this feature, which they will maintain and is part of their test suite.
  • 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?
    • No.

Review comments