Qualys

Security CommunityLa communauté des experts sécuritéen savoir plus

SecurityVibesQualys Community

Left content

HTML 5 et la sécurité

auteur de l'article Jerome Saiz , dans la rubrique Produits & Technologies

[Mis à jour le 9 septembre 2010] Les boulons ne sont pas serrés, la peinture n’est pas sèche mais HTML5 se retrouvera très certainement chez vous un jour ou l’autre. Par exemple à la faveur de votre service marketing, ou certainement plutôt de l’agence de création web qui travaille pour ce dernier (pensez aux mini-sites des campagnes éphémères, ceux qui poussent comme des champignons sans grand contrôle de votre part…). Les nouvelles balises sémantiques du langage, son ouverture aux contenus tiers et ses nouvelles fonctionnalités (notamment multimédia et interactives) en font un choix quasi-certain à moyen terme.

Alors autant s’y préparer et avoir dès aujourd’hui une vague idée de ce que cela change en terme de sécurité et de ce que vous pourrez imposer aux cahiers des charges le moment venu. Car s’il augmente la surface d’attaque (de nombreuses fonctionnalités prises en charge par des plugins dans HTML4 y sont désormais intégrées), HTML5 propose aussi quelques fonctions de sécurité qu’il serait dommage de ne pas réclamer.

Ce qui change

Vidéo, audio et même animations « à la » Flash (avec la balise <canvas>) : HTML5 élargit considérablement la surface d’attaque, ce qui augmente mécaniquement le risque d’y trouver des vulnérabilités. En un sens cependant le risque ne fait que se déplacer, allant des plugins tiers chargés d’assurer ces fonctionnalités vers le navigateur lui-même. Il faudra donc s’assurer que l’on sait aussi traiter ces risques dans ce nouvel environnement.

Plus important, HTML5 facilite l’échange de contenu à travers les domaines (bravant ainsi la fameuse restriction dite « cross-domain« ). Plus besoin, par exemple, de tour de passe-passe tordu (avec JSONP par exemple) pour faire des appels extra-domaine via Javascript avec XMLHttpRequest, HTML5 le permet nativement. Le langage introduit un système de messaging entre objets au sein du même site ou d’origines différentes (Cross-document messaging). C’est idéal pour enrichir les contenus d’une page en cette ère de widgets et de pages d’accueil personnalisées, mais il y a aussi de quoi faire tiquer les puristes en matière de sécurité. Mais là aussi le risque ne fait que se déplacer et il faudra surtout s’assurer de savoir le prendre en compte dans sa nouvelle incarnation. Après tout les développeurs web utilisent déjà des astuces pour obtenir des effets similaires et HTML5 ne fait en définitive que formaliser la pratique en proposant un cadre plus normatif.

Enfin, le stockage local est une fonctionnalité de « base de données » locale (et allégée) qui autorise le site à entreposer des données de session dans le navigateur. Elle ne représente a priori pas un risque nouveau : outre les cookies traditionnels de nombreuses technologies tiers permettait déjà un stockage étendu au sein du navigateur (Google Gears bien sûr, mais aussi Java, Flash, Silverlight). Alors certes l’implémentation actuelle n’est pas exempte de vulnérabilités, et le concept ouvrira peut-être la voie à de nouvelles attaques (GMail, par exemple, stocke déjà une copie des courriers de l’utilisateur dans container local). Mais il ne s’agit finalement pas là d’un problème inédit et la manière de l’adresser ne l’est pas elle non plus (n’accorder aucune confiance aux données stockées localement, par exemple !).

Les nouveautés

Plusieurs fonctionnalités inédites de HTML5 sont directement destinées à renforcer la sécurité et le contrôle des données personnelles de l’utilisateur, et il serait dommage de s’en priver.

C’est par exemple le cas de la balise <keygen>, qui permet – excusez du peu – de faire générer au navigateur une paire de clés cryptographiques (RSA, par exemple) au sein d’un formulaire de saisie. Lorsque le formulaire est soumis au serveur la clé privée demeure dans le navigateur (dans le stockage local) tandis que la clé publique est transmise avec les données. Alors certes la technique est loin d’être nouvelle (elle provient du navigateur Netscape !) et surtout loin de faire l’unanimité (des clés générées par logiciel et stockées localement ? Une hérésie pour les puristes !). Mais à condition d’en comprendre et d’en accepter les limitations ce sera probablement un outil utile à plus d’un titre… à condition d’être implémenté par les navigateurs ! Car aucun d’entre eux ne supporte encore cette balise et Microsoft refuse tout bonnement d’inclure  <keygen> dans Internet Explorer (voir encadré en fin de billet).

Si faire générer une paire de clés cryptographiques par une page HTML vous a surpris, attendez d’apprendre que HTML5 met également en oeuvre un bac à sable (sandbox) afin d’isoler au sein de la même page les contenus tiers. Grâce à l’attribut sandbox et au type de contenu associé (text/html-sandboxed) le contenu rendu dans un cadre sera incapable d’être interprété hors de ce dernier. Il ne pourra non plus accéder à la structure DOM de la page parent, exécuter des scripts, embarquer ses propres formulaires (ou manipuler ceux existants) ou encore utiliser le stockage local (cookies ou stockage propre à HTML5). Des options telles allow-same-origin, allow-top-navigation, allow-forms ou allow-scripts viennent toutefois assouplir sélectivement ces restrictions.

Dernière nouveauté, certes mineure mais qui pourra avoir son utilité : HTML5 introduit l’attribut rel= »noreferrer » aux hyperliens traditionnels. Anodin ? En effet, mais cela pourra, par exemple, être utile afin de ne pas laisser « fuir » des informations d’architecture web ou des variables de session entre l’intranet et des sites publics. Et surtout ça illustre combien HTML5 tente de répondre de manière normée aux usages et problèmes concrets.

Bien entendu aucune de ces nouveautés ne changera la face de la sécurité sur le web : gageons même que les criminels trouveront à l’occasion des détournements forts créatifs de ces nouvelles fonctionnalités. Mais les choses vont malgré tout dans le bon sens : que ce soit la réduction des plugins tiers au profit d’un code maîtrisé par la même équipe de développement (celle du navigateur) ou la prise en compte des problèmes de sécurité bien actuels (cross-site scripting, iFrame malveillant, absence d’authentification intégré aux formulaires…), HTML5 apporte des réponses et il serait dommage de s’en priver lors de vos prochains développements.

Pourquoi Microsoft refuse-t-il de supporter <keygen> ?

Selon Microsoft la balise <keygen> serait une fausse bonne idée. Dans un échange au sein d’une liste de discussion du W3C, Adrian Bateman de Microsoft fait trois reproches essentiels au sujet de la balise <keygen> (merci à Bernard Ourghanlian, de Microsoft France, pour cette référence).

  • L’utilisateur choisi lui-même la longueur des clés qu’il souhaite, ce que la majorité des internautes est incapable de faire de manière cohérente (le serveur est incapable de dicter une taille de clé minimale)
  • La génération des clés et l’exploitation du certificat reçu n’est pas fluide et exige de l’utilisateur une manipulation en plusieurs étapes
  • Il n’y a aucun mécanisme de renouvellement des clés l’utilisateur, doit donc les re-générer lui-même à leur expiration

De fait, la position de Microsoft est que cette fonctionnalité devrait être retirée des spécifications de HTML5 ou être rendue obsolète.


Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Notez L'article

Participez ou lancez la discussion!

3 réponses à HTML 5 et la sécurité

Catégories

Étiquettes

Archives

Ce site est une archive des messages à SecurityVibes de Septembre 2000 à Juillet 2014. S'il vous plaît visitez le Qualys Community pour les dernières nouvelles.