Un test de sécurité applicatif vise à évaluer le niveau de sécurité d’une application. Il peut s’agir de tests applicatifs sur une application web, ou sur une application riche (« lourde » en modèle client / serveur par exemple). Ces tests sont la plupart du temps réalisés en « boite noire », c’est-à-dire sans informations préalables ou accès au code source.

Généralement, ce type de test est composé de deux phases :

• Le test dit « en boite noire » : Sans aucun accès au code source, sans identifiants, sans informations techniques sur le logiciel

• Le test dit « en boite grise » : Ici, les experts disposent d’un compte utilisateur (non administrateur) sur l’application afin de vérifier la sécurité du point de vue d’un utilisateur légitime disposant d’un compte sur l’application.
  
  En une phrase : vérifier si un logiciel contient des failles ou erreurs de traitements

Les tests menés, les techniques utilisées et le déroulement des phases sont différents selon qu’il s’agisse d’une application web, ou d’une application classique, aussi appelée application lourde. Ces tests sont souvent demandés avant la mise en production d’un applicatif devant respecter la norme PCI DSS ou dans le cadre d’une certification ISO 27001.

Test d’application web : les grandes familles de vulnérabilités techniques recherchées seront par exemple des XSS, des injections SQL, des CSRF, des remote/local file includes, attaques sur les sessions et cookies, ainsi que toutes les vulnérabilités spécifiques à une technologie, comme les problématiques liées au « request validation » ou encore à la gestion des paramètres « ViewState » du langage .NET.

Audit d’application : Les vulnérabilités propres à ce type d’application sont en général : heap overflow, stack overflow, format string, race condition etc. Ici aussi les spécificités des technologies employées seront prises en compte.

Dans les deux cas , les vulnérabilités génériques seront testées, ainsi (éventuellement) que les autres éléments de l’écosystème applicatif.

Cette catégorie englobe, par exemple, les bugs dits « de logique » (erreur dans la conception dans l’algorithme), les bugs liés à l’authentification et la gestion de privilèges, ainsi que, dans la mesure où cela reste cohérent, les vulnérabilités liées aux attaques par ingénierie sociale, bien que ces derniers soient souvent liés à des vulnérabilités techniques.

Il existe aussi une autre catégorie de tests applicatifs : les tests en boite blanche. A contrario du test en boite noire, il se déroule de manière coopérative et repose sur un audit du code source. Lorsque l’on procède à un audit de code source, deux solutions sont possibles : l’audit manuel ou l’analyse statique.

En fonction du volume, de la criticité et du contexte de l’application, nous pourrons vous aider à qualifier le type de test le plus adapté à vos besoins.

Les audits, comme la plupart de nos tests, se concluent par la création et la remise d’un rapport technique de test, qui contient à la fois :

• Les vulnérabilités détectées
• Des moyens de reproduire (lorsque cela est possible) nos attaques

Des préconisations pour chaque type de vulnérabilité détetectée