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 We b 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 existe r 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’aid e 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 Commande de sélection BeEF

Figure 3-48 Résultats des commandes

5. Une fois que vous avez terminé d’explorer, fermez BeEF et supprimez le fichier test.html.

OWASP ZAP

OWASP ZAP (proxy d’attaque Zed; https://owasp.org/www-project-zap) est activement

maintenu par OWASP et est également inclus dans Kali Linux par défaut. Il est gratuit et open
source et a beaucoup de fonctionnalités incluses dans les produits commerciaux. La
fonctionnalité de base de ZAP est en tant que proxy. Toutefois, vous pouvez installer des modules
complémentaires et des extensions pour augmenter les fonctionnalités, y compris la possibilité
d’effectuer des analyses de vulnérabilité par rapport à des technologies spécifiques. Dans
certains produits proxy, la portée ou la vitesse des fonctionnalités est limitée si vous utilisez la
version « Communauté » ou gratuite. Ce n’est pas le cas avec OWASP ZAP. Si OWASP ZAP n’est
pas installé sur votre système, tapez apt-get install zaproxy. Une fois installé, vous pouvez lancer
 l’application à partir d’une interface de ligne de commande en tapant zaproxy, ou à partir du menu
Kali Linux en choisissant Applications | | d’analyse d’applications Web owasp-zap.

TIP Burp Suite (https://portswigger.net/burp ) est un autre logiciel proxy qui peut être utilisé pour
les tests d’applications Web. Il est disponible dans une édition communautaire gratuite et dans
les éditions commerciales Enterprise et Professional. Il existe une grande communauté de
développeurs et de testeurs qui créent et partagent des plug-ins pour aider à automatiser
certaines tâches associées aux tests d’applications Web. Bien que l’édition Community soit
gratuite, certaines fonctionnalités sont désactivées ou limitées, et tous les plugins ne sont pas
disponibles.

ZAP OWASP

Vous aurez besoin d’une machine virtuelle Kali Linux avec OWASP ZAP installé et d’une machine
virtuelle cible avec Mutillidae et DVWA installés. Si vous avez configuré vos machines virtuelles
comme indiqué dans l’annexe B,vous devez être prêt. Vous pouvez être invité à réinitialiser ou
réinitialiser la base de données pour DVWA et Mutillidae. Assurez-vous également que les
paramètres de sécurité des deux sont définis sur leur paramètre le plus bas.

1. La première chose que vous devez faire est de configurer votre navigateur pour utiliser un
proxy. En utilisant Firefox comme exemple, cliquez sur le bouton avec trois lignes horizontales
pour ouvrir le menu, comme le montre la figure 3-49.
 Figure 3-49 Paramètres de Firefox

2. Cliquez sur Préférences. Tapez proxy dans la fenêtre de recherche, puis cliquez sur le bouton
Paramètres pour l’option Proxy réseau. Dans la boîte de dialogue Paramètres de connexion
(voir figure 3-50),sélectionnez la case d’option « Configuration manuelle du proxy », entrez
localhost dans le champ Proxy HTTP (si ce n’est pas déjà renseigné), entrez 8080 dans le
champ Port et cochez la case « Utiliser ce serveur proxy pour tous les protocoles ». Cliquez sur
OK pour quitter la fenêtre Paramètres de connexion.
 Figure 3-50 Paramètres du proxy

3. Lancez OWASP ZAP à partir de Kali Linux en choisissant Applications | | d’analyse d’applications
Web owasp-zap. Vous pouvez prendre des valeurs par défaut et/ou ne pas conserver vos
données entre les sessions lorsque vous y êtes invité, et vous devriez être accueilli avec l’écran
principal (voir Figure 3-51), qui se compose des trois fenêtres plus petites suivantes :

• La fenêtre de l’arbre (en haut à gauche), où vous pouvez suivre les sites visités

• La fenêtre Espace de travail (en haut à droite), où vous pouvez afficher et modifier les demandes
et les réponses ou effectuer des tâches de « démarrage rapide »

• La fenêtre d’information (en bas), qui se compose d’onglets pour les résultats des données pour
les actions effectuées sur les applications / site Web
 Figure 3-51 Fenêtre principale d’OWASP ZAP

4. Commencez par effectuer une analyse rapide des vulnérabilités par rapport à votre application.
Cliquez sur le bouton Analyse automatisée dans l’onglet Démarrage rapide de la fenêtre Espace
de travail. Entrez l’adresse IP et le port du serveur DVWA dans le champ « URL d’attaque », puis
cliquez sur Attaque.

5. Dans la fenêtre Informations, sous l’onglet Analyse active, vous devriez voir une activité po ur les
actions qu’OWASP ZAP effectue sur votre cible. Il devrait se terminer en quelques secondes, à
quel point vous pouvez cliquer sur l’onglet alertes dans la fenêtre d’informations pour voir ce
qu’OWASP ZAP trouvé (voir Figure 3-52). Vous devriez voir des alertes pour XSS, CSRF et la
navigation dans l’annuaire. Si vous sélectionnez Navigation dans l’annuaire dans l’onglet
Alertes, un nouvel ensemble d’informations doit être affiché à droite. Cela affichera l’URL de
l’emplacement de la vulnérabilité, un score de risque, le mappage CWE et une recommandation
proposée pour la correction. Il s’agit d’excellentes informations à fournir à l’organis ation cible
pour le rapport. Cependant, en tant que pentester, vous devrez vous assurer que le score de
risque est approprié en fonction de vos autres résultats et du réseau opérationnel et de la
tolérance au risque de votre client.
 Figure 3-52 Alertes d’analyse automatisée terminées

6. Deux des fonctionnalités les plus précieuses et les plus chronométrantes incluses avec le logiciel
proxy sont la possibilité d’automatiser des tâches banales, comme la devinette de mot de
passe, et de modifier les demandes envoyées au serveur. OWASP ZAP a cette fonctionnalité
intégrée et vous pouvez l’utiliser pour effectuer une attaque de devinette de mot de passe
contre le serveur. Effectuez cette attaque contre le serveur Mutillidae. La première chose que
vous devrez faire est d’essayer de vous connecter avec un nom d’utilisateur et un mot de passe
incorrects. Accédez au site et essayez de vous connecter avec le nom d’utilisateur admin et le
mot de passe admin. Il devrait échouer, mais une fois que cela a été terminé, cliquez sur
l’onglet Historique dans la fenêtre Informations et recherchez une demande POST définie sur
login.php (voir Figure 3-53).
 Figure 3-53 Demande post mutillidae

7. Dans la fenêtre Espace de travail, cliquez sur le Demande onglet. Vous devriez voir quelque chose
de similaire dans la fenêtre directement sous la demande brute:

username=admin&password=admin&login-php-submit-button=Connexion

8. Faites un clic droit dans cette fenêtre et sélectionnez Fuzz (voir Figure 3-54).

Figure 3-54 Début du fuzzing de connexion

9. Vous devez être invité avec la fenêtre Fuzzing avec trois zones distinctes, la demande brute
d’origine, les paramètres d’URL ci-dessous et un volet Emplacements de fuzzing à droite. S’il
existe des emplacements de fuzzing actuels, effacez-les en les sélectionnant et en cliquant sur
le bouton Supprimer. Ensuite, dans les paramètres d’URL (voir figure 3-55), sélectionnez le mot
admin après password= et cliquez sur Ajouter dans le volet Emplacements de fuzz (voir Figure
3-56).
 Figure 3-55 Paramètres de fuzzing

Figure 3-56 Ajouter un emplacement de fuzzing

10. Dans la fenêtre Charges utiles qui s’ouvre, cliquez sur le Ajouter bouton. Dans la liste déroulante
Type, choisissez Fichier, cliquez sur le bouton Sélectionner et accédez à ce fichier :
/usr/share/metasploit-framework/data/wordlists/common_roots.txt. Votre volet de
 visualisation de la charge utile doit maintenant être rempli avec les mots de la liste de mots
(voir Figure 3-57).

Figure 3-57 Liste de mots

11. Cliquez sur le Ajouter bouton pour terminer l’ajout de la liste de mots, puis cliquez sur le OK
bouton pour terminer la sélection de la charge utile. Cliquez sur le bouton Démarrer Fuzzer et
vous devriez commencer à voir les demandes dans un nouvel onglet Fuzzer dans la fenêtre
Informations.

12. Il existe plusieurs façons de configurer les connexions d’application Web et ce qui est fait une
fois qu’une connexion réussie se produit. Dans le cas du processus de connexion défaillant de
cette application Web, il semble que la page de connexion vous soit à nouveau présentée et
 qu’un message d’erreur indiquant que votre mot de passe était incorrect. Vous allez
maintenant examiner vos résultats de fuzzing pour voir si vous pouvez trouver une variation ou
une différence dans la façon dont l’application répond en fonction de l’entrée. L’une des
premières choses que vous pouvez faire est de rechercher des différences dans la taille de la
réponse pour voir si vous pouvez trouver une valeur aberrante. Dans la fenêtre In formations,
cliquez sur l’onglet Taille du corps du resp pour trier par ordre croissant et faites défiler vers le
haut (voir figure 3-58). Vous devriez voir que non seulement la réponse est d’une taille
différente, mais vous devriez également avoir rencontré un type de réponse différent, un 302,
ce qui signifie que le site Web vous redirige vers une page différente. Il semble que vous ayez
trouvé votre mot de passe. Essayez de vous connecter avec le nom d’utilisateur admin et un
mot de passe de adminpass. Vous avez utilisé la technique ATT &CK T1078, Comptes valides, qui
fait également partie de la tactique d’accès initial.

Figure 3-58 Comparaison de la taille du corps de la réponse

13. Une fois que vous avez terminé d’explorer, vous pouvez fermer OWASP ZAP et fermer votre
navigateur.

ATTENTION C’est une bonne idée de prendre l’habitude de réinitialiser vos paramètres de
proxy avant de fermer votre navigateur. Si vous ne le faites pas, la prochaine fois que vous
ouvrirez Firefox, il essaiera de communiquer avec le proxy. S’il n’y parvient pas, v ous ne pourrez
accéder à aucun site Web.

Attaques par injection SQL

Les attaques par injection SQL sont conçues pour tenter d’exécuter des instructions SQL afin
d’interroger la base de données de manière involontaire. Les attaquants espèrent collecter des
données sensibles telles que des mots de passe ou des numéros de carte de crédit. Selon la
maturité du programme de sécurité de la victime, ces informations peuvent être stockées non
chiffrées, cryptées ou hachées. Les attaques par injection SQL sont classées dans le cadre de la
tactique d’accès initial (TA0001) dans le framework MITRE ATT&CK, sous la technique Exploit
Public-Facing Application (T1190). Les attaques par injection SQL font également partie de la
classification des attaques par injection sous OWASP, et l’injection est répertoriée comme
numéro un dans le top 10 des risques de sécurité des applications Web
OWASP(https://owasp.org/www-project-top-ten/). Les moyens d’atténuer les attaques par
injection SQL incluent le paramétrage des requêtes et la liste blanche des caractères. Le
paramétrage des requêtes nécessite que les développeurs assignent des variables aux objets
dans les chaînes de requête au lieu d’accepter les entrées d’utilisateur à utiliser dans les chaînes
de requête. La liste blanche des caractères fait référence à l’autorisation de fournir uniquement
certains caractères par les utilisateurs, filtrant ainsi les caractères spéciaux, tels que les
guillemets, les tirets, les points-virgules et les caractères de commentaire. Comme ce sont les
caractères que les développeurs souhaitent filtrer, ce sont également les premiers caractères que
les pentesters doivent utiliser pour essayer de déterminer si une application est sensible à
l’injection SQL.

REMARQUE L’ID de modèle d’attaque mitre common attack pattern énumération et

classification couvre l’injection SQL : CAPEC-66.

Empreinte digitale des serveurs SQL

Une fois que vous avez déterminé que l’application est vulnérable à l’injection SQL, l’étape
suivante de votre processus doit être d’essayer de déte rminer la « création et le modèle » de la
base de données principale. Il est possible que vous ayez pu découvrir ces informations lors de
votre reconnaissance ou de votre analyse réseau, mais un scénario plus probable est que la base
de données se trouve sur un segment de réseau inaccessible à partir de votre emplacement. Il
n’est pas rare que les développeurs ou les administrateurs système négligent certaines options
de configuration, telles que le masquage des informations de débogage. Si des messages de
débogage ou d’erreur sont affichés dans l’application, les attaquants peuvent utiliser ces
informations pour aider à empreinte digitale le type de base de données. Le tableau 3-16
répertorie les types de base de données les plus courants et les messages d’erreur
correspondants que vous pouvez utiliser pour déterminer le type de base de données.

Tableau 3-16 Codes d’erreur de base de données courants

Injection SQL standard et aveugle

Cette section examine à la fois l’injection SQL standard et l’injection SQL aveugle. Considérez le
code PHP suivant:

Le code précédent permet à l’application de passer l’entrée d’utilisateur à la base de données

à interroger. Il n’effectue aucune désinfection ni n’utilise de liste blanche. Cela permettrait à un
attaquant d’utiliser des chaînes spéciales pour manipuler la chaîne de requête envoyée à la base
de données. Si l’attaquant a spécifié ' ou '1'= '1 pour un nom d’utilisateur et un mot de passe, la
chaîne de requête envoyée à la base de données ressemblerait à ceci (sans gras appliqué au nom
d’utilisateur et au mot de passe) :

Cela prendrait la valeur TRUE, qui retournerait toutes les données de la table userProfile. Ce qui
en fait une attaque par injection SQL standard est le fait que les données retournées par la
requête sont affichées à l’utilisateur. Vous pouvez également utiliser des commentaires dans
votre champ nom d’utilisateur pour rendre le reste de l’instruction inutile. Les caractères de
commentaire peuvent différer selon le type de base de données. Les caractères de commentaire
les plus courants sont #, -- (suivi d’un espace) et les commentaires multilignes de style C qui
commencent par /* et se terminent par */. Si vous avez modifié votre champ de nom d’utilisateur
et utilisé ' ou '1'= '1';-- la nouvelle requête qui serait envoyée à la base de données ressemblerait à ceci
:

Tout ce qui suit le double tiret et l’espace serait interprété comme un commentaire et ne serait
pas évalué par la base de données, et donc ce code retournerait toutes les données dans la table
userProfile ainsi.

Il peut toujours y avoir une vulnérabilité d’injection SQL même si vous ne parvenez pas à voir
les résultats de la requête que vous envoyez à la base de données. C’est ce qu’on appelle
l’injection SQL aveugle. Essentiellement, l’injection SQL aveugle se produit lorsqu’un attaquant
est en mesure de différencier le résultat d’une requête de base de données donnée retournant
TRUE ou FALSE. Considérez le code suivant :
 Si vous êtes en mesure d’injecter une chaîne de requête dans la valeur itemID, vous pouvez
tromper la base de données en vous donnant des informations selon que l’instruction a la valeur
TRUE ou FALSE. Souvent, les attaquants utilisent une instruction UNION pour les injections SQL
aveugles afin de recueillir plus d’informations sur la base de données. Une instruction SQL UNION
est utilisée pour retourner les résultats de deux requêtes distinctes dans une seule table. Vous
pouvez utiliser ces types de requêtes pour cibler d’abord le nombre de colonnes d ans une table
avant de procéder à la collecte du contenu de la table :

';

En fonction du résultat TRUE ou FALSE reçu de l’application, faites comme si vous aviez
déterminé que la table comporte cinq colonnes. Cela vous donnerait également les numéros de
colonne qui sont retournés par la requête. Vous pouvez ensuite insérer d’autres requêtes dans
votre instruction UNION pour collecter plus d’informations sur la base de données, telles que les
noms de table et de colonne, ou la version de la base de donnée s :

Selon les autorisations attribuées aux colonnes, aux tables ou même aux bases de données,
les attaquants peuvent renvoyer des résultats de l’une de ces possibilités. À l’aide d’une
technique aveugle basée sur une valeur booléenne, les attaquants peuv ent alors commencer à
énumérer des éléments tels que des noms de table ou de colonne, ou des données stockées dans
la base de données, un caractère à la fois. Essentiellement, les requêtes demanderaient à la base
de données, « Est le premier caractère de la première table A. » Si le résultat est TRUE, la requête
suivante demande si la deuxième lettre est un A. Si le résultat est FALSE, la requête suivante
demande si la première lettre est a b. Cela continuerait jusqu’à ce que la base de données entière
ait été énumérée.

Automatisation des tests d’injection SQL avec Sqlmap

Comme vous pouvez l’imaginer, l’exécution manuelle d’une attaque par force brute contre
toutes les données de la base de données prendrait un temps excessif. Entrez sqlmap. Écrit en
Python, sqlmap est un outil open source qui peut être utilisé pour automatiser les tests
d’injection sur plusieurs types de bases de données, notamment MySQL/MariaDB, PostgreSQL,
MS SQL et Oracle. Il existe depuis 2006 et est toujours activement développé et entretenu. Il est
open source, sous licence GPLv2. Sqlmap peut être utilisé non seulement pour étoffer les points
d’injection et les techniques possibles, mais aussi pour les requêtes standard, et parfois même
pour l’exécution de code à distance ou l’accès shell. L’exécution de code à distance et l’accès shell
peuvent nécessiter l’activation de fonctionnalités de base de données spéciales. Dans le cas de
MySQL/MariaDB, les fonctions définies par l’utilisateur doivent être activées et l’utilisateur qui
se connecte à la base de données pour le compte de l’application Web a besoin d’autorisations
pour ajouter/modifier des fonctions définies par l’utilisateur. Dans le cas de MS SQL, les
utilisateurs doivent disposer des autorisations nécessaires pour exécuter ou activer la fonction
xp_cmdshell. Comme son nom l’indique, cette fonction exécute les commandes Windows comme
si elles étaient exécutées à partir d’une invite cmd.exe. La page d’aide de Sqlmap incluse avec le
progiciel est complète. Toutefois, vous seriez mieux servi en affichant la page Utilisation sur le
site Web du projet,https://github.com/sqlmapproject/sqlmap/wiki/Usage , qui donne
des exemples d’utilisation de l’outil dans différents scénarios. L’utilisation de sqlmap est
également documentée dans ATT&CK sous la technique T1190, Exploit Public Facing Application.

Injection de commande

Comme les vulnérabilités d’injection SQL, les vulnérabilités d’injection de commandes sont
exploitées afin d’a permettre au système cible d’effectuer une tâche de manière involontaire.
Toutefois, le résultat final est généralement l’exécution de code à distance par opposition à la
fuite d’informations. Il existe certains cas limites où l’injection SQL pourrait conduire à l’injection
de commande, comme indiqué précédemment avec l’utilisation de fonctions définies par
l’utilisateur dans MySQL ou la fonction xp_cmdshell dans MS SQL, mais cette section se concentre
sur l’injection de commande simple. Les vulnérabilités d’injection de commandes entrent
également dans la catégorie Injection en haut des 10 principaux risques de sécurité des
applications Web OWASP.

Il convient de noter que si un attaquant est en mesure d’obtenir l’exécution de code à

distance, les commandes seront exécutées dans le contexte et avec les autorisations de
l’utilisateur exécutant les applications. Cela signifie que les organisations doivent s’assurer
qu’elles implémentent le moindre privilège lors de la configuration des applications, afin que les
applications ne s’exécutent pas en tant qu’utilisateur racine ou SYSTÈME. Les atténuations des
vulnérabilités d’injection de commandes sont de nature similaire à celles de l’injection SQL dans
la mesure où les développeurs doivent mettre en liste blanche les caractères autorisés et limiter
la quantité d’entrées d’utilisateur non fiables autorisées dans les applications. Certains des
caractères les plus reconnaissables qui doivent être exclus incluent l’esperluette, le canal, les
guillemets simples et doubles, le signe dollar, les parenthèses, les symboles supérieur à et
inférieur à et le point-virgule. Ce processus d’exclusion de caractères et de limitation et de
normalisation des entrées d’utilisateur est appelé nettoyage des entrées.

REMARQUE L’ID de modèle d’attaque MITRE Common Attack Pattern énumération et

classification suivants couvre l’injection de commande : CAPEC-66.

Attaques côté client

À l’exception de BeEF, chaque attaque que vous avez exécutée jusqu’à présent a des serveurs
ciblés. Mais comme nous l’avons mentionné au début de ce chapitre, il y a un autre côté à la
médaille de l’exploitation : le client. Il existe plusieurs façons de cibler les services clients, les
systèmes et les utilisateurs qui les exploitent. Toutefois, comme il s’agit d’une section sur les tests
d’applications Web, elle se concentre sur les attaques côté client qui sont perpétuées en raison
de vulnérabilités ou d’erreurs de configuration sur le serveur.

Scripts inter-sites (XSS)

Bien que cette attaque soit techniquement appelée attaque par injection par OWASP, les
attaques de script inter-sites (actuellement septième) dans les 10 principaux risques de sécurité
des applications Web OWASP. XSS est généralement une attaque qui tire parti de JavaScript afin
d’obtenir le navigateur d’une victime pour effectuer une sorte d’action. L’attaque tire parti de la
confiance de l’utilisateur dans un site Web, lui permettant d’accéder à toutes les informations
stockées (par exemple, les cookies) auxquelles le site Web particulier pourrait avoir accès. Les
attaques XSS peuvent également prendre d’autres formes, telles que la production de fenêtres
pop-up ou même l’exécution d’actions sur un site Web particulier. Il existe trois principaux types
d’attaques XSS : XSS stocké, XSS réfléchi et XSS basé sur DOM.

REMARQUE L’ID de modèle d’attaque MITRE Common Attack Pattern Enumeration and
Classification ci-dessous couvre toutes les vulnérabilités XSS, bien que chacune possède son
propre identificateur spécifique : CAPEC-63.

Une vulnérabilité XSS stockée repose également sur la confiance de la victime dans un site Web.
Cependant, cette fois, le code malveillant est stocké sur un site vulnérable et sera exécuté par
toute victime qui accède à la page infectée. Le scénario le plus probable pour ce type d’attaque
est un forum Web ou un système de babillard électronique où les utilisateurs sont autorisés à
soumettre des commentaires. Si les soumissions des utilisateurs ne sont pas correctement
nettoyées, les soumissions peuvent contenir du code qui s’exécutera pour tout utilisateur qui
visite le forum. Ce type d’attaque serait classé sous Drive-by Compromise (T1189) dans ATT&CK.

XSS réfléchi Une attaque XSS réfléchie est effectuée à l’aide d’un site Web vulnérable pour
refléter l’attaque hors du serveur cible, et est généralement effectuée en demandant à la victime
de cliquer sur un lien dans un e-mail ou de prendre une autre action qui envoie une demande au
serveur vulnérable. Le serveur demande ensuite au navigateur de la victime d’exécuter le script.
Étant donné que l’utilisateur (et le navigateur de l’utilisateur) fait confiance au site, le cod e
s’exécutera et effectuera un certain nombre d’actions malveillantes. Une attaque de cette nature
tomberait très probablement sous T1192, Spearphishing Link, dans ATT &CK.

XSS basé sur DOM Un XSS basé sur DOM est entièrement côté client. Pour commencer, le modèle
DOM (Document Object Model) est un moyen de structurer logiquement un document Web
(XML ou HTML) afin de définir comment le document est accessible ou manipulé. Le DOM a été
conçu pour être indépendant de la langue et de la plate-forme et n’est exécuté qu’une fois que
le document est renvoyé à partir du serveur. Lors d’une attaque XSS basée sur DOM, la réponse
du serveur est exactement la même qu’une réponse non maçonne. Toutefois, une fois reçu, le
 client modifiera les informations en fonction de ce qui se trouve dans le DOM avant de les afficher
à l’utilisateur. Cela rend les protections côté serveur inutiles.

Falsification de demande inters sites

Les attaques CSRF nécessitent que la victime soit déjà un utilisateur autorisé et authentifié d’un
site Web particulier. Une attaque CSRF est différente d’une attaque XSS en ce qu’une attaque
XSS exploite la confiance qu’une victime peut avoir dans un site Web donné, tandis qu’une
attaque CSRF exploite la confiance qu’un site donné peut avoir dans un utilisateur ou le
navigateur de cet utilisateur. Ce type d’attaque serait catégorisé de la même manière dans ATT
&CK à celui d’un XSS réfléchi (T1192, Spearphishing Link) en ce qu’il obligerait la victime à cliquer
sur un lien malveillant qui leur est envoyé. Les étapes nécessaires pour compléter un compte
CSRF sont les suivantes :

1. La victime se connecte au site Web cible, par exemple, l’interface d’administration de son site
Web de blogs.

2. L’attaquant envoie à la victime un lien malveillant contenant une demande d’exécution d’une
action sur le site Web cible, par exemple, « Modifier le mot de passe de l’utilisateur ».

3. La victime clique sur le lien, qui effectue l’action spécifiée sur le site auquel elle est actuellement
connectée.

4. Le site Web cible traite la demande et modifie le mot de passe de la victime.

OWASP a une liste de recommandations et de feuilles de triche pour prévenir les

vulnérabilités CSRF et XSS et de nombreuses autres vulnérabilités possibles dans les
applications Web. Consultez https://cheatsheetseries.owasp.org/.

TIP CSRF, parfois prononcé « see-surf », est également appelé XSRF.

Conseils pour gagner du temps

Être en mesure de tester efficacement tous les ports possibles sur tous les périphériques en
réseau possibles ne sera généralement pas possible. La plupart des e ntreprises n’ont pas de fonds
ou de temps infinis, vous devrez donc être en mesure de résoudre ces problèmes tout en
fournissant à votre client une image bien formée de la santé globale de la sécurité de leur réseau.
Pour ce faire, il est possible d’assurer une délimitation adéquate de la portée du projet, comme
il est indiqué au chapitre 1. Pourtant, il y aura des moments où votre client demandera
l’impossible, comme tester chaque port et chaque application sur chacun de ses 10 000 appareils
en une seule semaine. Il existe des outils mis à jour et plus récents qui peuvent vous aider à
effectuer vos analyses plus rapidement. Masscan et Zmap sont deux outils qui permettent aux
testeurs d’effectuer des analyses de grands réseaux en quelques minutes plutôt qu’en quelques
heures ou jours. Une autre façon d’économiser du temps passé à rechercher votre cible est
quelque chose qui a déjà été mentionné, soit une approche de boîte grise ou blanche. Demander
à votre client de vous fournir de l’information à l’avance permettra d’économiser du temps et de
l’argent.

En ce qui concerne la cartographie et l’analyse du réseau, demander à vos clients de fournir

des informations sur leurs réseaux et périphériques de périphérie peut aider à minimiser la
quantité d’analyse que vous devez effectuer. Par exemple, si vous effectuez un test de
pénétration externe et que vous savez en examinant les configurations de pare -feu que votre
client autorise uniquement les ports 22, 80 et 443 à travers leur pare -feu, vous n’avez pas besoin
d’analyser les 65 536 ports. Dans ce cas, vous ne comptez pas sur la connaissance et la mémoire
de votre client de sa configuration réseau, car vous avez les configurations réelles des appareils
appropriés, diminuant ainsi la possibilité d’erreur humaine.

Vous pouvez également effectuer votre test sur un sous-ensemble représentatif de la liste
globale des cibles. Si votre client possède 10 000 appareils, mais qu’il n’existe que 10 types
d’appareils différents, il peut être utile de n’analyser que quelques-uns de ces 10 000 appareils
de chaque catégorie de type. L’inconvénient de cette approche est que vous (et votre client) êtes
convaincus qu’il n’y a pas de différences majeures dans la configuration entre les systèmes du
même type, et avec l’expérience, vous verrez bientôt qu’un problème majeur qui se trouve
souvent dans les grandes organisations est le glissement de configuration, où les administrateurs
ne peuvent pas garantir que les configurations système sont normalisées dans l’ensemble de
l’entreprise.

Dans le cas d’un client qui craint la congestion du réseau sur son réseau de production, vous
pouvez également suggérer que le test soit effectué sur une architecture représentative, telle
qu’une architecture de développement ou de test. De nombreuses entreprises permettront de
mettre en place ces types d’architectures représentatives pour tester les correctifs logiciels et
d’autres modifications tout en minimisant la possibilité que ces modifications aient un impact sur
le réseau de production. Ce type de test souffrira également d’un glissement de configuration,
car il est fort probable qu’un réseau de test ou de développement ne soit pas identique au réseau
de production.

Vous pouvez demander à votre client d’apporter des modifications à son environnement pour
permettre à vos analyses et évaluations de se terminer plus rapidement. Demander à votre client
de vous fournir des informations d’identification pour votre logiciel d’analyse des vulnérabilités,
par exemple, vous aidera à collecter des informations de configuration sur vos cibles et à éliminer
les faux positifs. En fin de compte, cela vous fera non seulement gagner du temps en matière de
recherche et de test, mais aussi du temps à votre client pendant la correction. Votre client peut
également modifier les configurations réseau (par exemple, autoriser votre adresse IP à accéder
à des périphériques spécifiques) pour aider vos analyses réseau à se terminer plus rapidement.
En tant que pentester, cela vous aidera à mieux gérer votre temps et à vous concentrer sur
l’évaluation et l’exploitation des vulnérabilités, plutôt que d’attendre la fin des analyses. Le
principal inconvénient de cette approche est que votre client augmente essentiellement sa
surface d’attaque. Ils permettent non seulement la possibilité qu’un attaquant réel obsède un
accès non autorisé, mais ne reçoivent pas non plus une représentation précise des vulnérabilités
auxquelles l’organisation est confrontée.

Vous devrez discuter avec votre client si l’une de ces approches correspond au calendrier du
test proposé, tout en respectant les buts et objectifs. Ce n’est que par le biais d’une
communication ouverte que vous pouvez vous assurer que les problèmes soulevés en raison de
tests de grande portée ne minimisent pas la précision des résultats produits par vos tests.

Fin

Prendre pied dans le réseau de votre cible a commencé par l’exécution de la reconnaissance et
de la collecte OSINT dans le chapitre 2. Cela vous a préparé à collecter activement des
informations sur le réseau et les périphériques de votre cible en effectuant une cartographie
réseau et des analyses de vulnérabilité. La connaissance des différents outils et techniques de
numérisation vous permettra d’exécuter ces analyses de manière efficace et efficiente. S’assurer
que vous planifiez en conséquence pour les zones à problèmes possibles vous aidera à éviter des
retards inutiles dans votre calendrier de test. Une fois que vous avez une image complète de
l’ensemble de la surface d’attaque, vous serez mieux préparé à planifier et à exécuter des
attaques contre les serveurs ou les appareils de l’utilisateur final de votre cible en utilisant une
ou plusieurs des nombreuses techniques différentes décrites dans ce chapitre.