WebAPI/Security/DeviceStorage: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
References:
References:
*https://wiki.mozilla.org/WebAPI/DeviceStorageAPI<br>
*https://wiki.mozilla.org/WebAPI/DeviceStorageAPI<br>
*https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9b5e3f55ea2c42f8
*Security discussion: https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9b5e3f55ea2c42f8


Brief purpose of API: Let content access files based on name and type.   
Brief purpose of API: Let content access files based on name and type.  Can be enumerated.
Can be enumerated.


Inherent threats: Use excessive resources (file space), read files,
Inherent threats:
change or delete files.  Files could potentially contain confidential
*Use excessive resources (file space), read files, change or delete files.   
information.
*Files could potentially contain confidential information.
*Create files with incriminating / illegal information, then call the cops
*Create files that other apps can look for to control their behavior


Threat severity: high to critical - privacy concerns, loss of user data,
Threat severity: high to critical - privacy concerns, loss of user data,
Line 16: Line 17:


== Regular web content (unauthenticated) ==
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Access a previously taken profile
Use cases for unauthenticated code: Access a previously taken profile picture, select a song to play.
picture, select a song to play.


Authorization model for uninstalled web content: Explicit (web activities)
Authorization model for uninstalled web content: Explicit via web activities


Authorization model for installed web content: Explicit (web activities)
Authorization model for installed web content: Explicit via web activities


Potential mitigations: Make sure the user knows what files is being accessed when asking permission. No option to remember permission. OS mediated interface (like file picker -  via intents?).
Potential mitigations:  
*Make sure the user knows what files is being accessed when asking permission.
*No option to remember permission.
*OS mediated interface (like file picker -  via intents?).


== Privileged (reviewed by store) ==
== Privileged (approved by app store) ==
Use cases for authenticated code: Photo gallery
Use cases for authenticated code: Photo gallery, camera app that displays photos, any app that saves data will likely want to read it back.


Authorization model: Explicit
Authorization model: Explicit


Potential mitigations: Granting permission only for a particular type of file (images, pdf, etc). In the short run we will rely on the "intended usage" to communicate to the user the risk of permitting this access.
Potential mitigations:
*Granting permission only for a particular type of file (images, pdf, etc).
*In the short run we will rely on the "intended usage" to communicate to the user the risk of permitting this access.


== Certified (system-critical applications) ==
== Certified (system-critical applications) ==

Revision as of 22:07, 6 August 2012

Name of API: Device Storage

References:

Brief purpose of API: Let content access files based on name and type. Can be enumerated.

Inherent threats:

  • Use excessive resources (file space), read files, change or delete files.
  • Files could potentially contain confidential information.
  • Create files with incriminating / illegal information, then call the cops
  • Create files that other apps can look for to control their behavior

Threat severity: high to critical - privacy concerns, loss of user data, access to confidential data.

Regular web content (unauthenticated)

Use cases for unauthenticated code: Access a previously taken profile picture, select a song to play.

Authorization model for uninstalled web content: Explicit via web activities

Authorization model for installed web content: Explicit via web activities

Potential mitigations:

  • Make sure the user knows what files is being accessed when asking permission.
  • No option to remember permission.
  • OS mediated interface (like file picker - via intents?).

Privileged (approved by app store)

Use cases for authenticated code: Photo gallery, camera app that displays photos, any app that saves data will likely want to read it back.

Authorization model: Explicit

Potential mitigations:

  • Granting permission only for a particular type of file (images, pdf, etc).
  • In the short run we will rely on the "intended usage" to communicate to the user the risk of permitting this access.

Certified (system-critical applications)

Use cases for certified code: File manager

Authorization model: Implicit

Potential mitigations: None.

Notes

Ideally permission should be given on a type basis (i.e. enforce the "intended usage" at runtime). So giving permission to access music doesn't automatically give permission to photos. If the type is a string literal when the code is reviewed, that would mitigate the issue. Otherwise sub-permissions for types (device-storage.music) or separate permissions for each type (device-storage-music) would be needed. Also has the benefit that it allows the permission prompt to be more explicit about what is being granted.