Services Web : comment la recherche automatique de vulnérabilités peut introduire des risques

Automatiser la recherche de vulnérabilités Web

En matière de recherche de vulnérabilités Web et de test d’intrusion, il n’y a absolument aucun problème pour automatiser largement le processus. Toutefois, avec les complexités des environnements réseau modernes, nombre de professionnels de l’IT et de la sécurité se sont habitués à pouvoir cliquer sur un bouton et à tout automatiser.

Je sais qu’une journée compte un nombre d’heures limité, mais un test de sécurité Web correct va au-delà du simple pointage d’une URL dans un scanner automatisé. Il y a tant de nuances dans la réalisation d’un scan que seul un professionnel expérimenté saura comment les exécuter de manière à obtenir les meilleurs résultats.

Il y a une centaine d’exemple dont certains sous-estiment ces subtilités, mais je vais me concentrer sur un domaine principal : il est nécessaire de connaître son scanner et de savoir quoi en attendre. A défaut de quoi, vous n’obtiendrez pas les résultats souhaités.

L’a priori général est que les utilisateurs finaux de ces outils savent exactement comment les employer dès le départ. Bien sûr, nombre d’éditeurs ont fait un excellent travail pour affiner les interfaces, mais cela ne suffit pas.

Par exemple, quelle politique de scan utilisez-vous ? Demandez-vous à chercher tout, ou juste les vulnérabilités à haut risque ? Et si vous vous limitez à ces dernières, vous passez probablement à côté d’une multitude d’opportunités potentielles de découvrir des failles additionnelles.

Mais peut-être ne pouvez-vous pas lancer certaines vérifications complètes, comme celles qui peuvent affecter un environnement de production, tout particulièrement pour les tests authentifiés ?

Justement, pour ces derniers, les lancez-vous seulement comme un tiers externe non authentifié, ou les exécutez-vous comme un utilisateur de confiance du système ? Si vous voulez obtenir une vision juste de la situation, vous devez faire les deux.

Toutefois, vous avez également besoin de savoir quelles politiques de scan sont appropriées pour le test authentifié et lesquelles sont pertinentes pour le test non authentifié.

Avec la plupart des scanners de vulnérabilités, je sélectionne généralement la politique qui vérifie tout, dans la perspective d’un tiers non authentifié. Toutefois, compte tenu des workflows et des spécificités de nombreuses applications - combinés aux difficultés qu’ont nombre de scanners à s’authentifier et à conserver une session ouverte sur les applications étudiées - il est souvent nécessaire de réaliser des scans moins complets pour les tests authentifiés. Sinon, le scanner risque de tourner en boucle pendant des jours entiers sans jamais finaliser ses actions. C’est une chose que l’on apprend avec la pratique.

Les bonnes pratiques

Qui plus est, certains scanners sont meilleurs que d’autres dans certains domaines.

Par exemple, l’un de ceux que j’utilise est excellent pour la détection de vulnérabilités par scripting inter-sites (CSS). D’autres sont remarquables pour relever les risques d’injection SQL. Mais l’un des scanners les plus populaires du marché, que j’ai utilisé pendant des années, n’en a jamais détecté une seule entre mes mains, alors que d’autres les trouvaient.

J’ai utilisé nombre de scanners de vulnérabilités Web au fil des ans et, dans de nombreux cas, je n’ai pas obtenu ce pour quoi j’ai payé.

En fait, la plupart des scanners tendent à trouver leurs propres vulnérabilités. En d’autres termes, différents scanners trouvent souvent des ensembles de failles complètement différents. J’ai appris il y a longtemps qu’il est nécessaire de lancer plusieurs scanners sur les applications Web que l’on teste pour espérer disposer d’une visibilité complète.

Il existe d’autres nuances, comme le nombre de requêtes concurrentes pouvant être lancées par le scanner : il peut affecter les résultats. Cela vaut notamment pour les applications intégrant des formulaires de contact – ou autres – non protégés par des Captchas. C’est un bon moyen de créer une situation de déni de service sur son environnement de production

Test sur environnement de production vs test sur environnement de développement

Et c’est là que l’on touche aux différences entre test sur l’environnement de production, et test sur celui de développement.

Dans le premier cas, il faut faire attention à ne pas faire tomber le système, ni à en polluer les bases de données avec les entrées du scanner.

Dans le second cas, il est difficile de s’assurer de disposer d’une parfaite réflexion de l’environnement de production. Et pourtant, c’est bien de cela qu’il s’agit : vérifier l’absence de failles affectant les systèmes exposés au public.

Ces questions – et d’autres – doivent être traitées durant la phase de détermination du périmètre de test.

Il y a beaucoup de choses à apprendre dans le domaine de la recherche de vulnérabilités Web. A commencer par connaître ses outils par le menu, connaître leurs limitations, et se rappeler qu’un seul scanner ne suffit pas - et qu’un simple scanner de vulnérabilités réseau, sans recours à un scanner dédié aux vulnérabilités Web, est insuffisant.

Ceci dit, même avec des scanners de vulnérabilités Web automatisés et dédiés, un autre point est nécessaire. Il faut avoir l’état d’esprit d’un pirate pour trouver les bonnes vulnérabilités.

Seuls, ces outils trouveront, en moyenne, 50 à 60 % des vulnérabilités que je documenterais dans un rapport d’évaluation de sécurité Web. L’analyse manuelle, avec un bon vieux navigateur Web, un proxy http, et des outils complémentaires, est nécessaire pour trouver toutes les autres failles dans une application.

Conclusion

Si vous êtes RSSI, administrateur ou auditeur de sécurité, comment faites-vous la part des choses entre test manuel et automatique ? Comment pouvez-vous dire que vous avez réalisé une analyse raisonnable de votre environnement Web ? Et que vous disposez d’une photographie juste de la situation ?

Tant que vous n’avez pas traité les points évoqués plus haut, vous ne pouvez tout simplement pas le dire.

Ne prenez pas le test d’intrusion et la recherche de vulnérabilités Web à la légère. Et n’estimez jamais que de simples scans de vulnérabilités sont suffisants parce qu’ils ne sont pas la même chose que des tests lancés contre des hôtes réseau.

Cherchez constamment de nouvelles informations, de nouveaux outils, de nouvelles techniques. Cela aidera à améliorer votre programme de sécurité global, tout en assurant que votre organisation ne fera pas les gros titres de la presse à cause de vulnérabilités Web non détectées et d’une faille qui aurait pu (et dû) être traitée.