[TechDays2012] HTML5 et la sécurité

Excellente session présentée par Sébastien Gioria de OWasp. Je précise que ces articles sont à base de mes notes pendant les sessions, donc que ça peut paraître parfois un peu tapé au kilomètre. Mais j’ai bien sûr tout repris et remis en forme avant publication, et c’est ce qui me permet de mettre, après coup, ces appréciations sur les sessions. Celle-ci était particulièrement bien menée, avec une personne très experte, s’exprimant bien, avec un contenu étoffé et avec un plan clair. Bref, 20/20 si je peux me permettre de noter…

WebSocket, WebMessaging, IndexedDB, Offline web application, Web Storage, Cross Origin Resource Sharing sont des APIs liées à HTML5, et qui peuvent fournir des opportunités à un attaquant. Le but de cette session est de les passer en revue et de voir en quoi elles peuvent améliorer, mais plus souvent dégrader, la sécurité.

L’intervenant commence par définir ces différentes API, mais en reprenant mes notes sur la conférence, je m’aperçois que ce sera plus pratique de regrouper, pour une référence écrite.

WebMessaging

Il s’agit d’un mécanisme d’échange de JSON entre plusieurs iFrames. Il n’y a pas de principe de validation du contenu : c’est au récepteur de se débrouiller pour vérifier que ce n’est pas offensif.

IndexedDB

Stockage d’objets en local. Sensible aux injections SQL, donc…

Forms

Falsification de Forms : on peut piloter un formulaire en dehors du contenu de la balise <form>. Ce n’était pas possible en HTML4, mais en HTML5, on peut rajouter une <input> en dehors du <form> et qui pointe sur celui-ci ! On peut rajouter un input de type submit avec un formaction qui pointe sur une autre URL. C’est évidemment un gros problème, et il est même étonnant que le pas ait été fait pour aller vers moins de sécurité.

Protocol handlers

En HTML5, on peut enregistrer des handlers de protocole, et surtout la norme ne rend pas obligatoire de valider par une autorisation de l’utilisateur.

Cross Origin Resource Sharing

Ce point particulier pose réellement problème. Normalement, XmlHttpRequest ne permet de dialoguer que sur le même domaine. C’est quelque chose qu’on apprend la première fois qu’on essaie de mettre en place de l’AJAX. En HTML5, on autorise à aller plus loin. Le champ Access-Control-Allow-Origin dans le header permet d’ajouter des URLs autorisées, voire même carrément *. On peut du coup faire du bypass d’accès. Si un serveur intranet met ceci en *, cela veut dire qu’une application extranet pourrait pointer en JavaScript dessus, et renvoyer l’information sur le serveur qui ne devait pas avoir accès à l’intranet.

On peut également se servir de ce détournement pour faire réaliser à une victime des attaques par DOS sur une cible donnée. Du coup, attention aux modifications des entêtes par un attaquant.

Offline Web Applications / WebStorage

Il s’agit d’un système de stockage d’objets JSON en cache local à la machine cliente. L’utilisateur n’a pas de contrôle sur ce qui est stocké. L’injection de JavaScript peut bypasser la limitation du contrôle d’accès => vol de sessions, de données sensibles, tracking d’utilisateur, etc.

Attention, le flag HTTPOnly des cookies ne fonctionne pas sur les localStorage ! Du coup, une application JavaScript pour aller lire le contenu du storage d’une autre application. Elle a juste à découvrir la structure. Rien à voir donc avec l’IsolatedStorage de .NET, qui permet de bien étanchéifier les stockages locaux en fonction des applications signées. Mais en même temps, c’est un peu logique : les applications ne sont pas signées sur le web, et surtout elles sont beaucoup plus multiples que les applications riches déployées par un processus interne, même s’il est automatisé.

Si les localStorage ne sont pas supprimés forcément lorsqu’on efface l’historique, cela permettra de suivre l’utilisateur encore plus que les cookies, qui étaient limités dans le temps.

WebSocket

L’API WebSocket permet de communiquer par tunnel entre différents domaines, dans le but de diminuer la taille des données véhiculées. Le client demande un UpgradeWebSocket au serveur. Du coup, on revient un peu à HTTP 1.0 où la connexion restait ouverte si possible (en HTTP 1.1 sans KeepAlive, on ferme tout de suite la connexion). Ceci va permettre de lancer des shells distants, de faire du port scanning, ou même du proxy poisoining.

Divers

Application Offline : <html manifest=”/cache.manifest”> permet de garder tout ce qu’on cherche en cache. Les Advanced Persistant Threats vont être facilitées, en gardant des points d’attaques y compris après être sorti d’une application.

WebWorkers en JavaScript : permet de lancer des processus longs JavaScript, mais du coup, cela va faciliter les calculs distribués (Ravan pour calculer des MD5 / SHA1 pour attaque par Rainbow Tables), ainsi que les attaques par DOS.

Attention, CSS3 facilite le ClickJacking par la possibilité d’injecter du JavaScript.

Une touche d’espoir ?

La sécurité a tout de même été prise en compte dans HTML5.

Par exemple, il y a un système de bac à sable pour les iFrame. On peut limiter en empêchant les formulaires, les scripts, les plugins. De même, les iFrames sandbox sont interdits de LocalStorage, etc. Par contre, les différents contenus allow-… permettent de libérer certaines fonctions. Attention, tous les navigateurs ne supportent pas bien toute cette granularité de droits.

http://caniuse.com est le site de référence pour savoir quel navigateur supporte quelle fonctionnalité de HTML5. Peut-être que les retours des chercheurs en sécurité vont permettre de faire modifier la norme. Mais les développements commencent déjà, donc ça risque de poser problème.

Conclusion

Forte ouverture de la surface d’attaque, car l’ouverture s’est clairement faite au détriment de la sécurité. Attention également à la part belle qui est faite à JavaScript, alors que celui-ci est toujours exécuté en dehors du consentement utilisateur, à part une activation unique pour toutes les applications lors de la configuration du navigateur.

Encore une fois, cette session était de très grande qualité, et si vous vous intéressez à la sécurité ou à HTML5, je ne peux que vous conseiller de la visionner lorsque les webcast seront disponibles (quelques semaines après l’évènement, en général). Et un grand merci à Sébastien Gioria s’il me lit !

About JP Gouigoux

Jean-Philippe Gouigoux est Architecte Logiciel, MVP Connected Systems Developer. Il intervient régulièrement à l'Université de Bretagne Sud ainsi qu'à l'Agile Tour. Plus de détails sur la page "Curriculum Vitae" de ce blog.
This entry was posted in Retours, Sécurité and tagged . Bookmark the permalink.

2 Responses to [TechDays2012] HTML5 et la sécurité

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha Captcha Reload