HTML5, offline et sécurité

Un article récent publié sur InfoQ abordait la sécurité de HTML5 dans sa globalité, et notamment sur des attaques concernant les nouvelles fonctionnalités de navigation hors-ligne de HTML5.

Quelles sont donc ces fonctionnalités et qu'en est-il vraiment des risques associés ?

Rappel historique

La seule possibilité pour une application web HTML/JavaScript de stocker des données dans un navigateur était jusqu'à récemment de les stocker dans un cookie. Limités en taille (la spécification exige seulement des navigateurs qu'ils puissent gérer 4096 octets par cookie !), parfois refusés par les navigateurs et nettoyés régulièrement, et assimilés à des logiciels espions par les antivirus, leur fiabilité restait très limitée.

D'autres technologies à base de plugins, comme Adobe Flash, utilisaient des procédés propriétaires ne répondant pas aux normes du W3C (les super cookies) et très critiquées pour leur opacité (manque de contrôle pour l'utilisateur pour savoir quelles informations sont stockées ou les supprimer). En 2007, Google a sorti Google Gears qui a permis de stocker des données dans le navigateur sous la forme d'une base de  données relationnelle et de disposer en local d'un cache de ressources (cf. les articles publiés par Olivier Mallassi sur le blog OCTO).

Cette nouveauté a permis le développement de véritables applications web stockant un nombre conséquent de données en local, permettant un fonctionnement déconnecté de l'application et une meilleure réactivité en évitant d'inutiles aller-retours avec le serveur. L'exemple le plus marquant étant naturellement le client mail de Google, Gmail, qui innovait en plus avec le "flaky mode" où l'utilisateur naviguait en permance en local, utilisant les ressources stockées dans son navigateur, et où l'application mettait à jour ces données quand une connexion à Internet était disponible. Cependant, Google Gears restait un produit de Google, et son implémentation sur les navigateurs n'était pas garantie.

Le groupe de travail sur HTML5, auquel contribue fortement Google, a alors déclaré vouloir inclure dans la spécification HTML5 des normes de stockage local s'inspirant de Google Gears. En parallèle, début 2009, Google a d'ailleurs arrêté le développement de Google Gears, au profit de l'implémentation de la norme HTML5.

Cette normalisation contraint déjà les navigateurs web à implémenter ces mécanismes, entraînant à coup sûr une démocratisation de leur utilisation par les applications web.

Quels sont les risques liés au stockage local ?

Parmi les sites précurseurs dans l'utilisation de stockage local se trouvent les webmails. Les données stockées dans  le navigateur sont donc les courriers électroniques de l'utilisateur, qui sont des données très critiques par-rapport au respect de la vie privée, sans parler des cas où certains mails contiendraient des données plus sensibles, comme un numéro de compte bancaire…

Il convient donc impérativement de s'assurer qu'aucun tiers ne puisse accéder à ces données.

Quels sont les mécanismes de stockage local ?

HTML5 prévoit deux systèmes de stockage de données en local :

• le Web Storage, comprenant local storage, toujours accessible à l'application et permettant par exemple à des onglets différents de partager des données, et le session storage, accessible uniquement à une fenêtre donnée. Les données sont stockées sous la forme de clés/valeurs,
• la Web SQL Database fournissant cette fois une base de données relationnelle, implémentée par les navigateurs avec SQLite. Signalons au passage que le choix de SQLite a été fait par les éditeurs de navigateurs au détriment de la proposition initiale de "Indexed DB" proposée par le W3C.

Un autre système de stockage local est fourni sous la forme de caches permettant cette fois-ci de stocker des ressources (images, fichiers JavaScript, etc.) et non plus des données.

Dans leurs spécifications respectives, le W3C aborde la sécurité, et décrit les mêmes problématiques pour les deux.

Quels risques et quelles protections ?

La seule protection spécifiée par le W3C concerne l'origine des sites : des données stockées par un site A ne doivent pas être visibles pour un site B, en se basant sur l'hôte du site et le port. Cela empêche par exemple une iframe inclus dans un site, typiquement un encart publicitaire, d'avoir accès aux données stockées localement par ce site.

Ce systèmes ne protège pas de certaines attaques, d'ailleurs décrites dans la spécification :

- les attaques par usurpation de DNS, qui consistent à usurper une adresse IP d'un serveur pour envoyer des paquets à sa place. Ce risque sera toutefois mitigé en utilisant SSL, et concerne le web dans sa globalité.

- le partage de nom d'hôte entre plusieurs sites : si le site d'adresse http://www.mon-site.com/site1 stocke des données, un autre site d'adresse http://www.mon-site.com/site2 y aura accès sans resctriction. Le risque étant faible de se faire attaquer par ce biais, car on a déjà fait confiance au premier site.

On remarquera que les attaques par XSS (cross site scripting) ne sont pas mentionnées et constituent pourtant un risque important, bien mis en valeur par l'OWASP. On pourra le mitiger avec notamment un contrôle du code côté serveur et une validation des données passées dans les formulaires.

La spécification ne prévoit pas d'autre mécanisme de sécurité.

Un point très important n'est pas abordé dans la spécification et pourrait pourtant s'avérer crucial : la spécification ne prévoit pas que les données stockées en base locale soient chiffrées, elles sont toujours stockées en clair.

Ce point a été soulevé par Nicholas C. Zakas (un des référents mondiaux sur le langage JavaScript notamment, qui contribue à HTML5). Il a même proposé une proposition très détaillée d'évolution de la spécification vers un chiffrement des données, décrite dans ce billet. Dans ce système, un serveur d'application web aurait la responsabilité de chiffrer les données sur le client, avec une clé de chiffrement gérée par l'application. Concrètement, une application web devrait exécuter la méthode Javascript suivante pour ouvrir la connexion en base de données : window.openSecureStorage("mystorage", window.AES_128, key, function(storage){ //use storage object });

L'application web choisirait donc l'algorithme de chiffrement et la clef. Ainsi, même si un attaquant parvenait à récupérer des données, il ne pourrait les exploiter. On remarquera d'ailleurs que sans chiffrement, toute personne ayant accès physiquement au poste client pourra lire toutes ces données…

Bien que sa proposition soit assez complète et détaillée, il n'y a pas encore eu de suite à ma connaissance de la part d'autres acteurs du web.

On peut tout de même se rassurer concernant les postes publiques (cyber cafés, etc.). En effet, les données sont stockées dans le navigateur dans un profil créé pour l'utilisateur, qui est normalement effacé lorsqu'il quitte le poste et que le compte est ré-initialisé, ce qui doit être l'usage pour ce type de poste. L'utilisateur devant tout de même s'en assurer, ce qui est loin d'être évident pour un utilisateur non initié. Il est ici plus question d'éducation des utilisateurs que de technologie.

Enfin, les caches peuvent quant à eux être attaqués par "Cache poisoning". L'objectif de l'attaquant est alors d'injecter dans le cache du navigateur un fichier JavaScript en remplacement d'un fichier fourni par le serveur "sain", et dont le script malicieux serait exécuté par le client. Ce risque est à prendre en compte particulièrement dans les réseaux wifi ouverts comme on en trouve par exemple dans des restaurants, mais si ces attaques sont difficiles à détecter et à contrer, le risque s'avère relativement faible d'après les conditions requises pour permettre l'attaque, citées par l'OWASP.

Conclusion

Malgré cette énumération de risques, qui plus est incomplète, il convient d'insister sur le fait qu'ils ne sont pas spécifiques à HTML5 mais au contraire inhérents au web depuis ses débuts. La nouveauté avec HTML5 est qu'il offre la possibilité de faire des application plus riches, stockant plus de données localement.

Cela doit simplement inciter les concepteurs et développeurs d'applications web à une certaine vigilance concernant la sécurité des données locales, mais ne vous y méprenez pas, HTML5 constitue bien dès aujourd'hui une formidable opportunité pour vos applications web !