Security/Reviews/Firefox4/IndexedDB Security Review: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 9: Line 9:
== Security and Privacy ==
== Security and Privacy ==
* Is this feature a security feature?  If it is, what security issues is it intended to resolve?
* 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?
* 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 <code>indexedDB.open()</code>. 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?
* 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.
* 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?
* How are transitions in/out of Private Browsing mode handled?
** IndexedDB is completely disabled in private browsing mode.


== Exported APIs ==
== Exported APIs ==
* Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
* Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
** [[http://mxr.mozilla.org/mozilla-central/source/dom/indexedDB MXR]]
* Does it interoperate with a web service? How will it do so?
* Does it interoperate with a web service? How will it do so?
** No.
* Explain the significant file formats, names, syntax, and semantics.
* Explain the significant file formats, names, syntax, and semantics.
** [[https://wiki.mozilla.org/Firefox/Projects/IndexedDB/SQL_Schema]]
* Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
* 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?
* Does it change any existing interfaces?
** We add the <code>moz_indexedDB</code> getter to [[http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/storage/nsIDOMStorageWindow.idl nsIDOMStorageWindow]]


== Module interactions ==
== Module interactions ==
* What other modules are used (REQUIRES in the makefile, interfaces)?
* What other modules are used (REQUIRES in the makefile, interfaces)?
** DOM, Content, Storage


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


== Reliability ==
== Reliability ==
* What failure modes or decision points are presented to the user?
* 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?
* 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 ==
== Configuration ==
* Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
* 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.]
* Are there build options for developers? [#ifdefs, ac_add_options, etc.]
** No.
* What ranges for the tunable are appropriate? How are they determined?
* 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)?
* What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
** Documentation on MDC


== Relationships to other projects ==
== Relationships to other projects ==
Are there related projects in the community?
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?
* 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?
* 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 ==
== Review comments ==

Revision as of 17:07, 28 September 2010

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