Au programme de ce premier rendez-vous français de l'[OWASP | http://www.owasp.org/index.php/France], l’association a élaboré un menu équilibré en deux présentations, technique pour l’une (les attaques contre XML) et organisationnelle pour l’autre (Open SAMM, un modèle d’assurance sécurité plus simple à mettre en oeuvre que nous abordons par ailleurs).

Sur le front de XML, c’est Renaud Bidou, Directeur technique et R&D du français Deny All, qui est venu s’y coller. Sa présentation a permis de faire le point des différents vecteurs d’attaque susceptibles de viser les applications et les infrastructures XML (les front-ends et les parsers).

Pour l’essentiel, XML est soumis aux mêmes risques que les applications web, à tel point que Renaud Bidou a pu mapper chaque point du Top 10 de l’OWASP avec une attaque équivalente contre XML.

Dans le détail, les attaques contre XML conduisent pour beaucoup à du déni de service (très simple à mettre à oeuvre) et à des injections similaires à ce que l’on connaît avec SQL, avec en outre quelques opportunités de divulgation d’information ou de rejeu des transactions.

En ce qui concerne les dénis de service, Renaud Bidou a noté :

Le déni simple : un document malveillant créé avec, par exemple, une profondeur de 1000 noeuds, pourra mettre à genoux un parser (essentiellement un parser de type DOM, qui charge toute la structure du document en mémoire afin de l’analyser dans un contexte global).

Le déni de service SOAP : si le front-end web est correctement dimensionné au niveau des accès HTTP, ce n’est pas toujours le cas du listener chargé de recevoir les requêtes SOAP, qui devient alors un goulot d’étranglement potentiel.

Encryption Key Loop : le scénario est enfantin : « La clé A est chiffrée par la clé B », puis au sein du même document, « La clé B est chiffrée par la clé A » : le document force alors le parser dans une boucle sans fin.

Sur le front des injections, plusieurs attaques sont également envisageables :

Injection XML : un attaquant sera en mesure d’ajouter ses propres balises à un document XML si ce dernier est créé (entièrement ou en partie) à partir de ses entrées mal filtrées. Les parsers de type SAX (qui n’explorent le document que de manière séquentielle ligne par ligne) sont les plus vulnérables ici.

Injection xPath : XPath offre un langage de requête afin d’extraire de l’information d’une structure XML (accéder à tel ou tel noeud du document, etc…). Il est pour l’essentiel vulnérable aux mêmes risques que l’est SQL dans le monde web traditionnel. Mais contrairement à SQL où l’attaquant pourra éventuellement être limité en fonction des droits de l’application qu’il exploite, une injection XML réussie donne accès à la totalité du contenu du document visé.

Injection via CDATA : les blocs CDATA permettent de passer des contenus qui ne seront pas interprétés par le parser. Mais l’approche permet également de « casser » une chaîne qui serait sinon interceptée par un pare-feu web / IDS traditionnel.

Dans le domaine de la divulgation de l’information, plusieurs techniques sont susceptibles de permettre à un attaquant d’afficher le contenu complet d’un document généré à partir d’une entrée utilisateur. Renaud Bidou a notamment détaillé celle du XML Document Dump : l’utilisation astucieuse du pipe ( | ) et d’un wildcard (*) afin d’afficher la totalité du document à la suite d’une injection XML réussie.

Enfin, en guise de bonus, deux autres attaques : le rejeu de message SOAP (« Les messages n’ont aucune relation entre eux. Si l’application ne se charge pas du contrôle, il est très facile de rejouer, par exemple, une main gagnante au poker », explique Renaud Bidou) et enfin l’exploitation de la transformation XSLT : la technique permet, au moment de la vérification d’une signature, de faire exécuter une commande système au serveur qui valide la signature.

Aucune de ces attaques n’est franchement révolutionnaire. Mais leur application à XML leur offre un terrain quasi-vierge qui n’a, encore, que peu conscience de sa vulnérabilité contrairement au monde web.

Enfin, aucune solution n’a été évoquée durant cette présentation, mais elles apparaissent évidentes à la lecture de ce florilège : le filtrage des entrées est, dans le monde XML, tout aussi essentiel que dans le web. Hélas, la bataille étant déjà loin d’être gagnée sur le front du web, il n’est pas certain que le message passe mieux du côté XML…