Benoit Piette

N’oubliez de venir faire un tour à la prochaine assemblée du W3Québec, Mathieu Chartier va nous présenter un état de l’art sur Javascript. À ne pas manquer. Les réunions du W3Québec sont toujours au CRIM, au 550 Sherbrooke Ouest à Montréal, le dernier . Malheureusement, nous n’avons plus les moyens pour que les présentations soient diffusées en visio-conférence à Québec. Personne n’a actuellement le temps de regarder la problématique dans tous ses angles. (Mais si vous avez le goût de nous préparer qqch la dessus, ce serait sûrement bien apprécié!)

Ouf… Pas que je n’ai pas le temps d’écrire ces temps-ci. Je commence juste à m’acclimater à ma nouvelle job. Je ne sais pas, je passe un peu moins de temps sur le Web. Je commence à me remettre à lire quelques blogues, question de savoir ce que j’ai manqué. Zut, j’ai manqué DemoCampCUSEC1, moi qui veut justement migrer mon blogue à Ruby. Le problème, qui je l’admet est souvent le même, c’est que j’ai plein d’idée de projets ou encore juste plein de trucs à faire, mais ils ont tous le même niveau de priorité. Ce qui fait que je n’avance pas. Mais en même temps, c’est peut-être pas fou non plus que j’en fasse un peu moins, et que je laisse mon laptop à ma fille pour qu’elle puisse jouer à Black & White. Il y a BarCamp2 Montréal qui s’en vient, ce qui risque d’être très intéressant, faut juste que je trouve quelque chose d’utile à présenter. Ahhhh l’insipiration, juste d’écrire un peu comme cela devrait m’aider .

Le trou de sécurité de GMail dont j’ai parlé dernièrement m’est resté dans la tête et je me disais qu’il fallait trouver un moyen simple d’empêcher que ce genre de chose ne puisse se passer sans notre consentement (lire la possibilité de bloquer un appel javascript entre domaines). J’ai aussi lu quelques articles sur comment JSON est bien meilleur que XML (moi personnellement ça ne me fait ni chaud ni froid : JSON me semble effectivement plus simple à utiliser dans bien des cas, mais ça ne veut pas dire que XML est mal non plus… ). Un des articles en question que j’ai lu est celui-ci : JSON vs. XML: Browser Security Model [en]. Il est possible d’inclure un javascript qui provient d’un autre site Web (ex: Google, Yahoo ou Amazon) qui est en fait un Web Service dans le sens Web 2.0 du terme. Ce code javascript appelle une autre fonction javascript qui elle provient du site où nous sommes en ce moment. Le javascript appellant envoie des paramètres seulement accessible à partir du Web Service au premier site Web. On peut passer ainsi des données d’un site Web à un autre sans passer par un proxy. En fait nous pourrions faire tout cela si un serveur Web appelle un autre serveur Web pour faire du mashing de données entre deux sites Web. Il y a toutefois deux grosses différences, premièrement c’est extrêmement plus facile de le faire par une simple balise script et un callback javascript. La deuxième qui est à mon avis ici encore plus importante, c’est que en faisant un appel à un script au site Web #2 à partir d’une page provenant du site #1, nous envoyons notre cookie du site #2 à partir du site #1 et que nous nous loggons au site #2 et que le site #2 envoie des données spécifiques à nous au site #1. Et c’est exactement ce qui s’est passé dans le trou de sécurité de GMail. Mais de façon générale, ces Web Services servent à passer de l’information que nous pourrions considérer comme confidentielle d’un site Web à un autre. Pire, en nous loggant à un Web Service, nous offrons un vecteur d’attaque à un site tiers à nos données confidentielles qui sont stockés sur un site qui contient des Web Services de ce type. S’il y a un trou de sécurité dans le Web Service, et bien nous sommes fait, pour ne pas dire baisés comme c’était le cas dans le trou de sécurité de GMail. C’est pour ce genre de choses qu’il y a une restriction à XmlHttpRequest. En fait ce qui fait peur, c’est qu’il y a un paquet de sites Web 2.0 qui basent leur modèle d’affaire sur ce qui est à mon avis un trou de sécurité dans les navigateurs. À un moment donné il va falloir réfléchir si les avantages des mashups et autres application Web 2.0 sont plus grands que les désavantages causés par les trous de sécurité qui y sont ratachés. Il va à mon avis falloir bloquer tout cela comme nous l’avons déjà fait avec les contrôles ActiveX. D’ailleurs, je ne connais pas encore d’extensions Firefox qui bloque les callback javascript inter domaines, mais je pense que si ça n’existe pas, il faudrait bien que quelqu’un en écrive une !

C’est tu moi où j’ai l’impression qu’il y a des plus en plus de problèmes avec GMail ces temps-ci. Des lenteurs et temps morts intermitants et maintenant un beau gros trou de sécurité qui rend notre liste de contact facilement hackable. Une façon facile d’empêcher le script de fonctionner est de bloquer tout cookie provenant de docs.google.com. Cela empêche le site de savoir que vous êtes présentement connecté à GMail et d’envoyer la liste de contacts. Faudrait que je vérifie, mais il me semble que tout téléchargement de javascript ne devrait se faire qu’à partir du même domaine, comme c’est le cas pour XmlHttpRequest. Ça briserait plein d’applications, mais ça empêcherait ce type de trou de sécurité. Et ce serait beaucoup mieux pour notre vie privé. N’y a-t-il pas une option dans Firefox pour bloquer tout cela ? Je pense qu’il faudrait que je regarde AdBlock un de ces quatre… Enfin, faut pas être trop paranoïaque non plus…