Security/Reviews/WebRT

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

Item Reviewed

WebRT
Target

{{#set:SecReview name=WebRT

|SecReview target=

}}

Introduce the Feature

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

  • stands for Web Run Time (not to be confused with real time communications)
  • good alternate name is Web App Run Time (WebAppRT), or you can call it Prism 2 or XULRunner 3
  • similiar to XULRunner, except it provides a XULRunner app that is a very small shell for web applications
  • will ship with Firefox
  • running web apps natively

Stack:

  1. mozapps API (navigator.mozApps), used for installing webApps
  2. Installer - Firefox feature that will install the app into the native platform (always user space), does the work required to make the app look like a native app and does things in the OS to make it like a native app(
  3. Executable - built when we build and ship Firefox; a stub; copied for each web app that is installed; calls next part of the stack. (The stub finds and loads libxul.dll.)
  4. XULAppShell - loads the web application
  • Installing a stub executable seems complicated. Why don't we just create shortcuts like firefox.exe -webapp https://angrybirds.com ?
    • There are issues with how shortcuts on Windows that break this fundamentally
    • These shortcuts would stop working if Firefox is moved or uninstalled. The stub can look for Firefox in the registry, and show a more useful error message (maybe even download Firefox or libxul.dll for you).
    • there is some complexity with Windows seeing these as other than Firefox and will not only show them as firefox.exe but group them in the taskbar in an unintuitive way
  • How does it deal with version mismatches? (see below)
    • If stub version doesn't match the firefox version, running the stub will cause the stub to upgrade (or downgrade) and relaunch.
      • stubs are updated, if you downgrade we can downgrade, the apps could become incompatible
  • When a web site suggests "installing" a web app, can users choose to put them in app tabs instead? (And vice versa -- can users choose to move an app tab to a new app?)
    • no, once purchased from the store the only option is as a native app and into your dashboard of apps
  • What permissions do these web apps have? What does the install prompt look like?
    • install prompt is a firefox door hanger
      • Is it similar to the install prompt for existing add-ons?
        • in the sense they are both doorhangers, yes
    • permissions are the standard web permissions (discussion on-going)
  • How does the webapp verify that the stub is the appropriate version / executable?
    • webapp has no access to the stub
    • Does it probe the stub's version number or does it probe the version & the SHA hash, or the signature?
      • does not matter since it does not know
    • the UA is different for this so one could tell in some sense

Are how webrt handles receipts in scope? (dveditz: you had a great question here about how receipts are stored but i can't totally remember what the concern was) The "scope" of a web app is an origin (protocol+host+port). In the future we might allow the app to specify that it will want to load Facebook or Paypal in order to do a third-party thing temporarily.

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

  • using firefox.exe shortcuts (discussed above)

Why was this solution chosen?

  • for a variety of reasons shown in the discussion above

Any security threats already considered in the design and why?

  • web apps whose name contains ".."

Threat Brainstorming

  • Does the stub get updated when Firefox is updated?
    • No. We just hope the attack surface is small enough that it's ok to update them when they run.
  • What happens if arguments are passed to the stub on the command line?
    • ... and the stub executable decides to update itself, right then
  • Stub executables cannot be signed, because the icon is smushed into the executable. Will this cause Windows to warn or block the executable?
    • it can be set to do so, but by default it will warn on execution if the sig is wrong
  • Are there domain restrictions on what a web app can load? (links used to open in firefox, does that still happen? What about changes to window.location?)
  • Do web apps share a cookie store with Firefox?
    • no
  • Does each app have a competely separate profile?
    • Yes
  • What permissions do these web apps have?
    • currently nothing beyond what a webpage has. they load in a type="content"
      • except for the ability to appear without a url bar, ...
  • web apps whose name is the same as an app the user already has installed (spoofing, overwriting)
    • given the way refrenced this should not be a problem
  • finding libxul.dll in the working directory (make sure we use the new, secure version of the dll search path)
  • Spoofing Facebook or Paypal logins. User has no way to tell if it's legit. Can we say "BrowserID logins only", or send it over to the web browser?
  • Can a web app change its icon on the fly? (Suddenly spoofing Firefox or Windows Update, for example)\

{{#set: SecReview feature goal=* stands for Web Run Time (not to be confused with real time communications)

  • good alternate name is Web App Run Time (WebAppRT), or you can call it Prism 2 or XULRunner 3
  • similiar to XULRunner, except it provides a XULRunner app that is a very small shell for web applications
  • will ship with Firefox
  • running web apps natively

Stack:

  1. mozapps API (navigator.mozApps), used for installing webApps
  2. Installer - Firefox feature that will install the app into the native platform (always user space), does the work required to make the app look like a native app and does things in the OS to make it like a native app(
  3. Executable - built when we build and ship Firefox; a stub; copied for each web app that is installed; calls next part of the stack. (The stub finds and loads libxul.dll.)
  4. XULAppShell - loads the web application
  • Installing a stub executable seems complicated. Why don't we just create shortcuts like firefox.exe -webapp https://angrybirds.com ?
    • There are issues with how shortcuts on Windows that break this fundamentally
    • These shortcuts would stop working if Firefox is moved or uninstalled. The stub can look for Firefox in the registry, and show a more useful error message (maybe even download Firefox or libxul.dll for you).
    • there is some complexity with Windows seeing these as other than Firefox and will not only show them as firefox.exe but group them in the taskbar in an unintuitive way
  • How does it deal with version mismatches? (see below)
    • If stub version doesn't match the firefox version, running the stub will cause the stub to upgrade (or downgrade) and relaunch.
      • stubs are updated, if you downgrade we can downgrade, the apps could become incompatible
  • When a web site suggests "installing" a web app, can users choose to put them in app tabs instead? (And vice versa -- can users choose to move an app tab to a new app?)
    • no, once purchased from the store the only option is as a native app and into your dashboard of apps
  • What permissions do these web apps have? What does the install prompt look like?
    • install prompt is a firefox door hanger
      • Is it similar to the install prompt for existing add-ons?
        • in the sense they are both doorhangers, yes
    • permissions are the standard web permissions (discussion on-going)
  • How does the webapp verify that the stub is the appropriate version / executable?
    • webapp has no access to the stub
    • Does it probe the stub's version number or does it probe the version & the SHA hash, or the signature?
      • does not matter since it does not know
    • the UA is different for this so one could tell in some sense

Are how webrt handles receipts in scope? (dveditz: you had a great question here about how receipts are stored but i can't totally remember what the concern was) The "scope" of a web app is an origin (protocol+host+port). In the future we might allow the app to specify that it will want to load Facebook or Paypal in order to do a third-party thing temporarily. |SecReview alt solutions=* using firefox.exe shortcuts (discussed above) |SecReview solution chosen=* for a variety of reasons shown in the discussion above |SecReview threats considered=* web apps whose name contains ".." |SecReview threat brainstorming=* Does the stub get updated when Firefox is updated?

    • No. We just hope the attack surface is small enough that it's ok to update them when they run.
  • What happens if arguments are passed to the stub on the command line?
    • ... and the stub executable decides to update itself, right then
  • Stub executables cannot be signed, because the icon is smushed into the executable. Will this cause Windows to warn or block the executable?
    • it can be set to do so, but by default it will warn on execution if the sig is wrong
  • Are there domain restrictions on what a web app can load? (links used to open in firefox, does that still happen? What about changes to window.location?)
  • Do web apps share a cookie store with Firefox?
    • no
  • Does each app have a competely separate profile?
    • Yes
  • What permissions do these web apps have?
    • currently nothing beyond what a webpage has. they load in a type="content"
      • except for the ability to appear without a url bar, ...
  • web apps whose name is the same as an app the user already has installed (spoofing, overwriting)
    • given the way refrenced this should not be a problem
  • finding libxul.dll in the working directory (make sure we use the new, secure version of the dll search path)
  • Spoofing Facebook or Paypal logins. User has no way to tell if it's legit. Can we say "BrowserID logins only", or send it over to the web browser?
  • Can a web app change its icon on the fly? (Suddenly spoofing Firefox or Windows Update, for example)\

}}

Action Items

Action Item Status In Progress
Release Target `
Action Items
Who bug Action By When Completed date

[NEW] new [DONE] Done [MISSED] Miss

myk bug 741954 navigating "off origin" needs to open in browser by ship [NEW] new
myk bug 741955 bug 707836 if whitelisted 3rd party pages/domains are allowed those need to be clearly identified in chrome when they're opened by ship [NEW] new
Full Query
ID Summary Priority Status
707836 Handle URI navigation outside app domain for native apps -- VERIFIED
741954 [Security Review][Action Item]WebRT - off origin navigation -- RESOLVED

2 Total; 0 Open (0%); 1 Resolved (50%); 1 Verified (50%);

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

|Feature version=`

|SecReview action items=

Who bug Action By When Completed date

[NEW] new [DONE] Done [MISSED] Miss

myk bug 741954 navigating "off origin" needs to open in browser by ship [NEW] new
myk bug 741955 bug 707836 if whitelisted 3rd party pages/domains are allowed those need to be clearly identified in chrome when they're opened by ship [NEW] new
Full Query
ID Summary Priority Status
707836 Handle URI navigation outside app domain for native apps -- VERIFIED
741954 [Security Review][Action Item]WebRT - off origin navigation -- RESOLVED

2 Total; 0 Open (0%); 1 Resolved (50%); 1 Verified (50%);

}}

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