WebAPI/Security/Contacts: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Contacts API==
== Contacts API ==
Reference:https://wiki.mozilla.org/WebAPI/ContactsAPI
Brief purpose of API: Access to users contacts.
Brief purpose of API: Access to users contacts.


Line 10: Line 9:
*DoS via filling address book with bogus data
*DoS via filling address book with bogus data


Threat severity: high
Threat severity: High


=== Regular web content (unauthenticated) ===
References:
Use cases for unauthenticated code: Mediated access to specific (user selected) contact
*https://wiki.mozilla.org/WebAPI/ContactsAPI
information
*https://groups.google.com/d/topic/mozilla.dev.webapps/hvG5PXsFyzw/discussion


Authorization model for uninstalled web content: OS mediated (web
activities, or trusted UI)<br>
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) ===
=== Permissions Table===
Use cases for authenticated code: Create, read or edit contact information


Authorization model: Explicit
{| border="1" class="wikitable"
 
! Type
Potential mitigations:
! Use Cases
! Authorization Model
! Notes & Other Controls
|-
| Web Content || None || No direct access (access via web activities)||
*App requests a contact via web activities or trusted UI
*API provides a local identifier instead of the actual contact information
|-
| Installed Web Apps || None || No direct access (access via web activities)||
*App requests a contact via web activities or trusted UI
*API provides a local identifier instead of the actual contact information
|-
| Privileged Web Apps || Create, read or edit contact information || Explicit ||
* Let user configure what data is accessible (globally?)
* 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?)
* 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 (vouched for by trusted 3rd party) ===
| Certified Web Apps || Create, read or edit contact information || Implicit ||
Use cases for certified code: Create, read or edit contact information
|}


Authorization model: Implicit
__NOTOC__


Potential mitigations: None
[[Category:Web APIs]]
[[Category:Security]]

Latest revision as of 23:40, 1 October 2014

Contacts API

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

References:


Permissions Table

Type Use Cases Authorization Model Notes & Other Controls
Web Content None No direct access (access via web activities)
  • App requests a contact via web activities or trusted UI
  • API provides a local identifier instead of the actual contact information
Installed Web Apps None No direct access (access via web activities)
  • App requests a contact via web activities or trusted UI
  • API provides a local identifier instead of the actual contact information
Privileged Web Apps Create, read or edit contact information Explicit
  • 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 Web Apps Create, read or edit contact information Implicit