Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

HTML5 : quid de la sécurité ?

février 2012 par Emmanuelle Lamandé

HTML5 est le futur standard pour le développement des pages Web. Même si ses spécifications ne sont pas encore définitivement arrêtées par le W3C*, on en connaît déjà les grandes lignes. Les nouveautés d’HTML5 devraient certes permettre d’améliorer l’expérience utilisateur coté visuel, mais apporteront aussi leurs lots d’écueils côté sécurité… le comble pour un standard qui se voulait plus simple, ouvert et surtout mieux sécurisé. Sébastien Gioria, Auditeur Systèmes d’informations et Sécurité, Groupe Y Audit, revient sur les principales spécificités d’HTML5, lors des Microsoft TechDays.

La nouvelle version du langage de développement est dotée d’un certain nombre de nouveautés. Outre une révision de la structure et de l’organisation du code, HTML5 introduit une nouvelle couche d’API. Au total, huit nouvelles APIs seront proposées dans cette première version du HTML5, dont WebSocket, WebMessaging, IndexedDB, OffLine Web Application, WebStorage… Ces API devraient permettre aux développeurs d’offrir un code mieux organisé et plus conforme aux standards du W3C*.

Toutefois, comme le souligne Sébastien Gioria, même si certaines améliorations sont indéniables avec HTML5, chacune de ces nouveautés apporte aussi son lot de risques et d’écueils. Il met ainsi en exergue quelques points d’attention sur lesquels les développeurs devront être particulièrement vigilants :

 Falsification de Forms : avec HTML5, il est possible de contrôler un formulaire en dehors du contenu de la balise "form". L’injection de Forms est une vulnérabilité propre à HTML5, qui n’existait pas dans HTML4…

 Webstorage donne la capacité au navigateur de stocker jusqu’à 10 Mo de données. Toutefois, l’utilisateur n’a pas de contrôle sur ce qui est stocké ou accédé. L’injection de Javascript peut permettre de bypasser la limitation du contrôle d’accès, et ainsi dérober des données sensibles, des sessions… mais aussi de traquer l’utilisateur. En effet, le flag HTTPOnly des cookies ne fonctionne pas sur les LocalStorage. Celles-ci ne sont pas forcément effacées lors de la suppression de l’historique. Il est donc possible de créer des identifiants (de type cookies) persistants permettant de suivre l’utilisateur.
Il est d’ailleurs surprenant que la CNIL ne soit pas intervenue sur ces problématiques, souligne Sébastien Gioria.

 Les WebSockets permettent d’effectuer des connexions persistantes et bi-directionnelles entre le client et le serveur, ce qui favorise le développement d’applications temps réel, multi-utilisateurs… Toutefois, les WebSockets laissent la porte ouverte à un certain nombre d’attaques, dont certaines sont triviales : Shell Distant, Botnet Web (via un XSS ou tout simplement en se connectant à un site Web), port scanning...

 Offline Web Applications offre l’opportunité au développeur d’exécuter tout ou partie des applications, même en étant déconnecté. Cependant, cette fonction facilite aussi la pollution des caches de navigateurs (via un point d’accès malveillant), même du SSL, voire la mise en œuvre d’attaques de type APT.

 Cross Origin Resource Sharing (CORS) : jusqu’à présent XmlHttpRequest (XHR) ne pouvait dialoguer qu’avec le site Web originaire du Javascript. Avec HTML5, on peut aller plus loin, puisque le champ Access-Control-Allow-Origin dans l’entête permet d’ajouter des URLs autorisées, voire même « * » : une nouveauté qui permet de bypasser le contrôle d’accès, et donc de voler de l’information en entreprise, mais aussi de faire des attaques en DDoS.
Afin de limiter les risques, il conseille, entre autres, de :
• Restreindre le domaine : en ne mettant pas d’étoile dans le champ ;
• Ne pas faire confiance à l’entête, puisqu’elle peut avoir été modifiée par l’attaquant ;
• Mettre en place des contre-mesures réseaux pour les DDoS.

 WebMessaging permet une communication entre différents documents HTML, mais facilite aussi la perte de données sensibles, si elles sont envoyées à une mauvaise iframe par exemple.

 L’API de géolocalisation peut également poser certains problèmes de sécurité et de respect de la vie privée, puisqu’elle permet d’accéder aux coordonnées de l’utilisateur et donc de savoir où il se trouve.

A l’origine, HTML5 n’a pas été conçu pour devenir une nouvelle norme « non sécurisée ». La volonté première était de créer un standard sécurisé, ouvert et plus simple. Les protagonistes de ce nouveau standard ont d’ailleurs pris en compte un certain nombre de problématiques de sécurité : par exemple, le principe de « Bac à sable » pour les iframes représente une avancée, même si tous les navigateurs ne supportent pas encore tous ces éléments aujourd’hui.
Même si Sébastien Gioria dénombre de nouvelles API intéressantes pour le développeur, il déplore que l’ouverture ne se fasse au détriment de la sécurité. Plus vous intégrez de nouvelles fonctionnalités, plus la surface d’attaques est accrue (vol d’informations, DDoS, APT…). HTML5 fait la part belle au Javascript, qui pourtant peut s’exécuter sans le consentement de l’utilisateur.

L’Enisa a, d’ailleurs, mis en exergue pas moins de 51 problèmes de sécurité concernant HTML5, suite à une analyse effectuée en 2011 : www.enisa.europa.eu/act/application-security/web-security/a-security-analysis-of-next-generation-web-standards.

Toutefois, les spécifications du HTML5, réalisées par le W3C, ne sont pas encore terminées. La norme n’est donc pas figée et devrait encore évoluer. « Nous espérons bien que certains des points de sécurité évoqués seront intégrés dans la version finale » conclut-il.


* World Wide Web Consortium

Pour en savoir plus :

http://www.w3.org/TR/html5/

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

http://html5test.com/: testez le support de votre navigateur vis-à-vis de la norme


Articles connexes:

Voir les articles précédents

    

Voir les articles suivants