WebAPI/Security/DeviceStorage: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "Name of API: Device Storage Reference: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI Brief purpose of API: Let content access files based on name and type. Can be enumerat...")
 
No edit summary
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Name of API: Device Storage
== Device Storage ==
Brief purpose of API: Let content access files based on name and type.  Can be enumerated.


Reference: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI
Inherent threats:
 
*Use excessive resources (file space), read files, change or delete files.   
Brief purpose of API: Let content access files based on name and type. 
*Files could potentially contain confidential information.
Can be enumerated.
*Create files with incriminating / illegal information, then call the cops
 
*Create files that other apps can look for to control their behavior
Inherent threats: Use excessive resources (file space), read files,
change or delete files.  Files could potentially contain confidential
information.


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


== Regular web content (unauthenticated) ==
References:
Use cases for unauthenticated code: Access a previously taken profile
*https://wiki.mozilla.org/WebAPI/DeviceStorageAPI<br>
picture, select a song to play.
*Security discussion: https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9b5e3f55ea2c42f8


Authorization model for uninstalled web content: Explicit (OS Mediated)
{| border="1" class="wikitable"
 
! Type
Authorization model for installed web content: Explicit (OS Mediated)
! Use Cases
! Authorization Model
! Notes & Other Controls
|-
| Web Content || None || No direct access (access via web activities) ||
|-
| Installed Web Apps || None || No direct access (access via web activities) ||
|-
| Privileged Web Apps || Photo gallery, camera app that displays photos, any app that saves data will likely want to read it back. ||Explicit ||
*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 Web Apps || Notify an app if the user is idle. || Implicit ||
|}
===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.


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?).
__NOTOC__


== Trusted (authenticated by publisher) ==
[[Category:Web APIs]]
Use cases for authenticated code: Photo gallery
[[Category:Security]]
 
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 (vouched for by trusted 3rd party) ==
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.

Latest revision as of 23:40, 1 October 2014

Device Storage

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.

References:

Type Use Cases Authorization Model Notes & Other Controls
Web Content None No direct access (access via web activities)
Installed Web Apps None No direct access (access via web activities)
Privileged Web Apps Photo gallery, camera app that displays photos, any app that saves data will likely want to read it back. Explicit
  • 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 Web Apps Notify an app if the user is idle. Implicit

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.

Retrieved from "https://wiki.allizom.org/index.php?title=WebAPI/Security/DeviceStorage&oldid=1021336"