La sécurité des applications

Les contrôles de sécurité d'applications web introduites dans Firefox OS sont les suivants :

• Les applications web sont explicitement installées et lancées plutôt que simplement chargées depuis un navigateur. Les applications doivent être installées avant toute utilisation et les contrôles de sécurité régissent la mise à jour et la suppression des applications afin de protéger l'utilisateur.
• L'accès aux nouvelles API web est contrôlé par un système de permissions, où une application doit déclarer les autorisations qu'elle veut utiliser avant l'installation. Afin d'avoir accès à certaines API, les applications doivent respecter certaines exigences et être examinées, approuvées et signées par le Marketplace.
• Les applications web sont mises dans une sandbox afin qu'elles ne voient que leurs propres ressources (cookies, base de données IndexedDB, etc.). Même si deux applications chargent la même URL, ces deux pages ne seront pas considérées comme provenant de la même origine car elles sont en cours d'exécution sur des applications différentes.

Types d'applications

Firefox OS supporte trois types d'applications : web, privilégiée et certifiée. Le type d'application est déclaré dans le manifeste d'application et indique la liste des permissions que chaque application peut demander.

• Application web : La plupart des applications tierces sont des applications "web". C'est le type par défaut qui ne nécessite pas d'autorisations supplémentaires en plus de celles déjà en place sur le web. Les applications web peuvent être installées à partir de n'importe quel site web, sans autre vérification. Elles peuvent aussi être empaquetées, mais cela n'induira pas d'autres autorisations.
• Application privilégiée : Les applications sont autorisées à demander des autorisations accrues. Ces applications privilégiées doivent être vérifiées et signées par le Marketplace.
• Application certifiée : Les applications certifiées sont obligatoirement préinstallées sur le périphérique par le constructeur/opérateur qui diffuse le téléphone.

Mettre une application à disposition

Sous Firefox OS, les applications peuvent être mises à disposition de deux façons différentes : hébergées ou empaquetées. Les applications web classiques peuvent être mises à disposition via deux mécanismes, les applications privilégiées et certifiées en revanche doivent être empaquetées.

Les applications hébergées

Une application hébergée est constituée uniquement d'un fichier manifeste sur le serveur web du développeur, qui contient un launch_path pour indiquer quelles pages doivent figurer lorsque l'application est lancée. D'un point de vue de la sécurité, les applications hébergées fonctionnent presque comme des sites web normaux. Lorsqu'une application hébergée est chargée, se sont les URL « normales » de ces pages, qui sont chargées. Elles sont chargées depuis le serveur web, ou depuis l'appareil si elles étaient stockées dans un fichier cache.

Les applications empaquetées

Une application empaquetée est un application web ayant l'ensemble de ses ressources (HTML, CSS, JavaScript, manifeste et ainsi de suite) contenues dans un fichier zip (les ressources ne sont pas présentes sur un serveur web). Pour plus de détails sur ce format, voir la page sur les applications empaquetées.

Origine de l'application

Pour les applications hébergées, l'origine de l'application correspond à l'origine du manifeste de l'application.

Pour les applications empacketées, l'origine est affectée de façon unique à l'application lors de l'installation. Les applications privilégiées et certifiées peuvent également demander une origine spécifique en spécifiant le paramètre origin dans le fichier manifeste de l'application.

Installation de l'application

Les applications sont installées grâce à l'API JavaScript Apps  :

• Les applications hébergées sont installées en appelant navigator.mozApps.install (manifestURL), où manifestURL est une URL qui définit l'emplacement de l'application. Pour plus de détails, voir la page sur l'installation d'applications.
• Les applications empaquetées : elles sont installées en appelant navigator.mozApps.installPackage(PackageURL). Pour les applications empaquetées, le manifeste de l'application principale est stocké dans le paquet lui-même, de sorte qu'il est signé. Il y a un deuxième « mini-manifeste », utilisé pour démarrer le processus d'installation. Voir l'installation d'applications empaquetées et les applications empaquetées pour plus d'informations.

Afin de garantir qu'une application est bien installée comme une application web, il faut s'assurer que le site web ne trompe pas le mécanisme avec un manifeste d'application. Pour cela, on vérifie que le type MIME du manifeste servi est application/x-web-app-manifest+json. Cette restriction est levée lorsque le manifeste de l'application a la même origine que la page demandant l'installation de l'application.

Mise à jour

Le processus de mise à jour pour les applications est décrit à la page mise à jour des applications.

Autorisations

Les applications peuvent avoir des privilèges supplémentaires par rapport à ceux accordés aux sites web normaux. Par défaut, une application possède les mêmes autorisations qu'une page web normale. Afin d'obtenir des autorisations supplémentaires, il faut tout d'abord lister les autorisations nécessaires dans le manifeste :

Déclaration de manifeste

Pour chaque autorisation supplémentaire, le manifeste doit lister cette autorisation ainsi qu'une description lisible de la raison pour laquelle l'application souhaite accéder à cette autorisation. Par exemple, si une application souhaite utiliser l'API de navigator.geolocation, le manifeste devra contenir le fragment suivant :

"permissions": {
  "geolocation":{ 
    "description": "Required for autocompletion in the share screen",  
  }
},

Cela permettra à l'application de demander la permission pour utiliser la géolocalisation (de la même manière qu'une page web). Pour plus de détails sur le fichier de manifeste, voir manifeste d'application.

Accorder les permissions

Lorsque les autorisations sont demandées dans le manifeste, il y a deux modes pour activer les permissions : la demande ou l'activation par défaut. L'activation par défaut est mise en place grâce au manifeste, sans autre interaction. Les permissions demandées sont affichées lors de la première utilisation et l'utilisateur peut choisir d'autoriser ou non l'API. En général, Firefox OS ne demande les autorisations que si celles-ci ont un impact sur la vie privée et qu'il est pertinent que l'utilisateur sache pourquoi l'API est utilisée. Par exemple, l'application demandera une permission pour accéder aux contacts, mais l'établissement d'une connexion TCP brute est implicitement autorisé car ici, il n'est pas nécessaire que l'utilisateur fournisse son accord. Lorsque les applications sont revues pour être intégrées au Marketplace, l'utilisation des permissions est examinée afin d'assurer la protection des utilisateurs.

Révoquer les permissions

À tout moment, les utilisateurs peuvent changer d'avis sur les permissions qui auront été demandées. Pour révoquer une permission, il faut aller dans l'application Paramètres. En revanche, les permissions activées par défaut ne sont pas paramétrables.

Application web Sandbox

Stockage des données par application

Chaque application s'exécute dans une sandbox de façon indépendante, ce qui signifie que toutes les données stockées par une application sont séparées des données stockées par les autres applications. Parmi ces données, on retrouve les cookies, les données locales et les autorisations liées au site.

Ainsi, si l'utilisateur se connecte sur Facebook avec l'Appli A, cela n'aura aucun impact sur l'utilisation de Facebook par l'Appli B. Le cookie de connexion entre Facebook et l'Appli A n'est disponible que pour l'Appli A. Si l'Appli B ouvre un <iframe> pour Facebook, le cookie ne sera pas disponible. C'est pourquoi, quand l'Appli B ouvre Facebook, elle affichera la page de connexion plutôt que le compte de l'utilisateur.

Une application ne peut en ouvrir une autre

Cela signifie que les applications ne peuvent pas ouvrir d'autres applications en utilisant les iframes. Si l'application A crée une <iframe> dont le src correspond à l'URL de l'application B, cela n'ouvrira pas l'application B dans l'<iframe>. Cela ouvrira uniquement le site web situé à cet emplacement. Elle n'utilisera aucun des cookies de l'application B et le comportement observé sera le même que si l'application n'était pas installée sur l'appareil de l'utilisateur.

Cela s'applique également aux applications empaquetées (voir ci-après pour plus d'informations). Si l'application A tente d'ouvrir l'application empaquetée B en utilisant un <iframe> dirigeant vers l'URL app:// de l'application B, celle-ci ne sera pas chargée. Cela provoquera une erreur 404 ou une autre erreur. Que l'application B soit installée ou non, cela échouera car l'application A ne peut pas détecter si l'application B est installée.

Les raisons de ce fonctionnement

Cette approche possède des avantages et des inconvénients. Un des premiers inconvénients est le suivant : si l'utilisateur interagit avec le même site web à travers plusieurs applications, il devra se connecter à toutes les applications. De même, si un site web veut stocker des données localement et que l'utilisateur interagit avec ce site web parmi les différentes applications, les données vont ainsi se dupliquer pour chaque application. Cela peut poser problème lorsque le volume de données devient conséquent.

Cela permet aussi de bénéficier de certains avantages en ce qui concerne la vie privée. L'utilisateur peut ainsi installer l'application MonPartiPolitique en toute sécurité sans se soucier du fait que MonAppliProfessionnelle puisse détecter les nouvelles données.

Isolement des permissions

Sandbox pour l'API Browser

Pour sécuriser les applications qui ouvrent un grand nombre d'URL, comme les navigateurs, nous avons ajouté un indicateur (flag) browserContent. L'indicateur browserContent permet à chaque application d'avoir non pas un, mais deux bacs à sable (sandboxes) : un pour l'application elle-même et l'autre pour tout le contenu web ouvert par l'application.

Par exemple, si l'application monNavigateur est chargée depuis https://monnavigateur.com, les scripts et ressources seront chargées dans ce bac à sable, ils appartiennent à ce domaine.

Ensuite, si une page de l'application crée un <iframe mozbrowser>, une sandbox différente sera créée et utilisée pour cette <iframe>. Cette sandbox sera différente de la première. Ainsi, si cet <iframe> dirige vers https://monnavigateur.com, cela se traduira par l'utilisation d'autres cookies pour cet <iframe mozbrowser>. De même, le contenu à l'intérieur de la <iframe mozbrowser> verra des données locales différentes de celles correspondant à l'application.

Ceci s'appliquera également si l'application monNavigateur souhaite intégrer des fonctionnalités de Google Maps pour proposer des outils de navigation basés sur la géolocalisation. Ainsi, si l'application ouvre un <iframe> vers https://maps.google.com, il recevra un ensemble de cookies pour https://maps.google.com. Si l'utilisateur navigue alors à l'intérieur du <iframe mozbrowser> contenant https://maps.google.com, cela utilisera différents cookies et d'autres autorisations au niveau le plus haut de l'application.

Voici un autre scénario où cela peut être utile : l'application Yelp. Cette application permet d'ouvrir différents sites Internet de restaurants. En utilisant <iframe mozbrowser>, afin d'ouvrir le site du restaurant, l'application Yelp s'assure que le site web du restaurant ne contiendra pas d'<iframe> pointant vers l'application Yelp. En effet, si le site du restaurant pointe d'une certaine façon vers https://yelp.com, il « verra » le site web Yelp plutôt que l'application. Ainsi, il est théoriquement impossible que le site du restaurant attaque les données de l'application Yelp.

Résumé sur la sécurité des applications