Firefox OS Developer Guide
Use the following checklists to avoid the most common web application vulnerabilities. Each checklist is prefaced with a short discussion of the problem.
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
- Use DOM functions (
setAttribute) or a trusted template system.
- Avoid string concatenation, especially for HTML attributes.
- Declare stricter-than-default CSP, using the manifest's CSP directive.
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 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.
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).
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.
- DOM Crypt is under devlopment
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;"
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.
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.
- 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.
- None, don't geolocate ;)
- 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.
- Conduct checks to ensure that private networks are not accessed (if possible).
- 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.
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.
setTimeout(with a string argument)
setInterval(with a string argument)
crypto.generateCRMFRequest(5th argument is eval'd)
.setAttribute("onXXX...", userinput)for setting event handlers (e.g.
.addEventListener(evt, handler)for setting event handlers, like above
.onXXX=for setting event handlers, like above
HTML element sinks
Dynamic creation of HTML elements. Note that script tags are prevent by CSP.
document.createElementmight create "dangerous" tags as listed below.
- assigns input to
actionattributes on supported elements.
- <arbitrary elements="" injection="" inline="" into="" li="" style="" styles="" stylesheets="">Arbitrary injection into stylesheets, style elements, and inline styles</arbitrary>
- Examine web activity handlers
- Examine manifest to see activities registered
- Examine the handler function for these activities. Search for
- Examine initiation of Web Activities
Client Side Storage
Examine use of client-side storage mechanisms:
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.
- 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.
addEventListener('message', ...)- Message handlers should validate the origin of messages.
postMessage- specify the target origin instead of using "*"
- Web activities (see above)
mozBrowserevents (see below)
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
typeis web or privileged
permissionsrequested for appropriateness. Consider
- Review system
Find unused permission and APIs used without the appropriate permissions. Regex collection to find privileged API use:
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.
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
Currently, FirefoxOS Gecko is a superset of Gecko (Firefox) - there are APIs that FirefoxOS has acccess to that Firefox does not.
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.
Principals - A principal represents a security context. There are 3 types of principals:
Secure Coding in C/C++
In addition to web security principles, understanding secure coding practices and common C/C++ vulnerabilities is essential to a successful Gecko security review. Things like buffer overflows, format string vulnerabilities, integer overflow, use after free, double free, etc.
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
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").
|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)|
|Remember that functions defined in chrome context execute with chrome privileges|
|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:
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.
Denial of Service