WebAPI/Security/DeviceStorage: Difference between revisions

Jump to navigation Jump to search

WebAPI/Security/DeviceStorage (view source)

Revision as of 12:52, 24 September 2012

405 bytes removed ,  24 September 2012
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
Name of API: Device Storage
== Device Storage ==
 
References:
*https://wiki.mozilla.org/WebAPI/DeviceStorageAPI<br>
*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.  Can be enumerated.
Brief purpose of API: Let content access files based on name and type.  Can be enumerated.


Line 16: Line 11:
access to confidential data.
access to confidential data.


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


Authorization model for uninstalled web content: Explicit via web activities
{| border="1" class="wikitable"
 
! Type
Authorization model for installed web content: Explicit via web activities
! Use Cases
 
! Authorization Model
Potential mitigations:
! Notes & Other Controls
*Make sure the user knows what files is being accessed when asking permission.
|-
*No option to remember permission.
| Web Content || None || No direct access (access via web activities) ||
*OS mediated interface (like file picker -  via intents?).
|-
 
| Installed Web Apps || None || No direct access (access via web activities) ||
== 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.
| Privileged Web Apps || Photo gallery, camera app that displays photos, any app that saves data will likely want to read it back. ||Explicit ||
 
Authorization model: Explicit
 
Potential mitigations:
*Granting permission only for a particular type of file (images, pdf, etc).
*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.
*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 Web Apps || Notify an app if the user is idle. || Implicit ||
Use cases for certified code: File manager
|}
 
===Notes===
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
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.
granted.


__NOTOC__
__NOTOC__
Ptheriault
canmove, Confirmed users
1,220

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/472983"

Navigation menu