[STANDARD] OWASP - Episode 6

Ce nouvel épisode est la suite de notre étude de la nouvelle version de la norme OWASP. Le but est de pratiquer les tests d'intrusion de manière méthodologique et aussi, de donner de nouvelles idées. Particulièrement, ce sixième épisode s'attache aux spécificités métiers de l'application cible.

1 - Avant-propos

Le sixième épisode que nous traitons ici représente le cinquième chapitre de tests actifs après un premier chapitre de découverte. Dans la norme OWASP v3, il s'agit du chapitre 4.7 relatif aux tests de l'application WEB cible et notamment les fonctions métiers qui peuvent être sujettes à des problèmes de sécurité.


2 - Phase de tests actifs 5 - tests sur les fonctionnalités métiers

2.1 - BL-001 : Tests des fonctionnalités métiers

Puisque chaque application est différentes, il n'existe pas de tests particuliers que nous pouvons fournir de manière certaine. Cependant, une démarche précise est proposée pour couvrir au mieux l'application et tenter de trouver les failles de sécurité éventuelles.

1/ Comprendre l'application :

Il s'agit ici de connaître les possibilités offertes par l'application. Pour cela, l'auditeur pourra s'aider de la documentation disponible (test en boîte blanche) et de sa propre exploration de l'application en navigant sur les différentes pages. Il est important de noter à cette étape :

• les limites rencontrées (que nous essaierons ensuite de contourner) ;
• les différentes manières de réaliser certaines actions (notamment les actions les plus importantes).

Cette première étape nous fournit un aperçu de l'application et nos premières pistes.

2/ Etablir les scénario de tests :

Nous prenons ici en compte tous les cas possibles que nous devrons croiser entre eux pour être exhaustif. Les cas en questions sont :

• les fonctionnalités principales (recherche d'un produit, commande d'un produit, ...) ;
• le circuit de validation d'une action (ex : de la commande à la validation d'un achat) ;
• les différents rôles intervenant sur l'application (e.g. de l'administrateur au directeur) ;
• les différents services (service IT, marketing, ...) ;
• les droits et privilèges accordés à chacun ... et à vérifier.

Ces cinq éléments doivent nous permettre de constituer un tableau avec l'ensemble des actions permises pour chaque niveau d'utilisateur.

3/ Préparation des tests

Suite à l'étape précédente, nous devons déterminer ici le ou les test(s) à réaliser en conséquence pour nous assurer que l'application est correctement cloisonnée par type d'intervenant et par action.

Par conséquent, à l'issue de cette troisième étape, un nouveau tableau sera créé contenant les tests résultants de l'étape précédente. Nous nous appuierons donc largement sur le précédent tableau.

4/ Obtention des pré-requis

Maintenant que les tests à réaliser sont connus, il est temps de demander au client les ressources nécessaires à leur réalisation. La plupart du temps, il s'agira de comptes avec des niveaux de privilèges différents. Aussi, il peut s'agir d'URL d'administration pour les comptes les plus privilégiés. Il est préférable de commencer avec un compte standard et de demander les ressources au fur et à mesure pour ne pas influencer les tests.
Par exemple, est-il possible de trouver et d'accéder à l'interface d'administration avec un compte standard sans information préalable ?

5/ Exécution des tests

L'exécution des tests issus du tableau déterminé en 3/ considérera la plupart du temps :

• l'analyse des requêtes HTTP ;
• les protections apportées (ou non) aux flux et données (e.g . chiffrement) ;
• la récupération d'erreur lorsque nous testons des valeurs limites ou hors range (ex : valeur négative ou très importante pour une somme) ;
• la recherche d'information cachée dans le traitement des actions;
• la modification de données en cours d'action ;
• le contournement d'une ou plusieurs étapes de validation ;
• etc.

A vous de jouer !


La suite au prochain épisode.