Michal Zalewski vient de rendre public une étude approfondie des « règles du bien programmer » et du « bien protéger » dans le domaine des navigateurs Web. Intitulé « Browser Security Handbook », ce travail minutieux, profond, est disponible en téléchargement gratuit sur les serveurs de google code. L’auteur y examine Internet Explorer (versions 6 and 7), Firefox (versions 2 and 3), Safari, Opera, Chrome, le navigateur embarqué d’Android et divers add-on majeurs.
A qui s’adresse cet ouvrage ? De prime abord aux développeurs d’applications et aux hommes sécurité. Les uns pour qu’ils puissent comprendre les raisons de ces réactions parfois étranges qui différencient les navigateurs face à une page html manifestement « standard », les autres pour saisir les failles de conception non pas des navigateurs, mais des fonctions du langage de description html. Tout au long de cette route couverte d’embûches, personne n’est innocent. Entre les « habitudes de programmation », les « usages généralement acquis », les « règles normatives imposées par les RFC », chaque navigateur a dû jongler avec ce qui est permis, ce qui est toléré… et ce qui existe déjà et doit continuer à être interprété. En fait, nous apprend sans grande surprise Zalewski, les contraintes de compatibilité ascendante, l’héritage du passé, les « astuces admises» ont, peu à peu, créé des failles de conception énormes. Et ce n’est pas un simple retour à l’orthodoxie du code qui remettra les choses en place. Non seulement parce qu’un respect stricte des règles rayerait de la carte une majorité de sites. Parce que les éditeurs, Microsoft en tête, ont « intégré » dans leurs interprètes, ces libertés d’écriture. Parce que le html est vivant et que chaque naissance de nouveau protocole, chaque fonctionnalité « moderne » apporte son lot de conflits avec le passé et de questions techniques pouvant être interprétées de milles manières différentes.
Quelle serait la solution pour retrouver une situation stable ? Faire de html un langage strictement borné ? Ainsi, l’absence de « slash » en fin de définition n’est pas, à priori, une contrainte bloquante à l’heure actuelle… faudrait-il que ce soit le cas ? L’on se couperait alors de toutes les pages « mal écrites » qu’un Internet Explorer affiche aujourd’hui sans le moindre état d’âme. Devrait-on « parser » le code tout entier avant la moindre interprétation ? Ce pourrait-être une solution fort pratique d’un point de vue sécurité, idéale sous l’angle de l’orthodoxie du source… mais contraignante en terme de temps de réaction et, une fois de plus, de compatibilité avec les sites existants. Ce ne sont là que quelques questions rapidement survolées, qui se complexifient au fur et à mesure que Zalewski nous raconte l’histoire du Web et nous brosse son devenir. La gestion des balises de streaming en html 5, par exemple, nécessiterait, si l’on souhaite « coller à la norme », une réécriture de tout ce qui se trouve sur le moindre IIS, sur le plus petit serveur Apache… ainsi que sur la totalité des actuelles machines qui diffusent du contenu audio ou vidéo.
Pessimiste, l’étude de Zalewski ? Réaliste plutôt. Il ne serait pas sage de s’arrêter aux raisons purement historiques qui ont conduit à la situation présente, de ne retenir de ce travail impressionnant que son aspect critique. Bien au contraire, la connaissance intime de ces petits défauts héréditaires permet au programmeur et à l’administrateur Wan d’éviter de commettre à nouveau de vieilles erreurs commises par habitude et d’anticiper des comportements anormaux qui tenteraient de les exploiter. Et là , l’on ne peut qu’admirer l’expérience, les années de pratique, les trophées innombrables de failles que l’auteur a accumulées au fil des années. Une expérience qu’il nous communique sans que cela ne coûte autre chose que l’effort que de lire ce pavé dense. De toute manière, le week-end risque d’être gris et froid…
