B2G App Security Model/Threat Model

Definitions

Definitions for the following phrases are missing from this document:

• CSP
• HSTS
• Web Apps
• Static Web Apps
• B2G platform

Scope of this Document

The scope of this document covers the following: TBD

Threats Summary

In order to discuss the permissions model for B2G, we need to discuss the threats posed. By default Web Apps are untrusted, not unlike any other web page, and therefore the permissions available to them are limited. The goal is to mitigate the threats faced by Web Apps to a level where they can be trusted to perform sensitive functions. Note that this should be a considered an initial draft as use cases and system design of B2G is still under discussion.

The threats considered include:

• Network Compromise
• Vulnerable Web App
• Web Server Compromise
• Platform Vulnerabilities
• Malicious Web App
• Web App Spoofing

These controls for these threats fall into two basic categories:

• Restricting the distribution of sensitive permissions
• Increasing the control over the integrity and authenticity of a Web App code

Ultimately the B2G model will need to be flexible enough to account for all possible Web Apps, from the most critical of phone functions to those Web Apps which require no additional permissions at all. Overly strict controls for apps which do not require permissions stifles development and adoption, but not providing controls for critical functions will destroy confidence in the platform.

Threats

Network Compromise

Web Apps hosted remotely face network threats upon every launch (note that even cached offline apps have their manifest checked upon each launch). Web Apps may (and are expected to) send information back to remote servers or load additional scripts and resources, although this may not be necessary (or appropriate) for critical system Web Apps.

Potential Countermeasures

• TLS/SSL
• HTTP Strict Transport Security(HSTS)
• Static Web Apps with use explicit update process
• Enforce a Content Security Policy (CSP) policy on critical Web Apps
  • Prevent loading of remote scripts for critical apps
  • Prevent loading of remote content altogether

Vulnerable Web App

Web application layer vulnerabilities are very common occurrences and should be expected in Web Apps. The consequence for most web applications issues will be the same as for website i.e. compromise will mainly impact the organization running the app, e.g. fraud from an internet banking Web App. But in addition, for a B2G app with permissions, any attack with the ability to inject JavaScript into application code will have the ability to perform actions on the phone with the permissions of the application.

Potential Countermeasures

• Static HTML Web Apps: Restrict dangerous permissions to static HTML applications - easier to review, less likely to suffer web application flaws).
  • Static apps could also be signed; where as dynamic web applications cannot (note signing does not mitigate the vulnerable Web App case really, it is more a control over the compromised server case, see below)
  • Explicit update process: Introduce explicit updates of static Web Apps (so a compromised server does not directly translate to compromise phone – a device is only compromised the next time it is updated, by which time the issue may be addressed).
  • Enforce a CSP policy on static Web Apps (having static code is no benefit, if vulnerable code is just loaded at runtime)
    • Prevent loading of remote scripts for critical apps
    • Prevent loading of remote content altogether
• Segregating critical B2G permissions, and limiting distribution of these to a subset of applications
  • Security of web application and server could be under direct control of the store (e.g. a Telco which hosts its own apps)
  • Contractual controls with third parties

Web Server Compromise

Similar to the vulnerable web application case – a compromised server hosting a Web App would allow the attacker to execute actions on the phone with the permission of the compromised Web App.

Potential Countermeasures

• Controls are largely the same as for vulnerable web applications - see above.
• Code Signing is an effective control here (assuming static web apps). Signing with a key not stored on the hosting server so that compromise of the server doesn’t directly result compromised phones.

Platform Vulnerabilities

Vulnerabilities in the B2G platform might allow a range of security issues:

• Same-origin bypass or other privilege escalation bug, allowing an application to access data or functionality it shouldn’t have access to
• A memory corruption vulnerability that gives control of content process
• Attacks against other processes (media server, rild etc)?

Potential Countermeasures

• Effective security update process
• Unique application identifiers? (i.e. spoofing an domain is not enough to gain access to another application’s permissions)
• Sandboxing low-privileged content processes
• Reduce attack vectors to vulnerable code
  • Prevent loading of remote scripts for critical apps
  • Prevent loading of remote content
  • I.e. enforce a CSP policy on critical Web Apps

Malicious Web App

A user installs an application that turns to be malicious. The are many different ways this could occur:

• A benign application could change to be malicious, or load a malicious script
• An untrustworthy store might be trusted by the user
• The user might be tricked into installing an application

Potential Countermeasures

• Process for removing permissions from known bad Web Apps(maybe even blocking them, or adding them to phishing and malware protection list)
• Trusted stores pre-installed on the B2G device, and contracts with third-party developers
• Appropriate warnings and acknowledgements when adding new trusted stores
• Trust delegation model where store can trust other stores to grant only certain permissions (i.e. maintain direct control over critical permissions)
• Trusted UI for installing application
• Requirement for HSTS for Apps granted permissions (Strict SSL even?)
• User can audit permission usage of an app so s/he can uninstall the app if it seems to be doing something undesirable

Web App Spoofing

A malicious website or Web App can imitate the look and feel of another Web App in an identical manner (i.e. this threat is higher than on a platform that has native apps, since Web App behavior could be identical between apps. The attacks that are possible here are varied, complex and constantly changing as new security controls are introduced. Some attacks might be:

• An website spoofing another to phish the user for credentials or other sensitive information (e.g. spoof wifi settings dialog to phish wifi credentials?)
• Spoof another application in order to be sold instead of legitimate application (close the malicious application case above)

Potential Countermeasures

• Most countermeasures to malicious web app case, also apply here
• Web Apps must be installed to gain permissions (ie websites on the same domain as a web app will not get the same permissions)
• Trusted UI

Privacy-invasive but non-malicious app

An application wants information about the user that the user is not comfortable sharing with the app. The application is not outright malicious; it follows FTC guidelines (e.g., it has a privacy policy). However, the user might not like what the app will do with his/her data. Some examples might be:

• An app tags posts with your current location
• An app turns the camera on for an optional chatting feature
• An app collects contact lists for marketing purposes

Potential Countermeasures

• Several of the countermeasures for the malicious web app case also apply here
• Contracts between web sites/apps and the stores that distribute them