WebAPI/Security/Contacts: Difference between revisions
mNo edit summary |
|||
| Line 1: | Line 1: | ||
Name of API: Contacts API | |||
Reference:https://wiki.mozilla.org/WebAPI/ContactsAPI | Reference:https://wiki.mozilla.org/WebAPI/ContactsAPI | ||
Brief purpose of API: Access to users contacts. | Brief purpose of API: Access to users contacts. | ||
| Line 12: | Line 14: | ||
Threat severity: high | Threat severity: high | ||
== Regular web content (unauthenticated) == | |||
Use cases for unauthenticated code: Mediated access to specific (user selected) contact | Use cases for unauthenticated code: Mediated access to specific (user selected) contact | ||
information | information | ||
| Line 25: | Line 27: | ||
* API provides a local identifier instead of the actual contact information | * API provides a local identifier instead of the actual contact information | ||
== Trusted (authenticated by publisher) == | |||
Use cases for authenticated code: Create, read or edit contact information | Use cases for authenticated code: Create, read or edit contact information | ||
| Line 34: | Line 36: | ||
* Have separate permissions read,create or update/delete? (assuming that many apps only want read, and could use web activities to create a contact if necessary?) | * Have separate permissions read,create or update/delete? (assuming that many apps only want read, and could use web activities to create a contact if necessary?) | ||
== Certified (vouched for by trusted 3rd party) == | |||
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 13:25, 25 June 2012
Name of API: Contacts API
Reference:https://wiki.mozilla.org/WebAPI/ContactsAPI
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: OS mediated (web
activities, or trusted UI)
Authorization model for installed web content: OS mediated (web
activities, or trusted UI)
Potential mitigations:
- App requests a contact via web activities or trusted UI
- API provides a local identifier instead of the actual contact information
Trusted (authenticated by publisher)
Use cases for authenticated code: Create, read or edit contact information
Authorization model: Explicit
Potential mitigations:
- Let user configure what data is accessible (globally?)
- Have separate permissions read,create or update/delete? (assuming that many apps only want read, and could use web activities to create a contact if necessary?)
Certified (vouched for by trusted 3rd party)
Use cases for certified code: Create, read or edit contact information
Authorization model: Implicit
Potential mitigations: None