A l’occasion de la conférence Hack in Paris 2012 le chercheur Krzysztof Kotowicz a présenté trois attaques HTML5 à surveiller de près. Sans revenir sur les pièges potentiels déjà largement évoqués, Kotowicz présente trois nouvelles attaques particulièrement simples, à la limite de l’ingénierie sociale et à l’étonnante efficacité. Elles ne sont fort heureusement pour l’instant encore exploitables que contre certains navigateurs, voire certains services en ligne seulement.

Le Filejacking

Le scénario de l’attaque est simple : une page web vous propose de récupérer un contenu quelconque. Pour ce faire vous devez cliquer sur un bouton afin de sélectionner l’emplacement où sera téléchargé le package que vous recevrez. Rien ne vous choque ? Oui, les téléchargements sont habituellement dirigés vers l’emplacement par défaut défini dans les options du navigateur. Ici, en cliquant sur ce bouton et en choisissant un répertoire quelconque sur votre disque dur vous autorisez en réalité la page web à explorer son contenu et à récupérer ce qui l’intéresse sur le serveur de l’attaquant.

L’attaque exploite la balise file directory de l’API fichiers de HTML 5. Pour l’instant celle-ci est encore obscure et n’est supportée que par Google Chrome (notamment pour travailler avec le service Google Docs).

AppCache poisonning

Cette attaque exploite un nouveau cache proposé par HTML 5. Le Cache Manifest offre aux applications HTML 5 un moyen de fonctionner hors-ligne en copiant localement les fichiers de support qui lui sont indispensables (librairies Javascript par exemple). Cette fonctionnalité permet au développeur d’une application web d’indiquer au navigateur quelle URL (ou ressource) doit être permanente. Celle-ci ne sera alors mise à jour ultérieurement que sur décision du développeur. Il s’agit d’un cache distinct du cache navigateur traditionnel.

Mais selon Krzysztof Kotowicz, cette fonctionnalité permettrait aussi d’injecter une version piégée d’une librairie (lors d’une attaque de type man-in-the-middle par exemple) qui sera ensuite stockée indéfiniment par le navigateur. En indiquant qu’il s’agit en réalité du fichier robots.txt (qui ne change que très rarement) le navigateur (Chrome ou Firefox seulement) continuera à utiliser la version piégée de la librairie.

Silent file upload

Une attaque sournoise par excellence, celle-ci vise à ternir l’image de la victime. Grâce à un objet Javascript XMLHttpRequest l’attaquant est en mesure de simuler le comportement exact de l’utilisateur lorsque celui-ci upload une image sur un site de partage d’images tel Flickr. Cela de manière totalement invisible, et en fournissant bien entendu l’image de son choix.

Le scénario d’une telle attaque serait de faire publier par l’utilisateur (et malgré lui) une image à caractère embarrassant sur son compte Flickr. Cela à la simple visite d’une page web piégée. Heureusement cette attaque exige un pré-requis de taille : le site cible ne doit pas utiliser dans ses formulaires de mise en ligne des jetons anti-CSRF. C’est toutefois le cas, par exemple, de Flickr, dont Krzysztof Kotowicz se sert pour sa démonstration.

L’attaque exploite la capacité de HTML 5 a honorer des requêtes dites « cross-origin with credentials« . Ce type de requête permet d’envoyer une requête POST à partir d’un domaine vers un autre en fournissant le cookie d’authentification appartenant au premier.

Les protections

Ces trois attaques ne sont en l’état que d’habiles « astuces » présentant un certain potentiel malveillant, et non de véritables vulnérabilités. Mais elles illustrent parfaitement les points à sensibles de HTML 5 : une plus grande ouverture vers l’application locale (et donc, le client) et une ambition applicative certaine, qui pourrait prendre les développeurs de court. Il serait en effet très facile (et dangereux) de considérer HTML 5 comme une simple évolution de HTML 4 et de se contenter de simplement mettre à jour ses déclarations d’en-têtes de pages HTML…

Krzysztof Kotowicz propose trois conseils de sécurité afin de minimiser l’impact de ces attaques :

• Utiliser X-FRAME-OPTIONS : DENY dans les application web afin que le document ne puisse être rendu dans un cadre.
• Envisager de randomiser légèrement certains éléments de l’interface graphique afin de lutter contre les attaques de « masquage d’interface » (une technique utilisée notamment dans le l’attaque de filejacking ci-dessus, mais également essentielle aux attaques de clickjacking traditionnelles)
• Exiger le retour d’un jeton aléatoire à chaque requête POST afin de s’assurer que celle-ci provient bien d’un formulaire légitime sur le site.