Security/Reviews/Firefox4/IndexedDB Security Review
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.
- 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
- 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.
- No. There are only 2 prefs introduced here and they all have guards and fallbacks.
- 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.)
- [MXR]
- Does it interoperate with a web service? How will it do so?
- No.
- Explain the significant file formats, names, syntax, and semantics.
- [[3]]
- 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?
- We add the
moz_indexedDB
getter to [nsIDOMStorageWindow]
- We add the
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.