Revision Content

Firefox OS Developer Guide

All Firefox OS apps use standard web technologies like HTML, JavaScript, CSS and SVG, but sensitive app permissions are restricted to privileged apps, which are delivered in a signed archive through the Firefox Market, rather than being deployed dynamically by an arbitrary web server. The purpose is to allow these apps to be reviewed from a security and quality perspective, to ensure they can be trusted with increased permissions levels. This section is intended to guide developers in writing secure packaged apps.

Use the following checklists to avoid the most common web application vulnerabilities. Each checklist is prefaced with a short discussion of the problem.

HTML/JavaScript/CSS injection and XSS

Injected code runs with the privilege of your app, and can potentially abuse any permission the app is granted. A default CSP policy is applied to all privileged apps, but this does not completely rule out this attack vector (note: in particular, inline styles are not yet prevented).

Where possible use .textContent instead of .innerHTML.

Use DOM functions (createElement/setAttribute) or a trusted template system.

Secure communication

While SSL is generally good practice for any website which sends and receives sensitive user data (password, private, credit cards etc.), unencrypted data transfer is even more critical on mobile devices, as they are more likely to be used on untrusted and potentially hostile networks.

Use SSL when sending sensitive user data across the network.

Be sure to use SSL when framing third-party content such as third-party oauth providers.

Web activities

Web activities provide a mechanism to send and receive data from other applications. When you start a web activity, there is no guarantee which app will handle it. If there are multiple activities which can fulfill your request, it is up to the user to choose, and vice-versa, when handling an activity. Any content, including untrusted web content, can initiate an activity, so therefore all input needs to be validated and sanitized.

Sanitation for handlers

Sanitize all input parameters.

Be careful what functionality you expose.

Any content can invoke your handler. Validate the origin of the caller if you only want to accept activities from specific apps.

Sanitation for callers

Validate return values from web activity handlers.

Consider that any app may handle your request.

Inter-app communication

All input to applications needs to be validated and sanitized. Mind that some input is not obvious, so some sources might be easily overlooked.

Validate the origin and content of message events.

Be careful with URLs (including location.hash). Although linking from one app:// to another is prevented, some forced-browsing scenarios are still possible. For example, if your application sets the location via user input.

Client-side storage

The risk of using client-side storage in privileged web apps is no different than in any web content. However, given that many privileged applications are designed to function without internet access, client-side storage will more likely be used for sensitive data.

Keep user data to a minimum and avoid storage of private user information where possible.

Provide users with a way to clear sensitive data.

Consider encryption prior to storage for particularly sensitive data. Mind that keys stored on the device can be recovered even after deletion.

Content Security Policy

Privileged apps have a default Content Security Policy (CSP) applied to them. Apps can be hardened by applying a more restrictive CSP policy which prevents loading external content. Note that even with a restrictive CSP policy in place, it is likely possible for the app to send data to the internet as data exfiltration is not preventable by CSP.

Consider applying a more restrictive CSP policy as a defence-in-depth technique.

Permissions

The more permissions an app has, the greater the chance that those permissions might be abused in the case of a vulnerability. It is good practice to minimize permissions to only those APIs required by the application to function.

Only request the bare minimum of permissions necessary for your application to work.

Use access restrictions like read-only where the API supports them. See the access property in the table of permissions.

API-specific guidance

The corresponding permission names are given in parentheses.

Alarm API (alarms)

Alarm handlers should be short running. Running frequent alarms performing complex operations will drain battery life.

Conduct checks to ensure that private networks are not accessed (if possible).

tcp-socket

Conduct checks to ensure that private networks are not accessed (if possible).

Use TLS for sensitive data.

Firefox OS Reviewer Guide

This section is suposed to guide reviewers, be it developers or marketplace reviewers, to ensure consistent auditing for security controls. The two main goals of the review process are:

to apply the least privilege principle and minimize permission use.

to find security bugs.

HTML/JavaScript/CSS injection and XSS

For static apps, we only need to be concerned with DOM-based injection attacks and consider those JavaScript functions which result in changes to the HTML, CSS or scripts themselves. Below is a list of functions to audit.

JavaScript execution sinks

Note that all of these should actually be prevented by the default CSP policy, and as such should not be present in a privileged or certified web app. Included here for completeness mainly.

Permission-specific recommendations

The sections below detail the standard use case for each API, what the potential threats related to an API are, and guidelines for reviewers for apps which intend to use these APIs.

Alarm API

Permission

alarm

Use case

Similar to setTimeout, except that the app is started if it isn't currently running. Used by apps for polling or other background processing. The intended use case is that the app can specify when it needs to be woken up to do processing.

Threats

Firing frequent alarms to prevent an app from being shutown. Draining battery life or consume CPU time.

Review guidance

Look at alarm handler: Will it finish quickly? Does it do a lot of processing?

Poorly designed or belligerent channels which block other sound from being played, blocking the notification or alarm channels for extended periods of time. Using the content channel for playing sounds that aren't expected to be played when the user isn't handling the app.

Review guidance

Examine the use of audio channels.

Browser API

Permissions

browser

Use case

Act as a browser which allows the app to render web pages inside an iframe like it was a normal top-level browser frame.

Examine use of mozbrowser frames - how and why are they used? Ensure that the app is not using the mozbrowser permission for malicious purposes. Make sure that the app does not blindly trust input parameters from mozbrowser events.

Contacts API

Permissions

contacts

Use case

Access the address book. There are read, write and create levels. Reviewers should review the app in line with the description.

Threats

Scrape address book and send to third party server. Modify contents of address book without user consent.

Review guidance

Should compare description to access requested. If different, that should be flagged. Carefully review any code which changes contacts, especially functions which can be used to globally modify contacts.

Notification API

Permissions

desktop-notification

Use case

Send a notification that appears in the system tray. The user can click on the notification, and a event is sent to the application.

Threats

Spamming the user, not providing controls to the user to limit notifications.

Review guidance

Device Storage API

Permissions

device-storage: pictures|videos|music|sdcard|app

Use case

Access user media. Read, write, create access.

Threats

Vandalize user media, unauthorized access

Review guidance

Validate the requested access is what is being used. Should only have the least access that is required to do what the app wants to accomplish. Do not allow global delete.

FM Radio API

Permissions

fmradio

Use case

Control the user, grantable to all apps.

Threats

Power draining, privacy issues due to potential side-channel geolocation through FM band usage.

Review guidance

Ensure app is not using API as a tracking mechanism (or if it does this, make sure it at least informs the user of this intent).

GEO Location API

Permission

geolocation

Use case

Obtain current user location

Threats

Logging and storage of geolocation data

Review guidance

Examine when geolocation will be prompted for (is it at an appropriate time). Examine what is done with geolocation data, is it stored, how frequently is it accessed etc.

systemXHR

Permission

systemXHR

Use case

Cross-origin XHR without CORS. Allows an app to request data from the web (without cookies or auth credentials).

Threats

Requests to private address ranges, behind firewalls etc.

Review guidance

TCP Socket API

Permission

tcp-socket

Use case

Opening a client socket to any host (for example e-mail or CalDAV), or creating a raw socket back to their server (although this should preferably be done with web-sockets).

Threats

See systemXHR, internal address ranges, port scanning etc.

Review guidance

FirefoxOS Gecko

{{draft}}

Currently, FirefoxOS Gecko is a superset of Gecko (Firefox) - there are APIs that FirefoxOS has acccess to that Firefox does not.

General Firefox(Gecko) Terminology

Content - Something (most commonly script) loaded from an untrusted source (e.g., a web page). In security discussions 'content' can refer to the set of restricted privileges made available to scripts in web content.

Chrome - Something pertaining to the browser (as oppsed to web content). In security discussions, this most commonly refers to a set of privileges which allows code to do everything (unlike web content, which is restricted). Has system principal which passes all security checks (can do anything, can operate as any principal).

Wrappers - Firefox relies on wrappers to provide 'safe' representations of objects from one context in another (e.g., chrome from content and vice versa). In simple terms, wrappers can be thought of as filtering proxies which enforce the rules on how content and script from different principals may interact.

XOW -> XPCCrossOriginWrapper - automatically created when an object from one domain is exposed to content from another domain

CERT has a C and C++ guideline that might be useful. There are, obviously, a myriad of other resources to learn about C/C++ security.

Content/Chrome Segregation

Content/Chrome segregation vulnerabilities are very dangerous as Chrome has 'system principal' and is not subjected to security checks (same origin policy). This is an example of a chrome/content segregation vulnerability that lead to

https://bugzilla.mozilla.org/show_bug.cgi?id=801305

Specific Vulnerabilities

One important difference between writing web content and chrome code is that in the latter, iframes have chrome privileges by default. If this is not desirable (and it probably isn't) you'll want to explicitly specify it's for content -- e.g., iframe.setAttribute("type", "content").

Javascript in Chrome code, unless explicitly needs Chrome privileges, should be run in Sandboxes

Take care when using wrappedJSObject on content objects from chrome code (for more information on safely accessing content DOM from chrome, refer to this document)

In Chrome code, avoid using dangerous JS functions like eval, setTimeout(string, time), etc. and other related functions if at all possible.

Content being able to access data/functionality it shouldn't because of a lack of security checks in chrome. Usually, wrappers are used to mitigate this threat.

Content passing malicious object to Chrome in order to get Chrome to access data or functionality for it. Content can pass malicious objects to Chrome in a few different ways:

Content can pass the object as an argument to any chrome-implemented object it can reference, since functions are callable even without __exposedProps__

Content can set the object as a property that has been exposed as 'w' with __exposedProps__

Content can stick them into a chrome array or typedarray, since arrays are accessible even without __exposedProps__

Process Segregation

cpmm and ppmm, child process and parent process communication. not using cpmm, ppmm to talk between paretn and child

ipc messages to talk with each other, and they include request id

Other Data Validation & Sanitization

Validate Permission Model

(1 __exposedProps__, make sure we aren't exposing stuff we shouldn't. 2 maybe a content object doesn't have direct access to something, but maybe a method opened to the content object can manipulate something it shouldn't) <--- this might be more appropriate in the chrome vs content section.

When talking about the browser, there are more or less 3 types: chrome, content and null. When talking about the web, SOP (more or less), the idea of an origin is a principal. Then, a permission is either allow, deny or unknown and is determined based of the type of principals interacting

I would imagine permission checking happens automatically at runtime... need to look more into this.