From MozillaWiki
< Security‎ | Reviews‎ | Gaia
Jump to: navigation, search

App Review Details


The Gaia calendar app is the default calendar application pre-installed on every Firefox OS device. It allows synchronization with Google, Yahoo and remote CalDav calendars. Additionally, it has all the features one would expect from a calendar application: It is possible to create, delete and update new events and reminders (alerts). This data can be synchronized to one or many remote calendars and displayed per day, week or month.


The app uses a custom Model View Controller (MVC) framework, templating system and storage layer (on top of IndexedDB). The calendar's README describes all paths and their purposes.

Source Code

The source code of the app is hosted at GitHub, as part of the gaia repository. All external libraries are located at js/ext/ (relatively to the root of the app). The following external libraries are used:


Requested permissions and their uses:

  • systemXHR: Used to fetch CalDAV resources from (arbitrary) remote servers (js/ext/caldav.js)
  • settings (readonly): Not used? No access to navigator.mozSettings. [2]
  • alarms: Used to start the application in intervals to synchronize all calendars and to show reminders (js/controllers/alarm.js)
  • browser: Used for an OAuth authentication flow (js/oauth_window.js)
  • storage: The calendar app is using an IndexedDB to store appointments, alarms and similar (js/db.js)
  • desktop-notification: (Most likely) used to notify the user about upcoming events and failed synchronization attempts (js/notification.js, js/controllers/alarm.js, js/controllers/error.js)
  • audio-channel-notification: To tell the audio channel manager to adjust the notification channel if a user presses volumeup/-down in the calendar (js/app.js)

Code Review Notes

1. XSS & HTML Injection attacks

No injection was found, though there was an unnecessary XSS sink and a code path which almost resulted in a XSS flaw.

Templates use the "h"-function (found in js/template.js) for output encoding. First, it checks if a HTML special character is part of the string with the regular expression /[&<>"'`]/. If this is not the case, the string is immediately returned without any further sanitization. In any other case, the string is assigned to the textContent property of a dummy span element to encode characters like < and >. Finally, the single and double quotes are replaced by their HTML entities. While this looks dangerous because of the check for bad characters, this worked in all tested cases and seems to be robust. Note, however, that there is the danger of mutated XSS (mXSS) attacks due to the extensive use of innerHTML and insertAdjacentHTML in the template engine.

2. Secure Communications

The calendar allows users to synchronize events with Google, Yahoo and custom CalDAV endpoints. There are HTTPS presets for Google and Yahoo servers but a user may still enter HTTP URIs for custom CalDAV endpoints. All communication with remote servers is conducted via the XMLHttpRequest API with mozSystem (cross-domain) and mozAnon enabled.

Additionally, a malicious user with access to the phone is not able to change the URL of an already existing CalDAV account in order to steal the credentials. The password field is left empty in the edit view of an already existing account.

3. Secure data storage

All data is stored via the IndexedDB interface. Looks good.

4. Denial of Service

An obvious attack vector is storage exhaustion. A malicious CalDAV endpoint can synchronize a lot of events to fill up the space available for the app. However, this could not be confirmed, as Gecko (development profile on Nightly) could handle our DoS attempts very well.

If a user enters a CalDAV server which accepts the TCP communication but never answers, the app will hang indefinitely. However, this is not a valid DoS vector since the user can kill the app and restart it.

OAuth may be another target of DoS attacks (see bug 1014759).

Previous Reviews found two DoS vulnerabilities in the CalDAV functionality of the calendar [3] [4].

5. Use of Privileged APIs

For the use cases of the APIs in the calendar app see above (Architecture/Permissions). All APIs seem to be used in a secure way.

6. Interfaces with other Apps/Content

No interface is exposed to other applications.

Security Risks & Mitigating Controls

HTTP Parameter Pollution

The Calendar.QueryString namespace (js/querystring.js) contains an URL query string parser which is able to consider multiple keys of the same name. Example: ?foo=1&foo=2&bar=3 would be parsed in to a data structure like {'foo': [1, 2], 'bar': 3}. This is neither a vulnerability nor wrong behaviour on its own, but must be considered when writing code which handles user-controlled query strings. An attacker may use this to confuse or break code which does not expect to deal with Arrays instead of strings.

Mutated XSS

As mentioned above, the templating engine relies on string parsing. This requires the use of properties like innerHTML and insertAdjacentHTML to place the templates into the DOM. Mutated XSS attacks take advantage of browser bugs which occur while converting strings to DOM nodes and pose a security risk to the templating engine. In future, it might be worthwhile to change the templating system to avoid this risk.

Actions & Recommendations

The settings permission does not seem to be used:

A flawed Same-Origin check in page.js was found (but marked as duplicate):

A potential OAuth problem was found:

An unnecessary XSS sink was reported:

Four bugs were found which can be exploited by malcious CalDAV servers: