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...

Une bonne manière d'éviter les potentiels de Cross Site Scripting en utilisant JSP et Struts est de toujours utiliser l'attribut filter="true" lors debean:write

Je viens de lire (en diagonale je l'admet) un excellent article[en] sur l'hameçonnage (phishing) sur O'Reilly network. Celui-ci explique en détail ce type d'attaques et les façons de se protéger.

C'est en lisant un article sur securityfocus et des discussions qui le suivaient sur quelques blogues que je me suis rappelé (ou rendu compte) comment notre date de naissance est une information confidentielle dont on oublie souvent l'importance. En effet, elle est souvent utilisée (à tort à mon avis) pour authentifier quelqu'un, par exemple lors de l'activation d'une carte de crédit.

Pour quelqu'un qui connaît notre date de naissance, il est plus facile d'effectuer un vol d'identité, qui dans notre monde hyper-informatisé et automatisé est certainement faisable. Il est donc très important de ne pas donner cette information à n'importe qui et il est très important de ne pas la mettre sur notre site Web ou notre C.V. Un billet du type « C'est ma fête aujourd'hui » est évidemment à éviter!