WebAPI/Security/DeviceStorage: Difference between revisions
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 | Authorization model for uninstalled web content: Explicit via web activities | ||
Authorization model for installed web content: Explicit | 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. | 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 ( | == 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). | 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:
- https://wiki.mozilla.org/WebAPI/DeviceStorageAPI
- 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.
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.