Security/Reviews/Firefox4/IndexedDB Security Review: Difference between revisions
Jump to navigation
Jump to search
Bent.mozilla (talk | contribs) |
Bent.mozilla (talk | contribs) 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.
- 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.