Security/Reviews/WebActivities: Difference between revisions
Jump to navigation
Jump to search
(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 | |||
Revision as of 15:30, 30 August 2011
Items Reviewed
Web Activities
- component of the broader Open Web Applications project
- https://github.com/mozilla/openwebapps/blob/develop/docs/ACTIVITIES.md
Introduce Feature (5-10 minutes)
- 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
- sim to web-intents from Google <-- markup as you browse
- 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?
Why was this solution chosen?
Any security threats already considered in the design and why?
Threat Brainstorming (30-40 minutes)
- Either chrome or content can implement provider, chrome<->content interaction/confusion
- provider should always be from a webapp which means the user installed it
- 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