Security/Reviews/Firefox4/IndexedDB Security Review

From MozillaWiki
Jump to: navigation, 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

  • Databases go into a directory built using the origin (scheme+ascii-host+port). Need to test to make sure that an overlong name for the file system FAILS rather than truncates and succeeds. Truncation means two sites might end up using the same databases.
  • database filenames are based on user input. Do we sanitize those names to prevent file system games like directory traversal and the like
    • hash name first (weak hash), escape everything but alphas, add first and last bits to hash.
    • should prevent tricks
  • Currently 3rd-party content (frames) can use databases. We want to block 3rd party because it's easier to loosen restrictions than the reverse. bug 595307
    • we need to check that it's same-origin all the way to the top-most frame if we do this.
  • Users are prompted before using database (per origin) -- they must opt in.
  • Users are prompted again if the origin uses more than <Quota> megabytes.
    • currently Quota is 50Mb
    • if users OK exceeding quota then space is unlimited
  • NOT hooked up to "Clear Recent History..." in any way
    • why not? what does it mean for databases?
    • if we try to partially delete we could muck with things
    • if we delete everything users could get pissed
    • if database was created during the period in question we could safely nuke the whole thing
    • if database pre-existed but was modified in that time, then what?
  • if we hook it up to Clear Recent History it probably needs its own category/check-box
  • feature not yet hooked up to "forget about this site" bug 594478
  • indexedDB disabled in private browsing mode.
    • Site might be able to guess you're in private mode if you've previously allowed them to store stuff?
  • Origins must have a host name to play, file:/// is out.
  • new serialization/storage format -- probably longer JSON.
    • has it been tested/fuzzed?
    • new format will be used for web workers as well.
    • may not switch to new format in FF4