Pas mal de sites web dits "2.0" sont en fait une simple extension des navigateurs via l'emploi des technologies comme Flash, AJAX ou Java. Ces technologies transforment le navigateur en moteur de rendu (Vue et Contrôleur) d'un tryptique MVC (Modèle/Vue/Contrôleur) généralement acquis en développement, le serveur étant relégué au stockage et à la modélisation des données (quoique ...). Le développement de ce type d'applications web se rapproche dès lors beaucoup plus du développement d'application client/serveur que des applications compilées classiques, un poil plus complexe que de simplement coller à un programme une interface utilisateur (UI) gérée par un navigateur.
Web 2.0 et services web
Une des pratiques courantes lors du développement de ce type de site consiste à implémenter un service proposant une interface accessible via le protocole HTTP, basée sur des protocoles standardisés comme SOAP par exemple, et une interface cliente exploitant l'interface du service. Cette interface de service n'est bien sûr que la partie visible de l'iceberg, toute la logique métier implémentée dans le service n'étant pas directement exposée/accessible.
L'interface SOAP/XML employée pour permettre l'envoi de requêtes au service développé peut être employée par différents langages, différents composants, et c'est en partie ce qui motive le développement de ce type d'interface couplée au service. De plus, ces services peuvent reposer sur une base de données, et exposer des informations intéressantes, bien qu'utilisées globalement par l'application. La partie cliente se résume à une applet Java ou Flash, voire même JavaScript (grâce au composant XMLHttpRequest), permettant d'interagir avec le service. Cette partie cliente offre plus ou moins de fonctionnalités, selon les désirs du ou des développeurs.
L'avantage de ce principe de développement est que les implémentations du service et de l'interface cliente peuvent se faire séparemment. Les inconvénients eux sont multiples: sécurité par l'obscurantisme et laxisme dans les vérifications.
Des services web obscurs ...
Une des lubies des développeurs de services web "sécurisés" consiste à supprimer toute information concernant le modèle des données (principalement les noms) mais de conserver les structures, ce qui est une obligation pour le bon fonctionnement du service. Cette pratique rend difficile l'analyse du service web: sans repère textuel, impossible de connaître les arguments de telle ou telle méthode offerte par le service. Cela peut sembler sécurisé, mais au final l'interface cliente possède ces informations en son sein: il suffit juste de l'analyser pour retrouver comment les méthodes sont appelées, ce qui dans le cas d'applets Flash ou java n'est pas très difficile à réaliser.
De même, certains services web implémentent des méthodes spéciales, réservées à des tâches d'administration, mais qui ne sont pas liées avec l'interface cliente. De fait, personne ne soupçonne l'existence de ces méthodes, jusqu'à ce que quelqu'un aille jeter un oeil au WSDL. Le WSDL, kezako ? Simplement un langage de description de services web (Web Service Description Language), communément supporté par plusieurs moteurs de services web (Axis, etc ...). Voici un exemple de fichier WSDL.
D'après mon expérience, ces problèmes sont récurrents d'une part à cause des développeurs (méthodes de débogage, de taçage) et d'autre part à cause des décideurs (méthodes implémentées pour une future version par exemple). Mais le fait est là: ces méthodes obscures peuvent permettre à un attaquant de prendre le contrôle d'un service web, et pourquoi pas du serveur hébergeant le service. De même, la tentative de camouflage des paramètres passées aux méthodes exposées par le service web tombe à l'eau dès que l'interface cliente est identifiée.
... et des développeurs naïfs
Une autre attaque commune consiste tout simplement à réimplémenter l'interface client, en enlevant toutes les vérifications effectuées et en augmentant ses fonctionnalités. Cela fonctionne (grâce ?) à cause du manque de vérification effectuées par le service web lui-même. Ceci est une conséquence de la dissociation lors du développement des implémentations du service web et de l'interface cliente: l'un se repose trop sur l'autre. Et ce qui devait arriver se produit généralement: l'interface cliente effectue tout un ensemble de vérifications sur les données saisies par exemple, avant de les envoyer au service web, qui lui ne fait pas toutes les vérifications et se retrouve donc vulnérable lorsqu'une interface tierce communique avec lui (rappelons que cette possibilité d'interfaçage est inhérente à la présence du service web). J'ai pu démontrer à maintes reprises dans différents articles de ce site que cela était possible.
Presque-conclusion
L'évolution du web (non, je n'aime pas le terme "Web 2.0") est telle que le développement web se rapproche de plus en plus du développement applicatif dit "classique", avec la même vision des enjeux et problématiques. Il est donc important que les développeurs web d'aujourd'hui adaptent leurs implémentation et notamment la sécurité à l'évolution (sic) des technologies, de façon à protéger de mieux en mieux les applications web. Il serait peut-être temps, car bon, les standards abordés dans ce post ne sont plus du tout très jeunes ...