Une faille XSS sur le réseau Wicri

Suite à la détection d'une faille de type Cross-site scripting le domaine lorexplor.istex.fr avait été confiné.

Après analyse et traitement, le réseau est redevenu nouveau accessible.

Puis, pour améliorer la fiabilité, un nouveau domaine a été ouvert.

Voici quelques explications.

La faille dans les serveurs d'exploration

La faille a été repérée par une organisation nommée open bug bounty. Elle injecte des données potentiellement dangereuses dans les url d'un site web et analyse les réponses du site pour voir si les données ont été nettoyées avant utilisation.

Pour construire des données dangereuses, il suffit d'y insérer un code javascript. Si le serveur ne filtre pas les données à la lecture, celles-ci peuvent produire des actions, sur le site de l'utilisateur.

Dans notre cas, toutes les procédures d'appel avec paramètres sur les serveurs apparaissaient comme vulnérables. Par exemple une recherche dans un index des villes contient dex paramètres : le code index et la clé.

https://lorexplor.istex.fr/Wicri/Sante/ ... /indexItem.php?index=AffVille.i&key=Montpellier

En cas d'anomalie (clé non trouvée), par exemple « MonTrucPellier » au lieu de Montpellier, le serveur d'exploration renvoie :

Mont-Saint-Aignan < **** key : MontTrucPellier not founded **** < Montfermeil

Si l'on insère un code javascript celui ci sera alors interprété lors de la réception sur l'ordinateur de l'utilisateur. Par exemple le paramètre

Mont<script>alert('bonjour')</script>pellier

provoquera l'impression d'un bouton imprévu sur l'écran de l'usager.

Les conséquences de cette faille

Ce type de faille peut être redoutable si des données altérées dans des systèmes internes d'information (à base de javascript par exemple).

Dans notre cas les données sont simplement renvoyées vers le site émetteur. Il faudrait donc qu'il s'injecte délibérément ce type de virus. On peut aussi imaginer des mécanismes plus complexes avec un navigateur infecté qui injecte au hasard des perturbations dans tous les envois de l'utilisateur. Mais cela signifie que l'utilisateur a laissé s'installer un mécanisme pervers.

Mais les détecteurs de failles ne peuvent pas évaluer leur dangerosité potentielle. La coupure de notre domaine, avant analyse, était cohérente.

Dans notre cas cette faille avait cependant un aspect critique. En effet, dans les serveurs d'exploration, toutes les procédures PHP avec paramètres contenaient cette faille. Avec 200 plateformes pouvant contenir 20 serveurs et des dizaines de procédures PHP, nous avions en fait 40.000 failles détectables. Autrement dit, une faille réelle devenait invisible.

Nous avons donc décidé dans un premier temps de rendre inaccessibles tous les serveurs d'exploration. Puis nous avons modifié le logiciel de génération des serveurs. Les données sont automatiquement nettoyées lors de leur lecture.

En revanche toutes les interfaces doivent être recompilées. Or les 200 serveurs ont été produits par des procédures en constante amélioration. La remise en marche des anciens serveurs peut donc s'avérer complexe. La remise en état doit donc s'étaler sur une longue période.