Security/Reviews/WebActivities

Please use "Edit with form" above to edit this page.

Item Reviewed

WebActivities
Target	`

{{#set:SecReview name=WebActivities |SecReview target=` }}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

`

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

' {{#set: SecReview feature goal=' |SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=' |SecReview threat brainstorming=' }}

Action Items

Action Item Status	None
Release Target	`
Action Items
'

{{#set:|SecReview action item status=None

|Feature version=` |SecReview action items=` }}

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
• 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)

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