Security guidelines

  • Revision slug: Web/Apps/Security_guidelines
  • Revision title: Security guidelines
  • Revision id: 481343
  • Created:
  • Creator: omerta
  • Is current revision? No
  • Comment

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.
  • 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.
  • 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;"

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 elements="" injection="" inline="" into="" li="" style="" styles="" stylesheets="">Arbitrary injection into stylesheets, style elements, and inline styles</arbitrary>
  • -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  

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
  • SOW -> XPCSystemOnlyWrapper - automatically created when native anonymous content is exposed to JS
  • COW -> XPCChromeObjectWrapper - automatically created when a chrome object is exposed to content
  • SJOW -> XPCSafeJSObjectWrapper -> Ability to safely access non-natively-implemented content defined objects
  • XrayWrapper -> XPCNativeWrapper - A way to wrap up an object so that it's safe to access from privileged code.

Principals - A principal represents a security context. There are 3 types of principals:

  • System - Passes all security checks. It subsumes itself and all other principals, which means it can operate on any principal, regardless of its security settings.
  • null - fails almost all security checks. It has no privileges and can't be accessed by anything but itself and chrome. They aren't same-origin with anything but themselves.
  • other/web - a triplet of <origin, appId, inbrowserframe>
Compartments -

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.

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)
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:

  • 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.

Denial of Service

Code Execution

https://bugzilla.mozilla.org/show_bug.cgi?id=479560#c0

[1] Safely accessing content DOM from chrome

[2] Firefox Security Basics for Developers [en-US]

[3] Gecko security check basics

[4] Security check basics

[5] Security wrappers, part 1: Basics

Revision Source

<h2 id="Firefox_OS_Developer_Guide">Firefox OS Developer Guide</h2>
<p>All Firefox OS apps use <strong>standard web technologies</strong> like HTML, JavaScript, CSS and SVG, but <strong>sensitive app permissions are restricted to privileged apps</strong>, which are delivered in a <strong>signed archive</strong> through the Firefox Market, rather than being deployed dynamically by an arbitrary web server. The purpose is to <strong>allow these apps to be reviewed</strong> 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.</p>
<p>Use the following checklists to avoid the most common web application vulnerabilities. Each checklist is prefaced with a short discussion of the problem.</p>
<h3 id="HTML.2FJavaScript.2FCSS_injection_and_XSS">HTML/JavaScript/CSS injection and XSS</h3>
<p>Injected code runs with the privilege of your app, and can potentially abuse any permission the app is granted. A <a href="https://developer.mozilla.org/en-US/docs/Apps/CSP">default CSP policy</a>&nbsp;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).</p>
<ul>
  <li>Where possible use <code>.textContent</code> instead of <code>.innerHTML</code>.</li>
  <li>Use DOM functions (<code>createElement</code>/<code>setAttribute</code>) or a trusted template system.</li>
  <li>Avoid string concatenation, especially for HTML attributes.</li>
  <li>Declare stricter-than-default CSP, using the manifest's <a href="https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp">CSP</a> directive.</li>
</ul>
<h3 id="Secure_communication">Secure communication</h3>
<p>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.</p>
<ul>
  <li>Use SSL when sending sensitive user data across the network.</li>
  <li>Be sure to use SSL when framing third-party content such as third-party oauth providers.</li>
</ul>
<h3 id="Web_activities">Web activities</h3>
<p>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.</p>
<ul>
  <li>Sanitation for handlers
    <ul>
      <li>Sanitize all input parameters.</li>
      <li>Be careful what functionality you expose.</li>
      <li>Any content can invoke your handler. Validate the origin of the caller if you only want to accept activities from specific apps.</li>
    </ul>
  </li>
  <li>Sanitation for callers
    <ul>
      <li>Validate return values from web activity handlers.</li>
      <li>Consider that any app may handle your request.</li>
    </ul>
  </li>
</ul>
<h3 id="Inter-app_communication">Inter-app communication</h3>
<p>All input to applications needs to be validated and sanitized. Mind that some input is not obvious, so some sources might be easily overlooked.</p>
<ul>
  <li>Validate the origin and content of <em>message</em> events.</li>
  <li>Be careful with URLs (including <code>location.hash</code>). 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.</li>
  <li>Be careful handling any <em>mozbrowser </em>events from child frames (see Browser API section below).</li>
</ul>
<h3 id="Client-side_storage">Client-side storage</h3>
<p>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.</p>
<ul>
  <li>Keep user data to a minimum and avoid storage of private user information where possible.</li>
  <li>Provide users with a way to clear sensitive data.</li>
  <li>Consider encryption prior to storage for particularly sensitive data. Mind that keys stored on the device can be recovered even after deletion.</li>
  <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=649154" title="https://bugzilla.mozilla.org/show_bug.cgi?id=649154">DOM Crypt</a> is under devlopment</li>
</ul>
<h3 id="Content_Security_Policy">Content Security Policy</h3>
<p>Privileged apps have a <a href="https://developer.mozilla.org/en-US/docs/Apps/CSP">default Content Security Policy (CSP)</a> 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.</p>
<ul>
  <li>Consider applying a more restrictive CSP policy as a defence-in-depth technique.</li>
  <li>In case of local-only content, apply: <code>"csp": "default-src none; script-src self; image-src self;style-src self;"</code></li>
</ul>
<h3 id="Permissions">Permissions</h3>
<p>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.</p>
<ul>
  <li>Only request the bare minimum of permissions necessary for your application to work.</li>
  <li>Use access restrictions like <em>read-only</em> where the API supports them. See the <em>access</em> property in the <a href="https://developer.mozilla.org/en-US/docs/Apps/App_permissions">table of permissions</a>.</li>
</ul>
<h3 id="API-specific_guidance">API-specific guidance</h3>
<p>The corresponding permission names are given in parentheses.</p>
<dl>
  <dt>
    Alarm API (alarms)</dt>
  <dd>
    Alarm handlers should be short running. Running frequent alarms performing complex operations will drain battery life.</dd>
  <dt>
    Audio Policy (audio-channel-normal, audio-channel-content, audio-channel-notification, audio-channel-alarm)</dt>
  <dd>
    Use the channels for their intended purpose only. See <a href="https://wiki.mozilla.org/WebAPI/AudioChannels" title="https://wiki.mozilla.org/WebAPI/AudioChannels">Audio channels</a>.</dd>
  <dd>
    Especially, do not use the <em>notification</em> and <em>alarm</em> channels for longer periods of time. Do not use them to play music.</dd>
  <dt>
    Browser API (browser)</dt>
  <dd>
    Be careful when listening to <em>mozbrowser*</em> events. Validate and sanitize all parameters.</dd>
  <dd>
    Ensure that <em>mozbrowser</em> is set on all untrusted content.</dd>
  <dd>
    <span style="background-color:#ff0000;">More here</span></dd>
  <dt>
    Contacts (contacts)</dt>
  <dd>
    Only request required access (API supports <em>readonly</em>, <em>readwrite</em>, <em>readcreate</em>, or <em>createonly</em>).</dd>
  <dd>
    If readwrite access is needed, be especially careful not to delete or corrupt user contact data.</dd>
  <dd>
    Consider keeping all your app's contacts separate from existing contacts by tagging them in some manner.</dd>
  <dt>
    Notification API (desktop-notification)</dt>
  <dd>
    Provide reasonable settings for the user to control notification frequency or disable notifications entirely.</dd>
  <dt>
    device-storage</dt>
  <dd>
    Only request access needed (API supports <em>readonly</em>, <em>readwrite</em>, <em>readcreate</em>, or <em>createonly</em>).</dd>
  <dd>
    Careful not to modify or delete user media (code checks into code to prevent global deletes etc.).</dd>
  <dd>
    Abide by Mozilla privacy principles.</dd>
  <dt>
    fmradio</dt>
  <dd>
    <span style="background-color:#ff0000;">None, don't geolocate ;)</span></dd>
  <dt>
    geolocation</dt>
  <dd>
    Provide user a way to enable and disable geolocation</dd>
  <dd>
    Don’t keep log of geolocation without informing the user.</dd>
  <dd>
    Provide mechanism to clear information.</dd>
  <dd>
    Abide by Mozilla privacy principles.</dd>
  <dt>
    systemXHR</dt>
  <dd>
    Conduct checks to ensure that private networks are not accessed (if possible).</dd>
  <dt>
    tcp-socket</dt>
  <dd>
    Conduct checks to ensure that private networks are not accessed (if possible).</dd>
  <dd>
    Use TLS for sensitive data.</dd>
</dl>
<h2 id="Firefox_OS_Reviewer_Guide">Firefox OS Reviewer Guide</h2>
<p>This section is suposed to guide reviewers, be it developers or marketplace reviewers, to ensure <strong>consistent auditing</strong> for security controls. The two main goals of the review process are:</p>
<ul>
  <li>to apply the <strong>least privilege principle</strong> and minimize permission use.</li>
  <li>to <strong>find security bugs</strong>.</li>
</ul>
<h3 id="HTML.2FJavaScript.2FCSS_injection_and_XSS">HTML/JavaScript/CSS injection and XSS</h3>
<p>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.</p>
<h4 id="JavaScript_execution_sinks">JavaScript execution sinks</h4>
<p>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.</p>
<ul>
  <li><code>eval</code></li>
  <li><code>setTimeout</code> (with a string argument)</li>
  <li><code>setInterval</code> (with a string argument)</li>
  <li><code>new Function</code></li>
  <li><code>crypto.generateCRMFRequest</code> (5th argument is eval'd)</li>
  <li><code>.setAttribute("onXXX...", userinput)</code> for setting event handlers (e.g. <code>onmouseover</code>, <code>onclick</code>, ..)</li>
  <li><code>.addEventListener(evt, handler)</code>for setting event handlers, like above</li>
  <li><code>.onXXX=</code> for setting event handlers, like above</li>
  <li><code>document.createElement('script');</code></li>
</ul>
<h4 id="HTML_element_sinks">HTML element sinks</h4>
<p>Dynamic creation of HTML elements. Note that script tags are prevent by CSP.</p>
<ul>
  <li><code>document.write</code></li>
  <li><code>document.writeln</code></li>
  <li><code>anyElement.innerHTML</code></li>
  <li><code>anyElement.outerHTML</code></li>
  <li><code>Range.createContextualFragment</code></li>
  <li><code>parseFromString</code> (DOMParser)</li>
  <li><code>document.createElement</code> might create "dangerous" tags as listed below.</li>
</ul>
<h4 id="Location_sinks">Location sinks</h4>
<p>Input used as part or all of a URL loaded by the app can be a risk. Check for JavaScript which:</p>
<ul>
  <li>assigns input to <code>src</code>, <code>data</code>, <code>href</code>, or <code>action</code> attributes on supported elements.</li>
  <li>setting <code>window.location</code>, <code>document.location</code> etc.</li>
</ul>
<h4 id="CSS">CSS</h4>
<ul>
  <li><arbitrary elements="" injection="" inline="" into="" li="" style="" styles="" stylesheets="">Arbitrary injection into stylesheets, style elements, and inline styles</arbitrary></li>
  <li><code>-moz-binding</code> <span style="background-color:#ff0000;">(input here)</span></li>
  <li><code>url</code> <span style="background-color:#ff0000;">(input here)</span></li>
</ul>
<h4 id="Web_Activities">Web Activities</h4>
<ul>
  <li>Examine web activity handlers</li>
  <li>Examine manifest to see activities registered</li>
  <li>Examine the handler function for these activities. Search for <code>mozSetMessageHandler('activity', …)</code></li>
  <li>Examine initiation of Web Activities</li>
  <li><code>new mozActivity(...)</code></li>
</ul>
<h4 id="Client_Side_Storage">Client Side Storage</h4>
<p>Examine use of client-side storage mechanisms:</p>
<ul>
  <li><code>localStorage</code></li>
  <li><code>indexedDB</code></li>
  <li><code>sessionStorage</code></li>
  <li><code>document.cookie</code></li>
  <li><code>navigator.getDeviceStorage(...)</code> - requires permission</li>
</ul>
<h4 id="Content_Security_Policy">Content Security Policy</h4>
<ul>
  <li>Review custom Content Security Policy restrictions if they exist.</li>
  <li>Consider suggesting a CSP for the app if one isn't already in place.</li>
  <li>Recommend a strict policy for apps which don’t load any resources over the network.</li>
</ul>
<h4 id="Secure_communication">Secure communication</h4>
<ul>
  <li>Examine XHR requests, form posts, WebSockets. Ensure use of TLS.</li>
  <li>If the app has TCPsocket permission, also examine this usage.</li>
</ul>
<h4 id="App_layer_Denial_of_Service">App layer Denial of Service</h4>
<ul>
  <li>Insecure storage of sensitive data</li>
  <li>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)</li>
  <li>Does that app use encrypted channels (SSL)</li>
  <li>Inclusion of third party content (framed or otherwise)</li>
  <li>Communication with other frames or windows (e.g. <code>onmessage</code> handlers)</li>
</ul>
<h4 id="Inter-app_communication">Inter-app communication</h4>
<ul>
  <li><code>onmessage</code>, <code>addEventListener('message', ...)</code> - Message handlers should validate the origin of messages.</li>
  <li><code>postMessage</code> - specify the target origin instead of using "*"</li>
  <li>Web activities (see above)</li>
  <li><code>mozBrowser</code> events (see below)</li>
</ul>
<h4 id="Client-side_storage">Client-side storage</h4>
<ul>
  <li><code>indexedDB</code></li>
  <li><code>localStorage</code></li>
  <li><code>sessionStorage</code></li>
  <li><code>cookie</code></li>
</ul>
<h4 id="Other_areas">Other areas</h4>
<ul>
  <li><code>window.open</code>, <code>showModalDialog</code></li>
  <li><code>mozSetMessageHandler(&lt;name of message&gt;,...)</code> - Handles system messages like <em>alarm</em>, <em>activity</em>, <em>notification</em>,<em> bluetooth-*</em>, <em>headset-button</em>, <em>ussd-recieved</em>, <em>sms-*</em>, <em>telephony-*</em>, and <em>icc-stkcommand</em>.</li>
  <li>Use of <code>XMLHttpRequest</code> - apart from ensuring data is sent over secure channels, ensure that response data is appropriately validated and sanitized.</li>
</ul>
<h3 id="Review_the_App_Manifest">Review the App Manifest</h3>
<ul>
  <li>Ensure <code>type</code> is <em>web</em> or <em>privileged</em></li>
  <li>Review <code>permissions</code> requested for appropriateness. Consider <code>allow</code> restrictions.</li>
  <li>Review system <code>messages</code> listened for.</li>
  <li>Review <code>activities</code> handled.</li>
</ul>
<h4 id="Permissions">Permissions</h4>
<p>Find unused permission and APIs used without the appropriate permissions. Regex collection to find privileged API use:</p>
<ul>
  <li><code>/mozAlarms/</code></li>
  <li><code>/window\.open\s*\(\s*[\",\']attention/</code></li>
  <li><code>/mozaudiochannel/</code></li>
  <li><code>/mozBluetooth</code></li>
  <li><code>/mozCameras/</code></li>
  <li><code>/mozCellBroadcast/</code></li>
  <li><code>/mozContacts/</code></li>
  <li><code>/mozNotification/</code></li>
  <li><code>/\.getDeviceStorage\s*\(\s*[\",\'](music|videos|pictures|sdcard|apps)/</code></li>
  <li><code>/mozapp\/</code></li>
  <li><code>/mozFMRadio/</code></li>
  <li><code>/\.geolocation/</code></li>
  <li><code>/\.addIdleObserver/</code></li>
  <li><code>/mozMobileConnection/</code></li>
  <li><code>/moznetworkupload/</code></li>
  <li><code>/moznetworkdownload/</code></li>
  <li><code>/mozPermissionSettings/</code></li>
  <li><code>/mozPower/</code></li>
  <li><code>/mozSettings/</code></li>
  <li><code>/mozSms/</code></li>
  <li><code>/mozSystem/</code></li>
  <li><code>/mozTCPSocket/</code></li>
  <li><code>/mozTelephony/</code></li>
  <li><code>/mozTime/</code></li>
  <li><code>/mozVoicemail/</code></li>
  <li><code>/mozApps.mgmt/</code></li>
  <li><code>/mozWifiManager/</code></li>
  <li><code>/mozKeyboard/</code></li>
</ul>
<h4 id="Permission-specific_recommendations">Permission-specific recommendations</h4>
<p>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.</p>
<dl>
  <dt>
    &nbsp;</dt>
  <dt id="Alarm_API_(alarms)">
    Alarm API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permission</strong></th>
          <td>alarm</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Similar to <code>setTimeout</code>, 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.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Firing frequent alarms to prevent an app from being shutown. Draining battery life or consume CPU time.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>
            <p>Look at alarm handler: Will it finish quickly? Does it do a lot of processing?</p>
          </td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="Audio_Policy_(audio-channel-normal.2C_audio-channel-content.2C_audio-channel-notification.2C_audio-channel-alarm)">
    Audio Policy</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permissions</strong></th>
          <td>audio-channel-normal, audio-channel-content, audio-channel-notification, audio-channel-alarm</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>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 &amp; content &lt; notification &lt; alarm &lt;<em> ringer</em> &lt; <em>telephony</em> &lt; <em>public notifications</em> (iItalicized channels for certified apps only).</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Poorly designed or belligerent channels which block other sound from being played, blocking the <em>notification</em> or <em>alarm</em> channels for extended periods of time. Using the <em>content</em> channel for playing sounds that aren't expected to be played when the user isn't handling the app.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>Examine the use of audio channels.</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="Browser_API_(browser)">
    Browser API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permissions</strong></th>
          <td>browser</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Act as a browser which allows the app to render web pages inside an iframe like it was a normal top-level browser frame.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Bypass same origin, eg. using <code>getScreenshot</code>, not accurately displaying user location, insecure handling of <em>mozbrowser</em> events. Click-jacking of warning messages like untrusted certificate warning page.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>Examine use of <em>mozbrowser</em> frames - how and why are they used? Ensure that the app is not using the <em>mozbrowser</em> permission for malicious purposes. Make sure that the app does not blindly trust input parameters from <em>mozbrowser</em> events.</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="Contacts_(contacts)">
    Contacts API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permissions</strong></th>
          <td>contacts</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Access the address book. There are <em>read</em>, <em>write</em> and <em>create</em> levels. Reviewers should review the app in line with the description.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Scrape address book and send to third party server. Modify contents of address book without user consent.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>Should compare description to access requested. &nbsp;If different, that should be flagged. Carefully review any code which changes contacts, especially functions which can be used to globally modify contacts.</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="Notification_Api_(desktop-notification)">
    Notification API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permissions</strong></th>
          <td>desktop-notification</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Send a notification that appears in the system tray. The user can click on the notification, and a event is sent to the application.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Spamming the user, not providing controls to the user to limit notifications.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>&nbsp;</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="Device_Storage_API_(device-storage.3A_(pictures.7Cvideos.7Cmusic.7Csdcard.7Capp)">
    Device Storage API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permissions</strong></th>
          <td>device-storage: pictures|videos|music|sdcard|app</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Access user media. Read, write, create access.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Vandalize user media, unauthorized access</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>Validate the requested access is what is being used. &nbsp;Should only have the least access that is required to do what the app wants to accomplish. Do not allow global delete.</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="fmradio">
    FM Radio API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permissions</strong></th>
          <td>fmradio</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Control the user, grantable to all apps.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Power draining, privacy issues due to potential side-channel geolocation through FM band usage.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>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).</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt>
    GEO Location API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permission</strong></th>
          <td>geolocation</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Obtain current user location</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Logging and storage of geolocation data</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>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.</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="systemXHR">
    systemXHR</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permission</strong></th>
          <td>systemXHR</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>Cross-origin XHR without CORS. Allows an app to request data from the web (without cookies or auth credentials).</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>Requests to private address ranges, behind firewalls etc<strong>.</strong></td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>&nbsp;</td>
        </tr>
      </tbody>
    </table>
  </dd>
  <dd>
    &nbsp;</dd>
  <dt id="tcp-socket">
    TCP Socket API</dt>
  <dd>
    <table class="standard-table">
      <tbody>
        <tr>
          <th scope="row"><strong>Permission</strong></th>
          <td>tcp-socket</td>
        </tr>
        <tr>
          <th scope="row"><strong>Use case</strong></th>
          <td>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<strong>)</strong>.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Threats</strong></th>
          <td>See systemXHR, internal address ranges, port scanning etc.</td>
        </tr>
        <tr>
          <th scope="row"><strong>Review guidance</strong></th>
          <td>&nbsp;</td>
        </tr>
      </tbody>
    </table>
  </dd>
</dl>
<h3 id="FirefoxOS_Gecko">FirefoxOS Gecko</h3>
<p>{{draft}}</p>
<p>Currently, FirefoxOS Gecko is a superset of Gecko (Firefox) - there are APIs that FirefoxOS has acccess to that Firefox does not.</p>
<table align="center" class="standard-table">
  <caption>
    General Firefox(Gecko) Terminology</caption>
  <tbody>
    <tr>
      <td>
        <p>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.</p>
      </td>
    </tr>
    <tr>
      <td>
        <p><a href="/en-US/docs/Chrome">Chrome</a> - 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). <span id="docs-internal-guid-51dcca4b-a464-da9e-10e8-10e78465ee47" style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">Has </span><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">system principal</span><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;"> which passes all security checks (can do anything, can operate as any principal).</span></p>
      </td>
    </tr>
    <tr>
      <td>
        <p><a href="/en-US/docs/XPConnect_wrappers#Security_wrappers_exposed_to_chrome">Wrappers</a> - 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.</p>
        <ul>
          <li>XOW -&gt; XPCCrossOriginWrapper - automatically created when an object from one domain is exposed to content from another domain</li>
          <li>SOW -&gt; XPCSystemOnlyWrapper - automatically created when native anonymous content is exposed to JS</li>
          <li>COW -&gt; XPCChromeObjectWrapper - automatically created when a chrome object is exposed to content</li>
          <li>SJOW -&gt; <a href="/en-US/docs/XPConnect_wrappers">XPCSafeJSObjectWrapper</a> -&gt; Ability to safely access non-natively-implemented content defined objects</li>
          <li>XrayWrapper -&gt; <a href="/en-US/docs/XPConnect_wrappers">XPCNativeWrapper</a> - A way to <a href="https://developer.mozilla.org/en/XPConnect_wrappers" title="en/XPConnect_wrappers">wrap up</a> an object so that it's <a href="https://developer.mozilla.org/en/Safely_accessing_content_DOM_from_chrome" title="en/Safely_accessing_content_DOM_from_chrome">safe to access from privileged code</a>.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td>
        <p><a href="/en-US/docs/Security_check_basics#Principals">Principals</a> - A principal represents a security context. There are 3 types of principals:</p>
        <ul>
          <li>System - Passes all security checks. It subsumes itself and all other principals, which means it can operate on any principal, regardless of its security settings.</li>
          <li>null - fails almost all security checks. It has no privileges and can't be accessed by anything but itself and chrome. They aren't same-origin with anything but themselves.</li>
          <li>other/web - a triplet of &lt;origin, appId, inbrowserframe&gt;</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td>Compartments -</td>
    </tr>
  </tbody>
</table>
<h4 id="Secure_Coding_in_C.2FC.2B.2B">Secure Coding in C/C++</h4>
<p>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.</p>
<p><a href="https://www.securecoding.cert.org/confluence/display/seccode/">CERT</a> has a <a href="https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard">C</a> and <a href="https://www.securecoding.cert.org/confluence/display/cplusplus/00.+Introduction">C++</a> guideline that might be useful. There are, obviously, a myriad of other resources to learn about C/C++ security.</p>
<h4 id="Content.2FChrome_Segregation">Content/Chrome Segregation</h4>
<p>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</p>
<p>https://bugzilla.mozilla.org/show_bug.cgi?id=801305</p>
<table class="standard-table">
  <caption>
    Specific Vulnerabilities</caption>
  <tbody>
    <tr>
      <td>
        <p>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").</p>
      </td>
    </tr>
    <tr>
      <td>
        <p>Javascript in Chrome code, unless explicitly needs Chrome privileges, should be run in <a href="/en-US/docs/Components.utils.Sandbox">Sandboxes</a></p>
      </td>
    </tr>
    <tr>
      <td>Take care when using wrappedJSObject on content objects from chrome code (for more information on safely accessing content DOM from chrome, refer to <a href="https://developer.mozilla.org/en-US/docs/Safely_accessing_content_DOM_from_chrome">this document</a>)</td>
    </tr>
    <tr>
      <td>Remember that functions defined in chrome context execute with chrome privileges</td>
    </tr>
    <tr>
      <td>In Chrome code, avoid using dangerous JS functions like eval, setTimeout(string, time), etc. and other related functions if at all possible.</td>
    </tr>
    <tr>
      <td>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.</td>
    </tr>
    <tr>
      <td>
        <p>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:</p>
        <ul>
          <li>Content can pass the object as an argument to any chrome-implemented object it can reference, since functions are callable even without __exposedProps__</li>
          <li>Content can set the object as a property that has been exposed as 'w' with __exposedProps__</li>
          <li>Content can stick them into a chrome array or typedarray, since arrays are accessible even without __exposedProps__</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>
<h4 id="Process_Segregation">Process Segregation</h4>
<p>cpmm and ppmm, child process and parent process communication. not using cpmm, ppmm to talk between paretn and child</p>
<p>ipc messages to talk with each other, and they include request id</p>
<h4 id="Other_Data_Validation_.26_Sanitization">Other Data Validation &amp; Sanitization</h4>
<h4 id="Validate_Permission_Model">Validate Permission Model</h4>
<p>(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) &lt;--- this might be more appropriate in the chrome vs content section.</p>
<p>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</p>
<p>I would imagine permission checking happens automatically at runtime... need to look more into this.</p>
<h4 id="Denial_of_Service">Denial of Service</h4>
<h4 id="Code_Execution">Code Execution</h4>
<p>https://bugzilla.mozilla.org/show_bug.cgi?id=479560#c0</p>
<h4 id="Links">Links</h4>
<p>[1] <a href="/en-US/docs/Safely_accessing_content_DOM_from_chrome">Safely accessing content DOM from chrome</a></p>
<p>[2] <a href="/en-US/docs/Security/Firefox_Security_Basics_For_Developers">Firefox Security Basics for Developers [en-US]</a></p>
<p>[3] <a href="https://developer.mozilla.org/en-US/docs/Security_check_basics">Gecko security check basics</a></p>
<p>[4] <a href="/en/docs/Security_check_basics">Security check basics</a></p>
<p>[5] <a href="https://blog.mozilla.org/gabor/2012/04/18/security-wrappers-part-1/">Security wrappers, part 1: Basics</a></p>
Revert to this revision