Ajax et la sécurité
| L'usage croissant d'Ajax dans les développements remet sur le devant de la scène les risques de sécurité liés à l'exploitation de codes JavaScript. Mais ce risque est-il suffisamment bien pris en compte dans les projets ? |
| Envoyer | | Imprimer |
| | En savoir plus | |
| |
| |
On ne présente plus Ajax (pour Asynchronous JavaScript and XML). Un acronyme qui, rappelons le, évoque moins une technologie qu'une méthode consistant à exploiter conjointement plusieurs langages, en vue de créer des interfaces Web se rapprochant du client riche. L'une des fonctions les plus connues qu'il permet de créer : la possibilité de mettre à jour une partie d'une page sans nécessiter son rechargement dans le navigateur.
Dans cette optique, l'Ajax combine le HTML (ou XHTML) pour la structure sémantique des informations, le CSS pour la présentation des informations, le DOM et JavaScript pour afficher et interagir dynamiquement avec l'information présentée, et enfin l'objet XMLHttpRequest pour échanger et manipuler les données de manière asynchrone avec le serveur Web (dixit Wikipedia).
L'usage croissant d'Ajax dans les développements, notamment sur le Web, remet sur le devant de la scène les risques de sécurité liés à l'exploitation de codes JavaScript. Si l'application est peu ou pas sécurisée, ces derniers peuvent en effet laisser ouvert un pont entre Internet et les applications de l'entreprise, que ce soit son site Web ou son intranet.
Simplement parce qu'il engendre une multiplication des communications entre le navigateur client et le serveur, Ajax crée autant d'opportunités pour une personne malveillante. Selon les experts en sécurité, il amplifie notamment les risques d'attaques de type screen-scraping et cross-site scripting. Certains éditeurs, tel Fortify (avec la dernière version de Secure Coding Rulepacks), proposent des solutions pour aider à traquer les failles dans le code source.
| Utiliser un identification unique universel |
Mais au-delà de JavaScript, les vulnérabilité peuvent provenir des requêtes XMLHttpRequest (flux XML transitant par le port HTTP par définition ouvert) qui gèrent les liens avec la base de données. Comment en effet empêcher une personne non autorisée de lancer des requêtes XML non autorisées ?
Une première réponse est de mettre en place un pare feu capable d'analyser les requêtes XML, et de bloquer les demandes litigieuses (ce qu'intègre la plupart des pare feu modernes). Autre solution : exploiter un identifiant unique universel (UUID) lors de la création du code HTML, et fournir ce code à la requête JavaScript lors de son activation afin de permettre sa validation par le serveur.
| | En savoir plus | |
| |
| |
Fin 2006, différents intervenants de la Black Hat Conference avaient pointé du doigt un manque des manuels de développement. Selon eux, ils ne mettent pas assez en garde les développeurs contre les vulnérabilités d'Ajax et surtout les moyens de sécuriser les sites créés.
L'échange et la réutilisation de codes Ajax ne sont également sans doute pas étrangers aux problèmes rencontrés. Mais, malgré les risques potentiels encourus, sans une attaque majeure d'un grand site, les recommandations de la Black Hat risquent fort de rester lettre morte.
Aucun commentaire:
Publier un commentaire