Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Tests de pénétration des applications Web Presque toutes les interactions des u

Tests de pénétration des applications Web Presque toutes les interactions des utilisateurs sur Internet se font par le biais d’applications Web. Même lorsque les internautes n’achètent pas de produits via une vitrine virtuelle, ils interagissent toujours avec du contenu qui est presque 100% dynamique. Le contenu qu’ils voient est basé sur leurs habitudes de navigation et leur historique ainsi que sur la publicité ciblée. Ils magasinent en ligne, interagissent avec d’autres personnes via des sites de réseaux sociaux et cherchent des solutions aux problèmes en ligne. Cette quantité d’activité en ligne crée un environnement très vaste et riche en cibles pour les utilisateurs malveillants qui souhaitent voler les informations ou les revenus durement gagnés d’autres utilisateurs. Que l’application soit accessible sur Internet ou interne à votre organisation cible, il y a de fortes chances que dans un engagement de test de pénétration donné, vous soyez invité à tester au moins une application Web. Nous aborderons certains outils de test des applications Web ainsi que certaines techniques que les attaquants utilisent pour exploiter les failles de sécurité et tirer parti des utilisateurs d’applications et des services principaux. NOTE En tant que tel, nous nous concentrerons sur seulement trois des principaux chemins d’attaque qui peuvent être utilisés pour aider à prendre pied dans un environnement : les attaques par injection, les attaques de script intersites et les attaques de falsification de requête intersites. Vulnérabilités des applications Web Les erreurs sont inhérentes à tout ce que les programmeurs créent. Et malgré tous leurs efforts pour suivre un cycle de vie de développement sécurisé et les meilleures pratiques de codage, parfois des vulnérabilités persistent dans les technologies elles-mêmes ou dans la façon dont elles sont censées fonctionner. Les applications Web ne sont pas différentes. En fait, en raison de leur omniprésence dans nos vies et de leur complexité croissante, ils offrent sans doute la plus grande surface d’attaque dans les environnements d’exploitation d’aujourd’hui. Et il n’y a pas que les applications serveur qui peuvent être attaquées. Des vulnérabilités peuvent exister dans une application qui permettent à des attaquants de cibler et d’exploiter les systèmes côté client utilisés pour afficher les applications Web. Nous examinerons les différences entre les attaques de script inter-sites (XSS) et les attaques csrf (cross-site request forgery), qui sont toutes deux utilisées pour tirer parti des systèmes côté client, ainsi que les attaques par injection, qui sont conçues pour exploiter les vulnérabilités dans la façon dont une application Web interagit avec les bases de données principales et les systèmes d’exploitation. Outils du commerce Tout comme pour l’analyse du réseau et l’évaluation des vulnérabilités, il existe un certain nombre de produits qui peuvent aider à automatiser le processus de test des applications Web, même en cas de chevauchement. Par exemple, Nessus peut être configuré pour tester les applications Web pour les faiblesses connues. Toutefois, étant donné que les applications Web nécessitent généralement un engagement actif avec les utilisateurs, certaines tâches de test automatisé peuvent entraîner des problèmes avec les applications Web. De même, vous devez également prendre soin de valider les résultats découverts par les produits automatisés. Cette section présente plusieurs analyseurs et proxys de vulnérabilité d’applications Web. Les analyseurs de vulnérabilités d’applications Web ne sont rien de plus que des outils d’automatisation spécialisés utilisés pour trouver des vulnérabilités connues. Les proxys,dans ce cas, font référence aux applications que vous pouvez utiliser pour intercepter et modifier le trafic Web entre votre navigateur client et le serveur traitant les données, essentiellement vous effectuez une attaque de l’intercepteur contre vous-même afin d’évaluer comment les navigateurs Web et les serveurs d’applications interagissent avec les données. Nikto Nikto (https://cirt.net/Nikto2) est un outil denumérisation d’applications Web open source qui existe depuis 2001. Il est écrit par Chris Sullo et David Lodge, et est inclus dans Kali Linux par défaut. Comme pour les scanners de vulnérabilité réseau, Nikto s’appuie sur une « base de données » interne de vulnérabilités connues et de mauvaises configurations pour comparer les résultats. Il prend en charge le proxy, ce qui signifie que vous pouvez exécuter l’outil via un proxy et qu’il peut être configuré pour s’authentifier auprès des serveurs Web à l’aide de l’authentification de base ou NTLM. Les testeurs peuvent également effectuer des attaques de devinettes de mot de passe et de sous-domaine contre des applications Web à l’aide de Nikto. Comme la plupart des scanners d’applications Web, Nikto n’est pas un outil « furtif ». Toute organisation avec la journalisation d’application minimale activée verra l’activité de Nikto. L’outil dispose d’une page de travail et vous pouvez également imprimer des options à l’aide de la commande nikto -help. Le tableau 3-14 énumère certaines des options les plus utiles. Tableau 3-14 Options de Nikto Vous pouvez effectuer une analyse rapide de Nikto sur votre machine virtuelle CentOS cible avec le conteneur docker DVWA en cours d’exécution, conformément à la configuration du laboratoire d’installation de l’enivrement du LAB, à l’aide de la commande nikto -host 192.168.1.15 -port 80. Comme le montre la figure 3-43, la sortie répertorie les vulnérabilités connues et les erreurs de configuration, ainsi que les éléments qui nécessitent une enquête plus approfondie. Par exemple, vous devez déterminer s’il y avait quelque chose d’intéressant dans le sous- répertoire /docs. Il répertorie également les vulnérabilités telles qu’elles sont indexées dans la base de données sur les vulnérabilités open source (OSVDB). Si des éléments trouvés avec Nikto arrivent à votre rapport final, vous devez vous assurer de traduire ces résultats dans un format que votre client peut utiliser pour la correction ou le suivi. Par exemple, OSVDB-3268 Directory Indexing peut être noté comme CWE-548, Information Exposure Through Directory Listing, si vous utilisez l’énumération de faiblesse commune MITRE. Figure 3-43 Balayage de Nikto par rapport à DVWA Le cadre d’exploitation du navigateur (BeEF) Le cadre d’exploitation du navigateur (https://beefproject.com/) est un outil de test de pénétration développépar Wade Alcorn qui se concentre sur les attaques côté client qui peuvent être utilisées pour « accrocher » les navigateurs à l’aide de techniques XSS. Son objectif est que le navigateur effectue différentes tâches, en fonction de la façon dont le navigateur est configuré, du type d’accès de l’utilisateur exécutant le logiciel de navigation et d’autres propriétés. BeEF est sous licence GPL et possède de nombreux modules qui peuvent être utilisés pour collecter des informations ou lancer des attaques. Certains des modules les plus utiles qui sont installés par défaut sont répertoriés et décrits dans le tableau 3-15. Tableau 3-15 Modules BeEF Notions de base de BeEF L’exercice suivant illustre une attaque côté client à l’aide de BeEF. Dans les versions récentes de Kali, BeEF n’est pas installé par défaut, vous devrez donc l’installer avec apt-get install beef-xss. Vous aurez besoin de votre machine virtuelle Kali Linux ainsi que de la machine virtuelle CentOS 1. Une fois BeEF installé, démarrez le programme en allant dans Applications | | des services système début du bEEF. Une nouvelle fenêtre apparaîtra demandant un mot de passe pour l’utilisateur de BEEf. Pour cet exercice, utilisez simplement « beef1 » comme mot de passe pour l’utilisateur « beef » par défaut. Lors d’un test de pénétration réel, vous voudrez vous assurer que vous utilisez une phrase secrète forte. Comme le montre la figure 3-44, vous disposez du lien à donner à vos victimes, et le service lancera une fenêtre de navigateur à laquelle vous pourrez vous connecter avec votre nom d’utilisateur et votre mot de passe de bEEf. Une fois connecté, vous devriez voir quelque chose de similaire à la figure 3-45. Figure 3-44 Démarrage du BeEF Figure 3-45 Console BeEF 2. En utilisant votre machine virtuelle CentOS comme machine victime, faites semblant que vous avez reçu un e-mail très convaincant avec un lien intégré (qui accrochera notre navigateur si vous cliquez dessus), puis cliquez sur le lien. Sur votre machine virtuelle CentOS, créez un fichier dans /tmp nommé test.html avec le contenu suivant, en remplaçant le cas échéant votre adresse IP Kali : 3. Après avoir enregistré le fichier, ouvrez votre navigateur et pointez-le sur file:///tmp/test.html. Vous ne verrez rien dans la fenêtre du navigateur, mais revenez à votre machine virtuelle Kali et à votre panneau de configuration BeEF, et vous devriez maintenant avoir une victime « accrochée », illustrée à la figure 3-46. Figure 3-46 Victime accrochée 4. Maintenant que vous avez une victime, rassemblez des informations sur votre cible. Tout d’abord, passez du sous-onglet Détails au sous-onglet Commandes, développez Navigateur | Domaine raccordé dans le volet Arborescence des modules, puis cliquez sur le module Détecter Firebug (voir figure 3-47). Dans le coin inférieur droit de la fenêtre principale, cliquez sur le bouton Exécuter ; l’exécution du script peut prendre une seconde ou deux. Une fois terminé, sélectionnez l’entrée dans le volet Historique des résultats du module, et les résultats doivent apparaître juste à droite de cela (voir Figure 3-48). Pour expérimenter davantage, voyez si vous pouvez obtenir une fausse barre de notification (sous Ingénierie sociale dans le volet Arborescence des modules) pour apparaître dans votre navigateur cible. Figure 3-47 uploads/Industriel/ chapitre-3-acces-initial-p2 1 .pdf