canmove, Confirmed users
120
edits
Security/Reviews/WebActivities: Difference between revisions
no edit summary
(Created page with "== Items Reviewed == Web Activities == Introduce Feature == === Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) === === What solutions/approach...") |
No edit summary |
||
| Line 1: | Line 1: | ||
== Items Reviewed == | == Items Reviewed == | ||
Web Activities | Web Activities | ||
* component of the broader Open Web Applications project | |||
== Introduce Feature == | * https://github.com/mozilla/openwebapps/blob/develop/docs/ACTIVITIES.md | ||
== Introduce Feature (5-10 minutes) == | |||
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) | * mhanson and shane created: http://etherpad.mozilla.com:9000/p5sbmv56Fh (contents will be copied into this section when moved to wiki) | ||
* lightweight service discovery for web services that also helps with interaction with those services | |||
* web addressable provider that will provide the service or content | |||
* could be multi-message or fire and forget | |||
* service providers taken from the list of web-apps the user has chosen to install | |||
** sim to web-intents from Google <-- markup as you browse | |||
*** think that is a little weak so this is more stringent | |||
* as currently specified, system is anonymous in both directions (thus the mediator) | |||
=== example === | |||
(second page of pdf) pretend there's no "chrome oauth API" business | |||
This diagram is a pseudo-threat model to illustrate the paths through which data flows. | |||
3rd party website contains button that initiates "getting a photo". The button calls on the activity API, which is injected into web conent. | |||
If there's a mediator for the activity, initiates it and does its thang. The mediator is told what services are available and loads iframes to launch 'em. | |||
* Browser acts as a message-passing interface to connect sites' desired API calls to apps that provide those APIs. | |||
* special activity called getCredential | |||
** this gets current logged in user and credentials to use for the service | |||
** can only be initiated by the browser | |||
== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) == | |||
* ^^ (incl in provided content) | |||
=== What solutions/approaches were considered other than the proposed solution? === | === What solutions/approaches were considered other than the proposed solution? === | ||
=== Why was this solution chosen? === | === Why was this solution chosen? === | ||
=== Any security threats already considered in the design and why? === | === Any security threats already considered in the design and why? === | ||
== Threat Brainstorming (30-40 minutes) == | |||
== Threat Brainstorming == | * Either chrome or content can implement provider, chrome<->content interaction/confusion | ||
** provider should always be from a webapp which means the user installed it | |||
== Conclusions / Action Items == | ** only formally installed web-apps can be a provider | ||
** need to keep an eye towards implicit permissions that users many not understand | |||
* Does installing as a web app indicate user's intent to allow the app access that normal web content does not have? (I.e. why differ from Web Intents?) | |||
* Clickjacking since content can cause the UI to be displayed | |||
* Content injection | |||
* Cannot enforce privacy/security constraints if web apps can define their own activities. | |||
* Impersonation attacks (e.g. "paypal app") - this includes the installation dialog/experience, what information is provided to user about what activities are being registered for etc. | |||
* Driveby manifest installs (like what we are fixing for addons) - for example, an addon or other installer creating a web app manifest on disk (eg the comcast issue with their toolbar) | |||
** there's a "ceremony" to install web-apps. user is presented with UI to approve "installation" of each web app. | |||
* Are all the special cases for login (race condition protection, limited invocability) only needed for login actions? | |||
* Phishing -- does this feature make phishing easier? We are depending on address bar being visible to protect against phishing. ( | |||
** all the normal indicators remain for the login scenario to help users not get phished (i.e. address bar) | |||
** But, aren't we getting rid of the address bar in many cases?) | |||
*** the login popup for auth would always have the url bar | |||
* Redirect handling - must make sure to use final target of redirect when comparing domains (manifests must come from same url as web app etc) | |||
* SSL/security/trust indicators with hidden interactions that are happening off the current page | |||
* Structured clone > JSON, a much bigger risk, Mike is not sure it is necessary to allow more than JSON, but images? video? | |||
* Unifying local data access security model and UX with web data access and UX | |||
== Conclusions / Action Items (10-20 minutes) == | |||
* [bsterne] will need to assign someone for penetration testing | |||
* [bsterne] threat model, further small discussion | |||
* [dchan] code review | |||
* [Sid] privacy review | |||
* More threat brainstorming/modelling needed | |||
* Talk to jst about popup blocker code | |||