WebAPI/Security/Contacts: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
No edit summary |
||
| Line 20: | Line 20: | ||
information | information | ||
Authorization model for uninstalled web content: | Authorization model for uninstalled web content: Explicit via web activities | ||
Authorization model for installed web content: | Authorization model for installed web content: Explicit via web activities | ||
Potential mitigations: | Potential mitigations: | ||
| Line 28: | Line 28: | ||
*API provides a local identifier instead of the actual contact information | *API provides a local identifier instead of the actual contact information | ||
== | == Privileged (approved by app store) == | ||
Use cases for | Use cases for privileged code: Create, read or edit contact information | ||
Authorization model: Explicit | Authorization model: Explicit | ||
| Line 37: | Line 37: | ||
* Have separate permissions for read vs read&write, assuming that many apps only want read, and could use web activities to create a contact if necessary. These distinctions should not be exposed to the user (the user should be only be asked if the API wants to "have access to" the contacts API, as it adds too much cognitive overhead to start scanning dialogs for the verb without clearly differentiating the risk to the user). | * Have separate permissions for read vs read&write, assuming that many apps only want read, and could use web activities to create a contact if necessary. These distinctions should not be exposed to the user (the user should be only be asked if the API wants to "have access to" the contacts API, as it adds too much cognitive overhead to start scanning dialogs for the verb without clearly differentiating the risk to the user). | ||
== Certified ( | == Certified (system-critical apps) == | ||
Use cases for certified code: Create, read or edit contact information | Use cases for certified code: Create, read or edit contact information | ||
Revision as of 23:26, 6 August 2012
Name of API: Contacts API
References:
- https://wiki.mozilla.org/WebAPI/ContactsAPI
- https://groups.google.com/d/topic/mozilla.dev.webapps/hvG5PXsFyzw/discussion
Brief purpose of API: Access to users contacts.
General Use Cases:N/A
Inherent threats:
- Read/exfiltrate confidential information,
- Destroy user's contact data
- DoS via filling address book with bogus data
Threat severity: High
Regular web content (unauthenticated)
Use cases for unauthenticated code: Mediated access to specific (user selected) contact information
Authorization model for uninstalled web content: Explicit via web activities
Authorization model for installed web content: Explicit via web activities
Potential mitigations:
- App requests a contact via web activities or trusted UI
- API provides a local identifier instead of the actual contact information
Privileged (approved by app store)
Use cases for privileged code: Create, read or edit contact information
Authorization model: Explicit
Potential mitigations:
- Let user configure what data is accessible (globally?)
- Have separate permissions for read vs read&write, assuming that many apps only want read, and could use web activities to create a contact if necessary. These distinctions should not be exposed to the user (the user should be only be asked if the API wants to "have access to" the contacts API, as it adds too much cognitive overhead to start scanning dialogs for the verb without clearly differentiating the risk to the user).
Certified (system-critical apps)
Use cases for certified code: Create, read or edit contact information
Authorization model: Implicit
Potential mitigations: None