Contribuez à SecuObs en envoyant des bitcoins ou des dogecoins.
Nouveaux articles (fr): 1pwnthhW21zdnQ5WucjmnF3pk9puT5fDF
Amélioration du site: 1hckU85orcGCm8A9hk67391LCy4ECGJca

Contribute to SecuObs by sending bitcoins or dogecoins.



Nouvelles perspectives d’attaques pour les technologies Web 2.0

Par Rédaction, secuobs.com
Le 23/10/2006


Résumé : Les technologies émergentes liées au Web 2.0 sont de plus en plus utilisées par les internautes : RSS, wikis, blogs, AJAX. Leur généralisation introduit de nouvelles menaces de part notamment la multitude de flux (et donc d'entrées) entre le client et le serveur.



Les technologies émergentes liées au Web sont de plus en plus utilisées par les internautes : flux RSS, wikis, blogs, applications AJAX [ lien ]. De nombreuses applications, autrefois développées sous forme de logiciels, sont désormais accessibles sur de simples navigateurs.

A titre d’exemple, un grand nombre d’entreprises proposent à leurs collaborateurs des interfaces Web permettant de poser des congés, de gérer leurs emplois du temps, d’accéder à leurs informations personnelles, etc.

Le terme de “Web 2.0” [ lien ] a été introduit par O’Reilly au travers de conférences et de publications pour désigner les nouvelles directions que prenait le Web, avec une interaction utilisateur toujours plus importante.

La généralisation des langages exécutés “côté serveur”, tels que l’ASP ou le PHP, ont beaucoup fait évoluer les problématiques de sécurité. Des tests d’intrusion externes mènent bien souvent à la découverte de vulnérabilités sur les “applications Web” hebergées.

Etant situés en bordure de réseau (bien souvent dans les zones démilitarisées - DMZ [ lien ]), les serveurs externes des entreprises ne sont pas les plus simples à auditer avec des mises à jour qui sont effectuées fréquemment, et peu de services accessibles directement. Les “web vulns” constituent donc la majorité des vulnérabilités recensées sur ces types de serveurs.

La généralisation du Web seconde génération introduit à son tour de nouvelles menaces, avec une multitude de flux (donc d’entrées) entre le client et le serveur. Ces technologies sont souvent tributaires des Web Services [ lien ].

Un article de Shreeraj Shah sur le site Net Square [ lien ] dresse un bilan des vulnérabilités les plus rencontrées avec 10 vecteurs d’attaque :


Failles XSS

Les failles XSS (Cross Site Scripting), longtemps considérées comme anodines, ont été reconsidérées suite à la diffusion, à titre d’exemple, de “Web Worms” non malicieux. L’exemple le plus médiatisé consistait en l’ajout automatique d’un contact inconnu. Après plusieurs jours, un nombre très important de personnes s’étaient vues connaître une nouvelle personne dans leurs réseaux de contacts.

Les applications AJAX axées sur les portails collaboratifs, permettent une grande diffusion des failles XSS. Elles visent particulièrement les sites dynamiques dont l’utilisateur peut interagir avec le contenu (les blogs en font évidemment partie). Un très bon papier au sujet des “Web Worms” est disponible dans les actes de la conférence SSTIC 2005 [ lien ]


Corruption XML

Le formalisme XML [ lien ] est utilisé en général dans des flux HTTP entre le client et le serveur. Un attaquant peut donc envoyer des paquets XML malformés (récursion importante, multiples encapsulations, etc.). Selon les moyens de gestion du format (parsing), le serveur peut alors crasher ou réagir avec un comportement erratique.

De plus, multipliant les flux simultanés, les échanges SOAP [ lien ] peuvent faciliter les dénis de service (DoS - Denial of Service) avec l’établissement de nombreuses connexions “légitimes”.


Exécution malicieuse de code AJAX

Contrairement aux échanges HTTP classiques dont la majeure partie des navigateurs alertent les utilisateurs en cas d’envoi de données (GET/POST classiques), les échanges des applications AJAX ne sont pas annoncés, les envois de données étant très réguliers.


Exploitation de failles via Atom / RSS

Les pages de syndication (ou “Web feeds”) permettent d’annoncer les modifications du contenu d’un site Web. Ils se révèlent très pratiques pour les sites d’informations, sur lesquels les nouveaux articles peuvent être référencés grâce au RSS [ lien ] ou à Atom [ lien ].

La page de syndication de SecuObs est par exemple accessible à l’adresse suivante [ lien ]. Les navigateurs vont donc chercher les mises à jour régulièrement, permettant l’annonce aux lecteurs d’un nouveau contenu sur le site.

L’exploitation d’une page de syndication permettrait à un attaquant d’exploiter de nombreuses machines à l’aide d’une vulnérabilité dans le navigateur ou d’un logiciel tiers des clients vulnérables.


Enumération des actions d’un Web Service

Le WSDL (Web Service Description Langage) [ lien ] permet de lister les formats de messages supportés par un Web Service. L’accès à ces informations permet d’appréhender les fonctions d’une application déportée et peut révéler l’architecture, le fonctionnement propre, ou voire même des crédences.


Rôle inopportun du client

Il est fréquent de trouver des validations ou vérifications effectuées côté client. Si la vérification d’un mot de passe en JavaScript (réalisée côté client) vous parait humoristique, il est néanmoins toujours possible d’assister à de tels scénarios en pratique !

Penser protéger un serveur contre des chaînes malformées via une simple vérification JavaScript est bien entendu illusoire, un attaquant aura vite fait de désactiver la fonction responsable de la vérification afin d’envoyer la chaîne directement au serveur.

Un autre exemple fréquemment rencontré est la vérification du contenu des chaînes afin d’éviter les injections SQL. Elle ne saurait en aucun cas être faite localement.


Routage des messages SOAP

WS-Security (Web Service Security : [ lien ]) définit des méthodes de routage pour les messages SOAP (WS-Routing). Il est possible de définir des chemins de noeuds (i.e. serveurs) par lesquels les messages SOAP transiteront.

Ils sont donc une cible de choix pour des attaquants, qui pourraient ainsi écouter passivement les messages en transit, les modifier à la volée, ou les rejouer (cas le plus simple sur des flux chiffrés).


Manipulation des paramètres

Les paramètres des messages SOAP sont destinés à être utilisés par le serveur. Il est envisageable pour un développeur peu soucieux des aspects “sécurité” d’insérer un paramètre reçu dans une commande shell afin de retourner une partie de la sortie standard mise en forme. Quel serait le comportement du système avec un paramètre “[garbage] ; rm -rf ~/” ?

Il s’agit ici d’un exemple ludique mais bon nombre d’actions peuvent être imaginées sur ces bases. Il s’agit encore une fois de filtrer correctement l’ensemble des entrées, bien que celles-ci deviennent très difficiles à identifier étant donnée l’interaction omniprésente avec les clients.


Injections XPATH

XPath (XML Path Language) [ lien ] permet de récupérer des parties de documents XML en fonction de requêtes, de la même façon qu’une base de données renverrait les informations contenues dans une table suite à une requête SQL par exemple.

Des requêtes XPath sont parfois générées à l’aide de paramètres transmis par un client. Les attaques sur XPath sont similaires sur bien des points aux injections SQL [ lien ] et peuvent mener aux mêmes conséquences : authentifications frauduleuses, récupération d’informations, etc.

Des requêtes XPath permettent également d’écrire dans les fichiers XML... La syntaxe des requêtes XPath sont de la forme : xmlDoc.selectNodes("/utilisateurs/utilisateur[0]")


Utilisation de clients légers (binaires, flash, activeX...)

L’utilisation de Web Services peut s’effectuer au travers de clients légers : applets Java, activeX, flash mais également binaires. Les auteurs de ces solutions doivent impérativement garder à l’esprit que les éléments d’authentification ne peuvent (devrions-nous dire ne doivent) pas être stockées dans ces applications.

Les applications flash sont particulièrement triviale à reverser, tout comme les applets Java (les quelques techniques d’obfuscation ont comme seul but de retarder l’analyse). Les binaires n’en sont pas moins vulnérables.

Des outils tels qu’IDA Pro [ lien ] permettent de simplifier les tâches de Reverse Engineering [ lien ]. Outre l’utilisation de protections applicatives classiques (obfuscation, packers, protections anti-debug...), les règles de bon sens doivent être appliquées.


Si les vulnérabilités logicielles liées à la gestion de la mémoire des processus sont de plus en plus difficiles à exploiter, les “vulnérabilités du Web”, elles, sont relativement triviales.

Pourquoi un attaquant irait développer un “exploit permettant de déclencher un buffer overflow dans la pile, dont les adresses peuvent être rendues aléatoires avec l’utilisation d’ASLR” (Address Space Layout Randomization [ lien ]), alors qu’il existe des moyens équivalents, bien plus accessibles et plus rapides ?

L’engouement pour les “nouvelles technologies” du Web engendre de nouvelles attaques. De nouvelles précautions doivent donc être prises dès le début de la conception de ces applications. Les problèmes de design intrinsèques au fonctionnement de ces applications risquent malheureusement d’être de plus en plus fréquents.