La nécessité d'une approche équilibrée

Introduction

Avec autant de techniques et d'approches pour tester la sécurité des applications web, il peut être difficile de comprendre quelles techniques utiliser ou quand les utiliser. L'expérience montre qu'il n'y a pas de bonne ou de mauvaise réponse à la question de savoir exactement quelles techniques doivent être utilisées pour construire un cadre de test. En fait, toutes les techniques doivent être utilisées pour tester tous les domaines qui doivent être testés.

Bien qu'il soit clair qu'il n'existe pas de technique unique qui puisse être mise en oeuvre pour couvrir efficacement tous les tests de sécurité et garantir que tous les problèmes ont été résolus, de nombreuses entreprises n'adoptent qu'une seule approche. L'approche unique utilisée a historiquement été le test d'intrusion. Les tests d'intrusion, bien qu'utiles, ne peuvent pas résoudre efficacement bon nombre des problèmes qui doivent être testés. C'est tout simplement "trop peu, trop tard" dans le SDLC.

La bonne approche est une approche équilibrée qui comprend plusieurs techniques, des revues manuelles aux tests techniques, en passant par les tests intégrés CI/CD. Une approche équilibrée doit couvrir les tests dans toutes les phases du SDLC. Cette approche tire parti des techniques les plus appropriées disponibles, en fonction de la phase SDLC actuelle.

Bien sûr, il y a des moments et des circonstances où une seule technique est possible. Par exemple, considérons un test d'une application web qui a déjà été créée, mais où la partie test n'a pas accès au code source. Dans ce cas, les tests d'intrusion sont clairement meilleurs que l'absence totale de tests. Cependant, les parties chargées des tests doivent être encouragées à remettre en question les hypothèses, telles que le fait de ne pas avoir accès au code source, et à explorer la possibilité de tests plus complets.

Une approche équilibrée varie en fonction de nombreux facteurs, tels que la maturité du processus de test et la culture d'entreprise. Il est recommandé qu'un cadre de test équilibré ressemble aux représentations illustrées à la figure 3 et à la figure 4. La figure suivante montre une représentation proportionnelle typique superposée au SLDC. Conformément à la recherche et à l'expérience, il est essentiel que les entreprises mettent davantage l'accent sur les premières étapes du développement.

Figure 2-3 : Proportion de l'effort de test dans le SDLC

La figure suivante montre une représentation proportionnelle typique superposée aux techniques de test.

Figure 2-4 : Proportion de l'effort de test en fonction de la technique de test

Remarque concernant les scanners d'applications web

De nombreuses organisations ont commencé à utiliser des scanners d'applications web automatisés. Bien qu'ils aient incontestablement leur place dans un programme de test, certains problèmes fondamentaux doivent être soulignés quant aux raisons pour lesquelles on pense que l'automatisation des tests en boîte noire n'est pas (et ne sera jamais) complètement efficace. Cependant, la mise en évidence de ces problèmes ne doit pas décourager l'utilisation de scanners d'applications web. L'objectif est plutôt de s'assurer que les limitations sont comprises et que les cadres de test sont planifiés de manière appropriée.

Il est utile de comprendre l'efficacité et les limitations des outils automatisés de détection des vulnérabilités. A cette fin, le OWASP Benchmark Project est une suite de tests conçue pour évaluer la vitesse, la couverture et la précision des outils et services automatisés de détection des vulnérabilités logicielles. L'analyse comparative peut aider à tester les capacités de ces outils automatisés et à rendre leur utilité explicite.

Les exemples suivants montrent pourquoi les tests automatisés en boîte noire peuvent ne pas être efficaces.

Exemple 1 : Paramètres magiques

Imaginez une application web simple qui accepte une paire nom-valeur de "magic" puis la valeur. Pour simplifier, la requête GET peut être : https://www.host/application?magic=value

Pour simplifier encore l'exemple, les valeurs dans ce cas ne peuvent être que des caractères ASCII a – z (majuscules ou minuscules) et des entiers 0 – 9.

Les concepteurs de cette application ont créé une porte dérobée administrative pendant les tests, mais l'ont obscurcie pour empêcher l'observateur occasionnel de la découvrir. En soumettant la valeur sf8g7sfjdsurtsdieerwqredsgnfg8d (30 caractères), l'utilisateur sera alors connecté et se verra présenter un écran administratif avec un contrôle total de l'application. La requête HTTP est maintenant : https://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d

Etant donné que tous les autres paramètres étaient de simples champs de deux et trois caractères, il n'est pas possible de commencer à deviner des combinaisons d'environ 28 caractères. Un scanner d'applications web devra forcer brutalement (ou deviner) tout l'espace de clés de 30 caractères. Cela représente jusqu'à 30^28 permutations, soit des billions de requêtes HTTP. C'est un électron dans une botte de foin numérique.

Le code de cet exemple de vérification de paramètre magique peut ressembler à ce qui suit :

public void doPost( HttpServletRequest request, HttpServletResponse response) {
    String magic = "sf8g7sfjdsurtsdieerwqredsgnfg8d";
    boolean admin = magic.equals( request.getParameter("magic"));
    if (admin) doAdmin( request, response);
    else … // normal processing
}

En regardant le code, la vulnérabilité saute pratiquement aux yeux comme un problème potentiel.

Exemple 2 : Mauvaise cryptographie

La cryptographie est largement utilisée dans les applications web. Imaginez qu'un développeur ait décidé d'écrire un algorithme de cryptographie simple pour connecter automatiquement un utilisateur du site A au site B. Dans sa sagesse, le développeur décide que si un utilisateur est connecté au site A, il générera une clé en utilisant une fonction de hachage MD5 qui comprend : Hash { nom d'utilisateur : date }.

Lorsqu'un utilisateur est transféré vers le site B, il enverra la clé dans la chaîne de requête au site B dans une redirection HTTP. Le site B calcule indépendamment le hachage et le compare au hachage transmis dans la requête. S'ils correspondent, le site B connecte l'utilisateur en tant qu'utilisateur qu'il prétend être.

Au fur et à mesure que le schéma est expliqué, les insuffisances peuvent être déterminées. Quiconque découvre le schéma (ou se fait dire comment il fonctionne, ou télécharge les informations de Bugtraq) peut se connecter en tant que n'importe quel utilisateur. Une inspection manuelle, telle qu'une revue ou une inspection du code, aurait rapidement découvert ce problème de sécurité. Un scanner d'applications web en boîte noire n'aurait pas découvert la vulnérabilité. Il aurait vu un hachage de 128 bits qui changeait avec chaque utilisateur et, de par la nature des fonctions de hachage, ne changeait d'aucune manière prévisible.

Remarque concernant les outils d'analyse statique du code source

De nombreuses organisations ont commencé à utiliser des scanners de code source statiques. Bien qu'ils aient incontestablement leur place dans un programme de test complet, il est nécessaire de souligner certains problèmes fondamentaux expliquant pourquoi cette approche n'est pas efficace lorsqu'elle est utilisée seule. L'analyse statique du code source seule ne peut pas identifier les problèmes dus à des défauts de conception, car elle ne peut pas comprendre le contexte dans lequel le code est construit. Les outils d'analyse du code source sont utiles pour déterminer les problèmes de sécurité dus à des erreurs de codage, mais un effort manuel important est nécessaire pour valider les résultats.