WebAPI/Security/DeviceStorage

From MozillaWiki
< WebAPI‎ | Security
Revision as of 22:07, 6 August 2012 by Ladamski (talk | contribs)
Jump to navigation Jump to search

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.