Security/Reviews/Gaia/Calendar: Difference between revisions

From MozillaWiki
< Security‎ | Reviews‎ | Gaia
Jump to navigation Jump to search
(Review for 1.2)
(Add link to calendar's README.)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
=== App Review Details ===
== App Review Details ==
 
* App: Calendar
* App: Calendar
* Follow-up Review Date: 22 Oct 2013
* Type: [https://developer.mozilla.org/en-US/Marketplace/Options/Packaged_apps#Certified_app Certified]
* Latest Commit: https://github.com/mozilla-b2g/gaia/commit/69575e3b40931c1cf2060e812db4b20f81040de5
* Review date: 2014-05-11-2014-07-07
* Branch Reviewed: master
* Review bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=1007088]
* Review Lead: Stéphanie Ouillon
* Reviewer: [https://twitter.com/_qll_ Nicolas G] (mentored by Frederik Braun)
* Previous review(s): [[Security/Reviews/Gaia/Calendar-2013-10-17]]


Please see page history for details of previous reviews
== Overview ==
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.


=== Overview ===
=== Architecture ===
The app uses a custom Model View Controller (MVC) framework, templating system and storage layer (on top of IndexedDB). The [https://github.com/mozilla-b2g/gaia/blob/master/apps/calendar/README.md calendar's README] describes all paths and their purposes.


The Firefox OS calendar app allows to synchronize to Google, Yahoo and CalDav calendars. You can create new events, set a reminder, choose when to synchronize the data.
==== Source Code ====
Events can be displayed per Day, Week or Month. You can slide between months.
The source code of the app is hosted at [https://github.com/mozilla-b2g/gaia/tree/master/apps/calendar GitHub], as part of the [https://github.com/mozilla-b2g/gaia gaia repository]. All external libraries are located at js/ext/ (relatively to the root of the app). The following external libraries are used:
* [https://github.com/mozilla-b2g/caldav CalDAV]: Loads and parses CalDAV from remote servers. [https://bugzilla.mozilla.org/show_bug.cgi?id=1023527 Soon to be replaced] by [https://github.com/gaye/dav/ davinci.js].
* [https://github.com/kewisch/ical.js jsical]: Parses iCalendar dat.a
* [https://github.com/lightsofapollo/notamd NotAmd]: An extensible loader system, used to load the calendar's dependencies.
* [https://github.com/visionmedia/page.js page.js] ([https://visionmedia.github.io/page.js/ Documentation]): An Express-(Framework)-inspired client-side router.


===Architecture===
==== Permissions ====
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. [https://bugzilla.mozilla.org/show_bug.cgi?id=1032280]
* 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)


The Calendar App is a model-view-controller project based on the expressjs web application framework (http://expressjs.com/)
== Code Review Notes ==
==== 1. XSS & HTML Injection attacks ====
No injection was found, though there was an [https://bugzilla.mozilla.org/show_bug.cgi?id=1027658 unnecessary XSS sink] and a [https://bugzilla.mozilla.org/show_bug.cgi?id=1009278 code path which almost resulted in a XSS flaw].


provider - A provider object serves as a representation of the server state. Data generated by a provider will map to one or more local "stores". provider/abstract.js contains the API which providers /must/ implement.
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.


store - A store object maps an abstract set of data stores to the different db models. The API contract is defined in store/abstract.js . Providers and other calendar code interact with the DBs through the store API. The store is responsible for transforming calendar operations into a set of DB transactions / manipulations.
==== 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.


db - The DBs used are IndexedDBs. db.js contains functions to open, close, upgrade and manipulate the underlying IndexedDB. This can be seen as the low level shim, whereas the store files operate at a higher level
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.


====Components====
==== 3. Secure data storage ====
All data is stored via the IndexedDB interface. Looks good.


index.html - The main UI for the application
==== 4. Denial of Service ====
elements - The UI for settings, account forms, etc, included in index.html
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.
caldav_worker.js


js/ - The code for the Calendar core features
If a user enters a CalDAV server which accepts the TCP communication but never answers, [https://bugzilla.mozilla.org/show_bug.cgi?id=1014502 the app will hang indefinitely]. However, this is not a valid DoS vector since the user can kill the app and restart it.
js/ext/ - Third party libraries: caldav.js (XML Parser for CalDav protocol, adapted from from the sax-js library), ical.js (iCalendar format), uuid.js (UUID generation)


====Relevant Source Code====
OAuth may be another target of DoS attacks (see [https://bugzilla.mozilla.org/show_bug.cgi?id=1014759 bug 1014759]).


Source code can be found at https://github.com/mozilla-b2g/gaia/tree/master/apps/calendar
Previous Reviews found two DoS vulnerabilities in the CalDAV functionality of the calendar [https://bugzilla.mozilla.org/show_bug.cgi?id=932819] [https://bugzilla.mozilla.org/show_bug.cgi?id=932825].


====Permissions====
==== 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.


* "systemXHR":{},
==== 6. Interfaces with other Apps/Content ====
* "settings":{ "access": "readonly" },
No interface is exposed to other applications.
* "alarms":{},
* "browser":{} - Required to open a window for OAuth authentication
* "storage":{},
* "desktop-notification":{}


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


====Web Activity Handlers ====
==== 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. [https://cure53.de/fp170.pdf 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.


None
== Actions & Recommendations ==
 
The settings permission does not seem to be used:
==== System Messages ====
* https://bugzilla.mozilla.org/show_bug.cgi?id=1032280
 
  "messages": [
    { "alarm": "/index.html" }
  ]
 
The calendar installs a handler for the following:
 
* alarm
 
==== Notifications ====
 
The app indirectly creates notifications through the alarm API.
 
==== Post Messages ====
 
The following code files use postMessage for communicating:
* js/worker/manager.js
* js/worker/thread.js
* js/calendar.js
 
This communication appears to be internal only. calendar.js uses postMessage but only responds to messages from itself.
 
 
====Web Activity Usage ====
 
None
 
==== Notable Event Handlers ====
 
===Code Review Notes===
The calendar doesn't handle any web activities and has limited interaction with other apps. Calendar does extend the alarms API / db for non-phone devices.
 
====1. XSS & HTML Injection attacks====
 
None found. There two main injection vectors for the Calendar app
1. user input when creating events
2. Synced data from external calendars
 
Manual entry of bad data into the Calendar app and syncing of bad data was performed. Template input is sufficiently escaped by the 'h' function in template.js . This function performs a regex check for HTML characters mathcing the regex /[&<>"'`]/ then escapes single and double-quotes. The corresponding template files in templates/ call either 'h', 's', 'bool' or 'l10n' to convert / escape data before display.
 
I've also tried to perform XML injection by exploiting the CalDav XML Parser and/or injecting code in iCal data: strings seem properly escaped, and attempts to perform an XXE failed.
Basically, the parser falls into a "strictFail()" method each time malformed data are parsed.
 
====2. Secure Communications ====
 
===== Remote Services =====
 
The Calendar talks to remote servers. There are currently presets for the SSL versions of Google and Yahoo calendars. However a user may specify their own CalDav or Local calendar instance. There is some risk if the user specifies a HTTP endpoint instead of HTTPS. The app does not perform SSL certificate checks, however gecko will error on a certificate error.
 
ext/caldav.js and service/caldav.js perform XHR requests to synchronize calendars.
The options are set in service/caldav.js and transmitted to the caldav ext library:  
 
var xhrOpts = {
  /** system is required for cross domain XHR  */
  mozSystem: true,
  /** mozAnon is required to avoid system level popups on 401 status */
  mozAnon: true,
  /** enables use of mozilla only streaming api's when available */
  useMozChunkedText: true
}
 
====3. (Secure) data storage ====
 
All data is stored in one of a couple IndexedDBs. The code looks okay.
 
====4. Denial of Service ====
 
Some DoS attacks may be possible during sync. See Actions & Recommendations section.
 
====5. Use of Privileged APIs ====
 
====6. Interfaces with other Apps/Content====
 
No interface is exposed to other applications.


=== Security Risks & Mitigating Controls ===
A flawed Same-Origin check in page.js was found (but marked as duplicate):
* https://bugzilla.mozilla.org/show_bug.cgi?id=1009278


The code from js/ext/caldav.js is adapted from the sax-js parser from https://github.com/isaacs/sax-js/. Some relatively recent commits might be worth applying:
A potential OAuth problem was found:
* https://github.com/isaacs/sax-js/commit/67d0edef57d003757566e8886ca0478e909cd3bf
* https://bugzilla.mozilla.org/show_bug.cgi?id=1014759
* https://github.com/isaacs/sax-js/commit/3b74c16503572d4216d93c867853fed846cffe55
* https://github.com/isaacs/sax-js/commit/6f760b1f8696c2af5e104ada9b171ebc2206b88c).


=== Actions & Recommendations ===
An unnecessary XSS sink was reported:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1027658


Two DoS attack vectors were found:  
Four bugs were found which can be exploited by malcious CalDAV servers:
* {{bug|932819}}
* https://bugzilla.mozilla.org/show_bug.cgi?id=1028346
* {{bug|932825}}
* https://bugzilla.mozilla.org/show_bug.cgi?id=1028554
* https://bugzilla.mozilla.org/show_bug.cgi?id=1014502
* https://bugzilla.mozilla.org/show_bug.cgi?id=1032512

Latest revision as of 16:14, 7 July 2014

App Review Details

Overview

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.

Architecture

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:

Permissions

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:

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Reviews/Gaia/Calendar&oldid=995021"