Documentation<Précédent | Table des matières | Suivant>
11.2.4. Évaluation de la demande
Alors que la plupart des évaluations ont une large portée, une évaluation d'application est une spécialité qui se concentre étroitement sur une seule application. Ces types d'évaluations sont de plus en plus courants en raison de la complexité des applications critiques utilisées par les organisations, dont beaucoup sont conçues en interne. Une évaluation de la demande est généralement ajoutée à une évaluation plus large, au besoin. Les demandes qui peuvent être évaluées de cette manière comprennent, sans s'y limiter :
• Applications Web : surface d'attaque externe la plus courante, les applications Web constituent de bonnes cibles simplement parce qu'elles sont accessibles. Souvent, les évaluations standard trouveront des problèmes de base dans les applications Web, mais un examen plus ciblé vaut souvent le temps pour identifier les problèmes liés au flux de travail de l'application. Les kali-linux-web metapackage a un certain nombre d'outils pour aider à ces évaluations.
• Applications de bureau compilées : le logiciel serveur n'est pas la seule cible ; les applications de bureau constituent également une merveilleuse surface d'attaque. Au cours des années passées, de nombreuses applications de bureau telles que
21http://docs.kali.org/kali-dojo/02-mastering-live-build 22https://www.offensive-security.com/kali-linux/kali-rolling-iso-of-doom/ 23http://docs.kali.org/development/live-build-a-custom-kali-iso 24https://www.offensive-security.com/kali-linux/kali-linux-recipes/
Les lecteurs PDF ou les programmes vidéo basés sur le Web étaient très ciblés, les forçant à mûrir. Cependant, il existe encore un grand nombre d'applications de bureau qui sont une mine de vulnérabilités lorsqu'elles sont correctement examinées.
• Applications mobiles : à mesure que les appareils mobiles deviennent plus populaires, les applications mobiles deviendront de plus en plus une surface d'attaque standard dans de nombreuses évaluations. Il s'agit d'une cible qui évolue rapidement et les méthodologies sont encore en train de mûrir dans ce domaine, conduisant à de nouveaux développements pratiquement chaque semaine. Les outils liés à l'analyse des applications mobiles se trouvent dans la Ingénierie inverse catégorie de menu.
Les évaluations des candidatures peuvent être menées de différentes manières. À titre d'exemple simple, un outil automatisé spécifique à l'application peut être exécuté sur l'application pour tenter d'identifier les problèmes potentiels. Ces outils utiliseront une logique spécifique à l'application pour tenter d'identifier les problèmes inconnus plutôt que de simplement dépendre d'un ensemble de signatures connues. Ces outils doivent avoir une compréhension intégrée du comportement de l'application. Un exemple courant de ceci serait un scanner de vulnérabilité d'application Web tel que Burp Suite25, dirigé contre une application qui identifie d'abord divers champs d'entrée, puis envoie des attaques d'injection SQL courantes vers ces champs tout en surveillant la réponse de l'application pour les indications d'une attaque réussie.
Dans un scénario plus complexe, une évaluation d'application peut être menée de manière interactive dans un
manière boîte noire ou boîte blanche.
• Évaluation de la boîte noire : l'outil (ou l'évaluateur) interagit avec l'application sans aucune connaissance ou accès particulier au-delà de celui d'un utilisateur standard. Par exemple, dans le cas d'une application Web, l'évaluateur peut n'avoir accès qu'aux fonctions et fonctionnalités disponibles pour un utilisateur qui ne s'est pas connecté au système. Tous les comptes d'utilisateurs utilisés seraient ceux où un utilisateur général peut auto-enregistrer le compte. Cela empêcherait l'attaquant de pouvoir examiner toute fonctionnalité qui n'est disponible que pour les utilisateurs qui doivent être créés par un administrateur.
• Évaluation boîte blanche : L'outil (ou l'évaluateur) aura souvent un accès complet au code source, un accès administratif à la plate-forme exécutant l'application, etc. Cela garantit qu'un examen complet et complet de toutes les fonctionnalités de l'application est effectué, quel que soit l'emplacement de cette fonctionnalité dans l'application. Le compromis avec cela est que l'évaluation n'est en aucun cas une simulation d'une activité malveillante réelle.
Il y a évidemment des nuances de gris entre les deux. En règle générale, le facteur décisif est l'objectif de l'évaluation. Si l'objectif est d'identifier ce qui se passerait si l'application faisait l'objet d'une attaque externe ciblée, une évaluation en boîte noire serait probablement la meilleure. Si l'objectif est d'identifier et d'éliminer autant de problèmes de sécurité que possible dans un laps de temps relativement court, une approche boîte blanche peut être plus efficace.
25https://portswigger.net/burp/
Dans d'autres cas, une approche hybride peut être adoptée lorsque l'évaluateur n'a pas un accès complet au code source de l'application de la plate-forme exécutant l'application, mais les comptes d'utilisateurs sont fournis par un administrateur pour permettre l'accès à autant de fonctionnalités d'application que possible.
Kali est une plate-forme idéale pour toutes sortes d'évaluations d'applications. Sur une installation par défaut, une gamme de différents scanners spécifiques à l'application est disponible. Pour des évaluations plus avancées, il existe une gamme d'outils, d'éditeurs de sources et d'environnements de script. Vous pouvez trouver l'application Web26 et rétro-ingénierie27 sections des outils Kali28 site Web utile.