Security/Reviews/B2GWebActivities

From MozillaWiki
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Item Reviewed

B2G Web Activities
Target 
   
     Full Query
ID Summary Priority Status
715814 Web Activities -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

{{#set:SecReview name=B2G Web Activities

|SecReview target=

Full Query
ID Summary Priority Status
715814 Web Activities -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

}}

Introduce the Feature

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

Summary
  • the caller call new Activity(activityOptions);
    • if there is a default app to handle that activity:
      • run the default app
    • else if there is only one app able to handle that activity:
      • run the app
    • else:
      • show a UI with application names and icons so the user can select the one that should be used;
    • the app handling the activity is called and does what it has to do.
  • The security threats depend on what the activity is.
  • Data Passing

Communication is based on DomRequest Caller waits for the onSuccess event, and then reads result Handler uses postResult to send the data Data is passed using a structured clone - allows more than JSON (e.g. date, bytearray etc) Two ways to handle intents - inline (e.g. iframe on top of current content, but decided by UA) - window (DomWindow) The idea is that any pages or apps could register to be a handler. It is unlikely that the b2g browser will support pages being handlers.

What solutions/approaches were considered other than the proposed solution?

Why we are not using web intents, and instead using web activities:

  • Intents are a subset of Android intents
    • Web Activities

Why was this solution chosen?

`

Any security threats already considered in the design and why?

`

Threat Brainstorming

  • Construct a regex that is slow to execute
** Regex throws if you try to do that
  • Steal sensitive data by handling a sensitive activity
    • If multiple apps are registered, the user chooses. (possibly a spoofing risk here?)
      • Spoofing risk mitigations: show app name and icon
    • introduce filters/checks for privileged activities
    • require user interaction for launching an activity (similar to popup blocking)
    • When a webpage registers to handle an activity we should put up a prompt.
    • When a activity is started, we should *always* display the list of handlers and let the user choose. Unless either the user has chosen a default handler, or if there is only one handler and that handler is trusted certified
  • DoS other apps by returning spurious data
  • App fires an activity without the user expecting
  • Apps can use this to get themselves launched - how will the user know they have changed apps?
    • Always show the choosing UI unless the user has chosen a default

{{#set: SecReview feature goal=;Summary:

  • the caller call new Activity(activityOptions);
    • if there is a default app to handle that activity:
      • run the default app
    • else if there is only one app able to handle that activity:
      • run the app
    • else:
      • show a UI with application names and icons so the user can select the one that should be used;
    • the app handling the activity is called and does what it has to do.
  • The security threats depend on what the activity is.
  • Data Passing

Communication is based on DomRequest Caller waits for the onSuccess event, and then reads result Handler uses postResult to send the data Data is passed using a structured clone - allows more than JSON (e.g. date, bytearray etc) Two ways to handle intents - inline (e.g. iframe on top of current content, but decided by UA) - window (DomWindow) The idea is that any pages or apps could register to be a handler. It is unlikely that the b2g browser will support pages being handlers. |SecReview alt solutions=Why we are not using web intents, and instead using web activities:

  • Intents are a subset of Android intents
    • Web Activities

|SecReview solution chosen=' |SecReview threats considered=' |SecReview threat brainstorming=*Construct a regex that is slow to execute 

** Regex throws if you try to do that
  • Steal sensitive data by handling a sensitive activity
    • If multiple apps are registered, the user chooses. (possibly a spoofing risk here?)
      • Spoofing risk mitigations: show app name and icon
    • introduce filters/checks for privileged activities
    • require user interaction for launching an activity (similar to popup blocking)
    • When a webpage registers to handle an activity we should put up a prompt.
    • When a activity is started, we should *always* display the list of handlers and let the user choose. Unless either the user has chosen a default handler, or if there is only one handler and that handler is trusted certified
  • DoS other apps by returning spurious data
  • App fires an activity without the user expecting
  • Apps can use this to get themselves launched - how will the user know they have changed apps?
    • Always show the choosing UI unless the user has chosen a default

}}

Action Items

Action Item Status In Progress
Release Target `
Action Items
* Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug)

pauljt::Revisit spoofing when doing security testing of web activities:: Post Implementation pauljt::ensure registered URL is restricted to same origin based on principal

fabrice::Restrict handling sensitive activities (sms, others?) to trusted or certified apps.

{{#set:|SecReview action item status=In Progress

|Feature version=` |SecReview action items=* Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug) pauljt::Revisit spoofing when doing security testing of web activities:: Post Implementation pauljt::ensure registered URL is restricted to same origin based on principal fabrice::Restrict handling sensitive activities (sms, others?) to trusted or certified apps. }}

Retrieved from "https://wiki.allizom.org/index.php?title=Security/Reviews/B2GWebActivities&oldid=436223"