Documentation<Précédent | Table des matières | Suivant>
11.2. Types d'évaluations
Maintenant que vous vous êtes assuré que votre environnement Kali est prêt, la prochaine étape consiste à définir exactement le type d'évaluation que vous effectuez. Au plus haut niveau, on peut décrire quatre types d'évaluations : une évaluation de la vulnérabilité, un test de conformité, un test de pénétration traditionnel et un évaluation de la demande. Un engagement peut impliquer divers éléments de chaque type d'évaluation, mais cela vaut la peine de les décrire en détail et d'expliquer leur pertinence pour votre version et votre environnement Kali Linux.
Avant d'approfondir les différents types d'évaluations, il est important de noter d'abord la différence entre une vulnérabilité et un exploit.
A vulnérabilité est défini comme une faille qui, une fois exploitée, compromettra la confidentialité, l'intégrité ou la disponibilité d'un système d'information. Il existe de nombreux types de vulnérabilités différentes, notamment :
• Inclusion de fichiers : vulnérabilités d'inclusion de fichiers1 dans les applications Web vous permettent de comprennent le contenu d'un fichier local ou distant dans le calcul d'un programme. Par exemple, une application Web peut avoir une fonction « Message du jour » qui lit le contenu d'un fichier et l'inclut dans la page Web pour l'afficher à l'utilisateur. Lorsque ce type de fonctionnalité est mal programmé, il peut permettre à un attaquant de modifier sa requête web pour forcer le site à inclure le contenu d'un fichier de son choix.
• Injection SQL : une injection SQL2 L'attaque est une attaque où les routines de validation d'entrée pour le programme sont contournées, permettant à un attaquant de fournir des commandes SQL pour que le programme ciblé s'exécute. Il s'agit d'une forme d'exécution de commande qui peut entraîner des problèmes de sécurité potentiels.
• Débordement de tampon : un débordement de tampon3 est une vulnérabilité qui contourne les routines de validation d'entrée pour écrire des données dans la mémoire adjacente d'un tampon. Dans certains cas, cet emplacement de mémoire adjacent peut être critique pour le fonctionnement du programme ciblé et le contrôle de l'exécution du code peut être obtenu par une manipulation soigneuse des données de mémoire écrasées.
• Conditions de course : une condition de course4 est une vulnérabilité qui tire parti des dépendances temporelles dans un programme. Dans certains cas, le flux de travail d'un programme dépend d'une séquence spécifique d'événements à se produire. Si vous pouvez modifier cette séquence d'événements, cela peut conduire à une vulnérabilité.
An exploiter, d'autre part, est un logiciel qui, lorsqu'il est utilisé, tire parti d'une vulnérabilité spécifique, bien que toutes les vulnérabilités ne soient pas exploitables. Étant donné qu'un exploit doit modifier un processus en cours d'exécution, le forçant à effectuer une action involontaire, la création d'exploits peut être complexe. En outre, il existe un certain nombre de technologies anti-exploit dans les plates-formes informatiques modernes qui ont été
1https://en.wikipedia.org/wiki/File_inclusion_vulnerability 2https://en.wikipedia.org/wiki/SQL_injection 3https://en.wikipedia.org/wiki/Buffer_overflow 4https://en.wikipedia.org/wiki/Race_condition
conçu pour rendre plus difficile l'exploitation des vulnérabilités, telles que la prévention de l'exécution des données5 (DEP) et randomisation de la disposition de l'espace d'adressage6 (ASLR). Cependant, juste parce qu'il n'y a pas d'exploit connu publiquement pour une vulnérabilité spécifique, cela ne signifie pas qu'il n'en existe pas (ou qu'il ne peut pas être créé). Par exemple, de nombreuses organisations vendent des exploits commercialisés qui ne sont jamais rendus publics, de sorte que toutes les vulnérabilités doivent être traitées comme potentiellement exploitables.