Dernièrement, des manchettes ont pointé sur certaines failles de sécurité particulières au HTML5. Pourtant, il n’y aurait pas là de quoi s’énerver le pompon puisque, dit-on chez les experts, le processus de développement de ce langage n’est pas encore complété.
Sur fond de chicane impliquant les plus grands noms de l’industrie, dont Apple, Adobe, Microsoft, Google et Mozilla, le HTML5 (HyperText Markup Language), la prochaine grande version du vieux langage Web, progresse. Il incarne déjà le célèbre mot du scientifique John Cage, une légende du monde UNIX, « The Network is the Computer ». Infiniment mieux que son prédécesseur, le 5 confie au réseau une gamme de services intelligents (applications, fonctions, API, etc.), éliminant l’obligation d’installer bien des logiciels ou utilitaires dans un poste de travail. Quant aux données qui en résultent, elles se trouvent sur un dispositif local contrôlé par l’usager, ce qui inclut, par exemple, les clés USB. Ces services, également appelés RIA (Rich Internet Applications ou Rich Interactive Application) selon qu’on écoute les évangélistes d’Adobe ou de Microsoft), ne nécessitent aucune installation dans un ordi client et peuvent parfaitement bien ronronner dans un environnement étanche (au sens sécurité) appelé Sandbox (carré de sable). Fondamentalement différentes des plugiciels ( plug-ins) qui s’installent sur l’ordi client et qui ne fonctionnent qu’avec le fureteur pour lequel ils ont été bidouillés, les RIA sont universelles. Par exemple, quel que soit le fureteur, quel que soit le système d’exploitation, la vidéo pourra s’afficher pleine page dans ledit fureteur (ce qui explique la chicane entre Apple et Adobe relativement au Flash, une techno qu’Apple a déclarée caduque puisque, pour afficher de la vidéo, elle nécessite l’ajout d’un plugiciel pas toujours compatible). Essentiellement, on parle d’un raboudinage de technos permettant infiniment plus que ne l’avait jamais espéré le créateur du WWW, Tim Berners-Lee. Comme il est devenu possible de baliser et présenter la vidéo, l’audio, les équations mathématiques, les modèles complexes, l’animation 2D et les polices de caractères marginales, « le Web est en train de devenir une plateforme informatique orientée client », avait soutenu en 2009 le célèbre physicien britannique lors de l’assemblée annuelle du Worldwide Web Consortium (W3C). Tellement que la version 5 du HTML ouvre toute grande la porte au développement d’applications/services Web (RIA) dont pourront bénéficier les fureteurs évolués. « Pourront » ou « peuvent »? Disons que dans l’état actuel du grand projet, celle de la révision 1.4263, les versions récentes des fureteurs Internet tirent fort bien leur épingle du jeu. En ce sens, le HTML5 est un work in progress auquel les fureteurs s’adaptent au fur et à mesure. Cela implique évidemment une gamme parfois inquiétante d’enjeux de sécurité. Comme ce qu’on affiche dans un fureteur est de plus en plus complexe au sens « lignes de code » du terme, les recoins à surveiller et protéger sont plus nombreux que jamais. La probabilité de failles exploitables est beaucoup plus grande qu’à l’époque, disons, de Netscape Navigator. Mais rien ici n’est vraiment nouveau. Ce n’est que la suite de ce qui se faisait déjà. L’industrie évolue, les malfaiteurs s’adaptent. On se rappelle du débat quand apparurent les témoins (cookies), ces petits cafards que certains sites Web installaient dans nos ordis pour mieux nous reconnaître, pour nous amener à nos préférences, pour nous simplifier la vie. À l’époque, des défenseurs du droit à la vie privée avaient dénoncé ces « intrusions extérieures », craignant notamment que des fouineurs criminalisés puissent s’approprier l’info de ces témoins. Or, le HTML5 va beaucoup plus loin. Au lieu d’un microfichier d’à peine 1 ko, on parle désormais de données en quantité illimitée. C’est le prix à payer pour utiliser des produits comme Google Docs ou Office Live. Ainsi, un hacker malintentionné pourrait récolter infiniment plus d’info. Autrement dit, ses efforts d’intrusion peuvent s’avérer beaucoup plus rentables. Pire, il pourrait remplacer des données, leur substituer des infos malveillantes (par exemple, remplacer la BD SQL locale), de sorte qu’en se synchronisant avec le système de l’entreprise, le poste client pourrait initier une contamination très sérieuse. Autre exemple, on connaît ces JavaScript qui envoient des requêtes XML HTTP au site Web sur lequel est connecté l’ordi client. Or, la nouvelle mouture du bon vieux protocole pousse cette possibilité plus loin. Avec certaines applications utilisant, par exemple, la fonction « PostMessage() », l’ordi client peut établir un lien de communication avec n’importe quel serveur le permettant. C’est le cas d’un site HTML5 qui va afficher de l’info dynamique colligée sur différents sites en ligne (mashup), des sites acceptant, supposons, les requêtes clients XML HTTP. Supposons qu’un de ces sites soit de mœurs déplorables, il pourra lui être facile, alors, de déposer un exécutable malveillant dans le PC visiteur. Puis, récemment, on a parlé de débordement de tampon (buffer overflow) particulier à Canvas, un API de rendu d’image particulier au HTML5, grâce auquel du code malveillant pourrait être injecté. On a parlé également de la Offline Application Cache (OAC), une autre caractéristique du HTML5 qui donne des sueurs froides. En cliquant sur ce lien, vous pouvez suivre les explications d’un programmeur qui a réussi à hacker un compte (pourtant HTTPS) de GMail en zigonnant dans une faille d’OAC. On a aussi parlé des dangers de la géolocalisation grâce à laquelle, un hacker connaissant le HTML5 peut, à notre insu, savoir où l’on est. Et ainsi de suite. Mais cela, tous les experts en sécurité le savent et la plupart sont d’avis qu’à la publication finale du standard HTML5, cet enjeu aura été réglé. Jusqu’à ce que les méchants trouvent une parade, on s’entend. Il en a toujours été ainsi, non? En fait, ce qui précède a été cité par des experts lors du USENIX Security Symposium tenu, il y a quinze jours, dans la capitale américaine. Ce sont des exemples qui mettent en évidence le travail devant encore être abattu avant que le HTML5 ne soit vraiment propulsé à l’avant-scène par le consortium responsable de son développement, le W3C.
Nelson Dumais est journaliste indépendant, spécialisé en technologies de l’information depuis plus de 20 ans.
