Security Considerations & Recommendations for a hosted Gaia

Introduction

This document will serve as a recommendation to keep the Gaia as secure as it is right now. The Requirements section will give a brief summary, whereas the following sections will explain the security features of the existing codebase and suggest how to apply them to a hosted model.

Requirements

• Sign updates (and validate in the platform, not in the ServiceWorkers)
• Prevent loading unsigned content on the gaia app origin or treat app as a separate content from the http(s) gaia location
• Maintain the strong CSP policy and reduce exceptions over time
• Maintain all the application logic in the client side (i.e. back-end less)
• Create an auditable approach to DOM XSS prevention (e.g. discouraging certain code patterns)
• Use CSRF prevention mechanisms like X-Frame-Options and CSP frame-ancestors
• Discourage code patterns that simply act on URL fragments (so-called CS#RF)
• Apply modern HTTPS web hosting practices, with forward secrecy and HTTPS Public Key Pinning (HPKP).

Analysis & Rationale

The current architecture is secured against several attacks. This includes (active) network attackers and malicious applications and the typical web exploitation scenarios. These usually involve the user clicking on an evil link. We currently also implement a certain level of defense in depth features to prevent exploitation of very common security holes, like Cross-Site Scripting (XSS). Note that Gaia currently consists of static files only, which leaves a few server side vulnerabilities out of scope. If we intend to regularly serve different files per user or maintain server-side state, we should revisit our security considerations accordingly.

Gaia server compromise results in malicious code on client (Code Integrity)

• Existing control: doesn’t apply (apps are signed, updates are signed)
• Impact: Run malicious code on all FxOS devices
• Security requirement: compromise of hosting web server doesn’t result in malicious code running on users device
• Proposal: sign updates, add a platform mechanism to validate the updates (can’t rely on service workers to verify the code themselves). and use a modern HTTPS setup (see also below).

App content needs to be isolated from other content on the domain

• Existing control: app: protocol creates unique separate security origins for apps
• Impact: Content hosted on the same origin as Gaia apps would be given privileges.
• Security Requirement: signed code on separate origin to unsigned code
• Proposal: either:
  • app content is treated loaded in a separate origin. Perhaps by using a custom protocol handler such as app:https://app.foo.com
  • gecko prevents loading unsigned content on the gaia app origin

Script/HTML/other injection

• Existing control: static HTML content, CSP, manual audit
• Impact: Cross-site scripting in a privileged application is more severe (runs with same privileges as application)
• Requirement: mitigate the likelihood of script injection
• Proposal: apply same as existing controls (no server-side dynamic content)
  • strict Content Security Policy
  • consistent auditable approach to DOM-XSS prevention (kgrandon/fbraun already working on this. )

CSRF

• Existing control: restrictions on app:// prevent linking which largely prevents CSRF, data-jars prevents ambient credentials being abused
• Impact: impact of CSRF more severe that web, since privileged application (e.g. CSRF deletes one of your photos)
• Requirement: mitigate CSRF through standard app security methods
• Proposal: prevent through consistent use of architecture which is immune to CSRF

Click-jacking

• Existing control: protocol restrictions prevent framing of privileged app content
• Impact: click-jacking a privileged application might disclose or modify sensitive data or access sensitive functionality
• Requirement: prevent framing of privileged app
• Proposal: set x-frame-options: DENY; header (either on the server, or synthetically somehow for privileged apps)

Confidentiality, Traffic Analysis

• Existing control: application stored on disk N/A
• Impact: Device usage may be exposed to an attacker
• Requirement: ensure confidentiality and privacy that the former packaged app model had
• Proposal: Use HTTPS with a modern setup, including Forward Secrecy and HTTPS Public Key Pinning (HPKP)