Security guidelines

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.
• Avoid string concatenation, especially for HTML attributes.
• Declare stricter-than-default CSP, using the manifest's CSP directive.

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.
• Be careful handling any mozbrowser events from child frames (see Browser API section below).

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.
• In case of local-only content, apply: "csp": "default-src none; script-src self; image-src self;style-src self;"

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.

Audio Policy (audio-channel-normal, audio-channel-content, audio-channel-notification, audio-channel-alarm)

Use the channels for their intended purpose only. See Audio channels.

Especially, do not use the notification and alarm channels for longer periods of time. Do not use them to play music.

Browser API (browser)

Be careful when listening to mozbrowser* events. Validate and sanitize all parameters.

Ensure that mozbrowser is set on all untrusted content.

More here

Contacts (contacts)

Only request required access (API supports readonly, readwrite, readcreate, or createonly).

If readwrite access is needed, be especially careful not to delete or corrupt user contact data.

Consider keeping all your app's contacts separate from existing contacts by tagging them in some manner.

Notification API (desktop-notification)

Provide reasonable settings for the user to control notification frequency or disable notifications entirely.

device-storage

Only request access needed (API supports readonly, readwrite, readcreate, or createonly).

Careful not to modify or delete user media (code checks into code to prevent global deletes etc.).

Abide by Mozilla privacy principles.

fmradio

None, don't geolocate ;)

geolocation

Provide user a way to enable and disable geolocation

Don’t keep log of geolocation without informing the user.

Provide mechanism to clear information.

Abide by Mozilla privacy principles.

systemXHR

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.

• eval
• setTimeout (with a string argument)
• setInterval (with a string argument)
• new Function
• crypto.generateCRMFRequest (5th argument is eval'd)
• .setAttribute("onXXX...", userinput) for setting event handlers (e.g. onmouseover, onclick, ..)
• .addEventListener(evt, handler)for setting event handlers, like above
• .onXXX= for setting event handlers, like above
• document.createElement('script');

HTML element sinks

Dynamic creation of HTML elements. Note that script tags are prevent by CSP.

• document.write
• document.writeln
• anyElement.innerHTML
• anyElement.outerHTML
• Range.createContextualFragment
• parseFromString (DOMParser)
• document.createElement might create "dangerous" tags as listed below.

Location sinks

Input used as part or all of a URL loaded by the app can be a risk. Check for JavaScript which:

• assigns input to src, data, href, or action attributes on supported elements.
• setting window.location, document.location etc.

CSS

• Arbitrary injection into stylesheets, style elements, and inline styles
• -moz-binding (input here)
• url (input here)

Web Activities

• Examine web activity handlers
• Examine manifest to see activities registered
• Examine the handler function for these activities. Search for mozSetMessageHandler('activity', …)
• Examine initiation of Web Activities
• new mozActivity(...)

Client Side Storage

Examine use of client-side storage mechanisms:

• localStorage
• indexedDB
• sessionStorage
• document.cookie
• navigator.getDeviceStorage(...) - requires permission

Content Security Policy

• Review custom Content Security Policy restrictions if they exist.
• Consider suggesting a CSP for the app if one isn't already in place.
• Recommend a strict policy for apps which don’t load any resources over the network.

Secure communication

• Examine XHR requests, form posts, WebSockets. Ensure use of TLS.
• If the app has TCPsocket permission, also examine this usage.

App layer Denial of Service

• Insecure storage of sensitive data
• App layer DoS (e.g. break an Gaia app, or the phone entirely, make a feature unusable - fill up the gallery with fake photos etc)
• Does that app use encrypted channels (SSL)
• Inclusion of third party content (framed or otherwise)
• Communication with other frames or windows (e.g. onmessage handlers)

Inter-app communication

• onmessage, addEventListener('message', ...) - Message handlers should validate the origin of messages.
• postMessage - specify the target origin instead of using "*"
• Web activities (see above)
• mozBrowser events (see below)

Client-side storage

• indexedDB
• localStorage
• sessionStorage
• cookie

Other areas

• window.open, showModalDialog
• mozSetMessageHandler(<name of message>,...) - Handles system messages like alarm, activity, notification, bluetooth-*, headset-button, ussd-recieved, sms-*, telephony-*, and icc-stkcommand.
• Use of XMLHttpRequest - apart from ensuring data is sent over secure channels, ensure that response data is appropriately validated and sanitized.

Review the App Manifest

• Ensure type is web or privileged
• Review permissions requested for appropriateness. Consider allow restrictions.
• Review system messages listened for.
• Review activities handled.

Permissions

Find unused permission and APIs used without the appropriate permissions. Regex collection to find privileged API use:

• /mozAlarms/
• /window\.open\s*\(\s*[\",\']attention/
• /mozaudiochannel/
• /mozBluetooth
• /mozCameras/
• /mozCellBroadcast/
• /mozContacts/
• /mozNotification/
• /\.getDeviceStorage\s*\(\s*[\",\'](music|videos|pictures|sdcard|apps)/
• /mozapp\/
• /mozFMRadio/
• /\.geolocation/
• /\.addIdleObserver/
• /mozMobileConnection/
• /moznetworkupload/
• /moznetworkdownload/
• /mozPermissionSettings/
• /mozPower/
• /mozSettings/
• /mozSms/
• /mozSystem/
• /mozTCPSocket/
• /mozTelephony/
• /mozTime/
• /mozVoicemail/
• /mozApps.mgmt/
• /mozWifiManager/
• /mozKeyboard/

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?

 

Audio Policy

Permissions	audio-channel-normal, audio-channel-content, audio-channel-notification, audio-channel-alarm
Use case	Competing with other audio channels, leave audio running when the user leaves the app (e.g. background music app). Note, the hierarchy of which channel gets preference: normal & content < notification < alarm < ringer < telephony < public notifications (iItalicized channels for certified apps only).
Threats	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.
Threats	Bypass same origin, eg. using getScreenshot, not accurately displaying user location, insecure handling of mozbrowser events. Click-jacking of warning messages like untrusted certificate warning page.
Review guidance	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