16 PhasesIntrusion - 5SOA

Les phases
d’intrusion
ECOLE
ECOLE IT
IT –– 5SOA
5SOA -- Année
Année Académique
Académique 2023-2024
2023-2024 –– ©
© Tous
Tous droits
droits réservés
réservés
Résumé
• Prise d’empreinte
• Phase d’exploitation
• Post exploitation
• Masquer les traces
ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Les phases
d’intrusion
Phase de reconnaissance
ECOLE IT – 5SOA- Année Académique 2023-2024 – © Tous droits réservés

Infrastructure web
L’infrastructure mutualisée : les sites internet sont hébergés sur un serveur sécurisé avec d’autres clients.
Correspond bien aux sites marchands à faible trafic.
L’infrastructure semi-distribuée : les sites internet sont hébergés sur des serveurs web dédiés connecté à un
pare-feu dédié. Correspond aux sites ou infrastructures à moyen ou fort trafic.
L’infrastructure distribuée : l’hébergement des sites est dispatché sur plusieurs serveurs pour maximiser les
performances : des load-balancer qui dirigent les requêtes et gèrent la charges des serveurs ; des serveurs qui
gèrent uniquement la partie web (Apache / PHP) ; des serveurs de base de données ; des serveurs de fichiers
(jusqu’à plusieurs Téraoctet de stockage) ; des serveurs spécifiques selon vos besoins. Correspond aux sites ou
infrastructures à fort trafic.

Infrastructure distribuée
Navigateur web : chaque navigateur est différent, il faut donc que le code soit compatible avec le navigateur utilisé
par vos clients.
Serveur DNS : le serveur DNS permet de transformer un nom de domaine en adresse IP.
Load balancer et Reverse Proxy : l’utilisation d’un load balancer permettra de répartir les requêtes entre les
différents serveurs d'applications.
Serveur d’application : le serveur d’application va exécuter le code applicatif (java, js, php, C#, ...). Très souvent
plusieurs instances d'une application seront déployées sur différents serveurs d’applications.
Base de données : C'est ici qu'on va stocker les données de l’application, soit de façon simple (une base de donnée
sur un serveur), soit de façon plus compliquée en utilisant un cluster de base de données.
Fonctionnement d’une application web
SELECT * from users where id = 6534
Requête http
Utilisateur Internet Firewall Serveur web Serveur Base de données

d’application

Architecture d’une application web
Utilisateur
Client Couche métier
Serveur d’application
Couche accès base de données

AJP
HTTP HTTP JDBC
JNDI API AWS
Couche web Couche bdd API xxx
Firewall Serveur base de données

Authentification
Serveur web
Cache

Présentation du protocole HTTP
HTTP (HyperText Transfer Protocol) est un protocole (couche 7

HTTP
du modèle OSI) de communication utilisé pour le transfert de Protocole
couche 7
données sur le Web. Il permet aux navigateurs web d'envoyer des
requêtes aux serveurs web et de récupérer des ressources, telles
que des pages web, des images, des vidéos et d'autres contenus,
afin de les afficher aux utilisateurs.
HTTP est considéré comme un protocole sans état, ce qui signifie

que chaque requête est traitée indépendamment des autres. Le
serveur ne conserve pas d'informations sur les requêtes précédentes,
mais nécessite l'utilisation de mécanismes comme les cookies pour
maintenir l'état entre les requêtes.

Evolution du protocole HTTP
A ce jour, il existe plusieurs versions du protocole HTTP, qui sont :
Invention
de HTTP par 1989 1991 1996 1999 2014 2015 2018
Tim
Berners-Lee
HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/1.1bis HTTP/2 HTTP/3
Le protocole une Utilisation de Clarification de

ligne headers la RFC2616
RFC1945 Protocole Un protocole pour Amélioration de
RFC822 standardisé plus de performances la performance
Meilleure gestion (adoption de SPDY) (protocole QUIC)
du cache 2.4.17 http Apache
Fonctionnalité 1.9.5 http Nginx
Keep-Alive
RFC2616

Fonctionnement du protocole HTTP

Le protocole HTTP est basé sur le modèle client-serveur ;

Le client, généralement un navigateur web, envoie une requête au serveur, qui héberge

les ressources demandées ;

Le serveur traite ensuite la requête et renvoie une réponse au client avec les données

demandées.
Requête HTTP
« Retourne moi le document /index.html »
Réponse HTTP
Client « Voici le doc au format HTML, sa taille est de 3200 caractères »

Serveur

Méthodes du protocole HTTP
Les principales méthodes HTTP sont : GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH,
TRACE et CONNECT. Chaque verbe a une signification spécifique et est utilisé pour effectuer
différentes actions sur les ressources du serveur.
Méthode HTTP Description
GET Demande une représentation de la ressource spécifié

POST Envoie des données au serveur
PUT Crée une nouvelle ressource ou remplace une représentation de la ressource ciblée par
le contenu de la requête
DELETE Supprime la ressource indiquée
HEAD Demande les en-têtes qui seraient retournés si la ressource spécifiée était demandée
avec une méthode HTTP GET
OPTIONS Décrit les options de communication pour la ressource ciblée
PATCH Applique des modifications partielles à une ressource
CONNECT Utilise un proxy comme un tunnel de communication
TRACE Demande au serveur de retourner ce qu’il a reçu dans le but de tester et effectuer un
diagnostic sur la connexion

Utilisations du protocole HTTP
Le protocole HTTP est principalement utilisé pour la communication entre un client

et un serveur Web. Ci-après quelques exemples :
Utilisation Description
Navigation Web Chargement de pages Web dans un navigateur
Transfert de fichiers Upload/Download de fichiers tels que des images, des vidéo ou des documents
Services Web Fourniture d’interfaces RESTful ou SOAP afin de permettre aux applications de
communiquer via le réseau
API Web Accès à des données distantes, des services, des réseaux sociaux, etc...
Communication IoT Parfois utilisé pour la communication entre appareils IoT et serveurs

Codes erreur du protocole HTTP
• Les codes d’erreur HTTP, également appelés codes de statut HTTP, sont des codes numériques envoyés
• par un serveur HTTP à un client HTTP pour indiquer le résultat du traitement de la requête HTTP ;
• Ils sont regroupés en différentes catégories, chacune ayant sa signification spécifique.

Catégorie Description Exemples (liste non exhaustive)
1xx Codes de réponse 100 : continuer

d’informations
2xx Codes de succès 200 : OK
201 : créé
204 : pas de contenu
3xx Codes de redirection 301 : redirection permanente
302 : redirection temporaire
304 : non modifié
4xx Codes d’erreur du client 400 : requête incorrecte
401 : non autorisé
403 : interdit
404 : non trouvé
5xx Codes d’erreur du serveur 500 : erreur interne du serveur
502 : mauvaise passerelle
503 : service non disponible
Les en-têtes HTTP (headers)
Les en-têtes HTTP permettent au client et au serveur de transmettre des informations

supplémentaires avec la requête ou la réponse. Un en-tête de requête est constitué de
son nom (insensible à la casse) suivi d'un deux-points :, puis de sa valeur (sans saut de
ligne).

Les cookies
Un cookie est un petit fichier stocké par un serveur dans le client d’un utilisateur et associé
à un domaine web. Ce fichier est automatiquement renvoyé lors de contacts ultérieurs avec
le même domaine.

Utilisation de HTTP pour une URL
Une URL (Uniform Resource Locator) est un format de nommage universel pour désigner
une ressource sur Internet. Il s'agit d'une chaîne de caractères ASCII imprimables qui se
décompose en cinq parties :
Schéma User/mot de passe (facultatif) Alias serveur Port Chemin

(facultatif)
http :// user : password @ www.evil.com : 80 /index.html

La sécurité du protocole HTTP
• Contexte :

Nativement, le protocole HTTP n’est pas sécurisé. Les données sont transmises en

texte brut. Cela expose les informations aux risques d'interception ou de modification

pendant le transit. Si on souhaite sécuriser le protocole HTTP, il est nécessaire d’utiliser

le protocole HTTPS (Hyper Text Transfer Protocol Secure)
• HTTPS :

HTTPS ajoute une couche de chiffrement TLS, à l’aide d’un certificat TLS, pour les

données échangées entre le client et le serveur Web. A ce jour les versions de TLS

préconisées par l’ANSSI sont les versions TLS v1.2 et v1.3
• Header HSTS :

Le header HSTS (HTTP Strict Transport Security) est un mécanisme qui permet à un

serveur Web de déclarer à un client Web qu’il doit interagir avec lui en utilisant une

connexion sécurisée (tel que HTTPS)

Prise d’empreinte
La prise d’empreinte d'un serveur web consiste à identifier le type et la version

du serveur web sur lequel tourne une cible.
La découverte précise du type de serveur web sur lequel fonctionne une

application peut permettre aux testeurs de sécurité de déterminer si
l'application est vulnérable à une attaque.
En particulier, les serveurs exécutant d'anciennes versions de logiciels sans

correctifs de sécurité à jour peuvent être vulnérables à des exploits connus
spécifiques à une version.

Prise d’empreinte d’une webapp
Wappalyzer
Op stem
rks
Sy
WAF
era
wo
s.io
tin
me
nsy
g
Fra
Ce
p0f
es
Cr
W
ic ap
aw
ha
rv
Se Nm
tw
lin
Cv
af
g
e p
ers de
tai ku
Coo ead ls.c s loo
kies H om N
Version du serveur web Produits Exploit-db.com Google Hacking
Err Ha
eur og kra
sH eL wle
IP TT hiv r
P
@ Arc
So
Bu
ur
rp
eb
ie
Su
ph
es
tw
Extension de
ite
ra
ha
H
Walw00f
TM
g
W
rto
fichiers
L/
Ca
JS

Motivations de la prise d’empreinte ?
Identification des produits et versions
Recherche des vulnérabilités publiques
Utilisation des exploits
Outils

Cartographie manuelle des fonctionnalités du site web
01 Explorer manuellement la webapp pour identifier toutes les fonctionnalités

02 Si besoin créer un compte afin d’accéder à des fonctionnalités spécifiques
03 Noter et surfer sur chaque URL déclarée dans la webapp
04 Identifier chaque fonctionnalité et noter leur URL
05 Pour chaque URL, noter les paramètres passés
06 Noter l’extension de chaque script dans l’URL (.jsp, .php, .aspx, …)

Analyse des sources HTML
Analyser minutieusement le code source HTML de la webapp
Rechercher les commentaires < !-- et les balises <META écrits

dans le code HTML. Parfois ils mentionnent des informations
intéressantes
Rechercher les liens URL car ils peuvent aider à comprendre la

structure du site web
Rechercher la destination des attributs ‘action’ des formulaires

Analyse des sources HTML (suite)
Outil

Fuite d’informations grâce aux erreurs HTTP
Utiliser des fonctionnalités avancées des moteurs de recherche
Utiliser les commandes définis dans Google Hacking Database

pour optimiser les recherches d’erreurs HTTP
Les informations collectées vont délivrer la version du serveur

web, la technologie utilisée,...

Fuite d’informations grâce aux erreurs HTTP (suite)
Outil

Détection du WAF
L’objectif est de déterminer si la webapp est protégée par un WAF
Connaître le type de WAF permet parfois d’appliquer des

contournements sur les protections existantes
Utiliser l’outil wafw00f pour détecter l’existence d’un WAF en

frontal de la webapp
Outil
• Exemple : wafw00f https://www.loreal.com

Identifier la version du serveur web
Le principe consiste à analyser la réponse du serveur afin d’en

déduire le type et la version du serveur web
L’information ainsi recueillie aide le pentester à sélectionner les

exploits qui permettront d’exploiter des vulnérabilités
Outil
• Exemple : nmap -sV -p80,443 www.loreal.com

Enumérer les services
Scanne le serveur pour identifier les différents services exposés
Chaque service ouvert doit être considéré comme une piste

potentielle d’accès à des vulnérabilités
Outil
• Exemple : nmap -sS -p- www.loreal.com

Enumérer les services (suite)
Outil
• Exemple : https://censys.io

Identifier les frameworks et produits
Une analyse des headers dans la réponse HTTP permet souvent
de découvrir les technologies employées côté serveur
Outil
Outil

Identifier les frameworks et produits (suite)
Outil

Analyser les extensions des fichiers
Technologie Extension Plateforme
Script Perl CGI .pl Serveurs web sous Linux

Active Server Page .asp Microsoft IIS
ASP+ .aspx Microsoft .NET
Script PHP .php Apache
Java Server Page .jsp Tomcat, Jboss,...
Java Struts .do Tomcat, Jboss,...

Analyser les cookies
Serveur Cookie
Apache Apache=...
IIS ASPSESSIONID...
Java JSESSIONID
PHP PHPSESSID-

Découvrir le système d’exploitation
Outil
• Exemple : nmap -O www.loreal.com

Les phases
d’intrusion
Phase d’exploitation

Phase d’exploitation
• Utilisation avec succès d’une vulnérabilité ou d’une faille de sécurité pour pénétrer un SI :

Code malveillant (injections, webshells...);

Exploits pour des vulnérabilités logicielles (CVE, scripts);

Techniques d’ingénierie sociale pour obtenir des accès non autorisés.
• Objectif : prendre le contrôle du système cible ou obtenir des informations sensibles

Cross-Site Scripting (XSSi)
• Les attaques XSSi exploitent des vulnérabilités générées dynamiquement dans les
• pages web d’une application ;
• Une vulnérabilité apparaît lorsqu’un point d’injection n’est pas sécurisé (i.e. lorsqu’un
• paramètre d’URL ou un champ de formulaire web n’est pas filtré) ;
• Elles permettent à un attaquant d’injecter du code javascript, HTML... dans les pages
• web qui seront consultées par d’autres utilisateurs à travers des requêtes « légitimes » ;
• Les impacts d’une attaque XSS peuvent être :
Exécution de script malicieux Vol de session utilisateur

Redirection vers un site malveillant Escalade de privilèges
Défiguration de site Manipulation/Vol de données

Fonctionnement des attaques XSSi
Fonctionnement Exemple d’utilisation d’une

nominal page html vulnérable qui
traite une erreur HTTP 404
404 Not http://texy45.com/
found 1 texy_file.html
/texy_file.html Code exécuté côté back-end

<html>
2 <body>
< ? php
print
2 urldecode($_SERVER[« REQUEST_URI »]) ;

?>
</body> Serveu
</html>
r
404 Not
found
/!\ Warning 1 http://texy45.com/<script>alert(«/!\ Warning Arrêt du
Arrêt du serveur ») ;</script>
serveur
Attaque
XSSi

Catégories de XSSi
XSS réfléchie Le code malveillant est inclus dans l'URL ou les paramètres d'une requête HTTP.
Lorsque la cible clique sur un lien ou soumet un formulaire avec les paramètres infectés,
le code malveillant est renvoyé par le serveur et exécuté dans le navigateur de la
victime. Contrairement au XSS stocké, le code réfléchi n'est pas persistant et dépend de
l'action immédiate de la victime.
XSS stockée Dans ce type d'injection, le code malveillant est stocké sur le serveur, généralement
dans une base de données ou un autre emplacement de stockage persistant. Lorsque
d'autres utilisateurs consultent la page qui affiche le contenu infecté, le code malveillant
est renvoyé directement par le serveur et s'exécute dans leurs navigateurs.
Blind XSS Cette attaque se produit sans que l'attaquant puisse voir directement les résultats de
son injection de code malveillant. Cela signifie que l'attaquant ne peut pas observer
immédiatement les effets de son attaque en examinant la page web ou en interagissant
avec elle. Néanmoins, les résultats de l'attaque peuvent être récupérés par l'attaquant
ultérieurement, souvent à travers un canal de communication différent.
DOM-based XSS Ce type d'injection XSS exploite des vulnérabilités dans le DOM (Document Object
Model) du navigateur. Le code malveillant est généralement inséré dans les scripts
JavaScript directement sur la page web et ne passe pas par le serveur. Lorsque le script
est exécuté, le code malveillant modifie le DOM et peut entraîner des conséquences
malveillantes.

Attaque XSSi via e-mail
2 Bonjour
La victime clique sur
le
Interne Message important de votre lien malicieux
t 7 3 banque. Cliquez sur le
Lien : <A 4
HREF=https://bank.com...
L’attaquant récupère
les codes d’accès
Envoi d’un email bancaire de la
Victim
avec un lien victime e
malicieux La victime saisit les Le serveur envoi une page à
1 info
Avant de valider
Profil client :
La victime pour saisir son
profil
6
Nom
Age 5
Adresse
Id Serveur
Attaquan Mot de bank.co
passe
t m
• Dans cet exemple un attaquant forge un e-mail contenant un script malicieux et l’envoi à la victime :
• <A HREF=https://bank.com/registration?clientId=<script>code malicieux</script>>Cliquer ici</A>
• Si la victime clique sur le lien, l’URL invoque le site bank.com avec le code malicieux ;
• Le site légitime bank.com retourne une page web à la victime incluant le code malicieux qui est exécuté sur le poste de la victime.

Attaque XSSi pour le vol de cookies utilisateur
Les cookies de la Victim

victime sont transmis
au serveur malveillant e
Serveur La victime invoque la page Web infectée
malveillan 4 2
t
Page web
La victime accès à la page Web et la
XSSi s’exécute dans son navigateur infectée par
une XSSi
3
Un attaquant a trouvé le moyen d’injecter une XSS stockée
1
stockée
dans une page web d’une webapp légitime
Attaquan Serveu
t r
légitime

Attaque XSSi pour l’élévation de privilèges
1 Bonjour
La victime clique sur
le
Interne Message important. Cliquez sur lien malicieux
t 2 le lien : <A
HREF=https://legitime.com...
Victim
Envoi d’un email
avec un lien e Le code
malicieux Le serveur envoi une page à
malicieux
5 s’exécute la victime avec le code
malicieux
4 Page web + code

malicieux 3
Attaquan Serveur
t legitime.co
Une requête que seule la victime peut invoquer est
m
transmise
au serveur légitime grâce au code malicieux

Attaque XSSi dans un champ texte libre
Laissez votre Une utilisatrice visite Commentaire :

commentaire : la page web où sont François, J’aime ton blog
J’aime ton blog déposés les
<script>alert(«Hello commentaires Laissez votre
World»)
commentaire :
</script>
Attaquant Utilisatric
(pseudo : e
François) Un attaquant insère dans un
commentaire du code Le code malicieux inclus dans le
javascript commentaire de François s’exécute sur
le poste de l’utilisatrice
Le commentaire est
Stocké en base de
données
Base de WebAp
données p
Une popup apparaît à l’écran

Exemple : injection XSS réfléchie
• Grâce à l’injection XSS <script>alert(‘XSSi’)</script> dans le champs Login du formulaire,

• l’affichage d’une popup javascript prouve la vulnérabilité ;
• Cette vulnérabilité reste possible par l’absence de filtrage du champs Login ainsi que
• l’affichage du login saisi sur la page web après validation.

Exemple: injection XSS stockée
• Grâce à l’injection XSS dans le champ Comment avec la valeur :

• "<audio src=1 onerror=alert(/xssi/);>", l’affichage d’une popup javascript prouve la
• vulnérabilité ;
• Cette vulnérabilité reste possible par l’absence de filtrage.

Exemple: défiguration d’une page web

Rappels sur le langage SQL
Le langage SQL (Structured Query Language), est un langage de programmation conçu pour
gérer et manipuler des bases de données relationnelles. Il offre une interface standardisée
permettant aux utilisateurs de communiquer avec les systèmes de gestion de bases de
données (SGBD) tels que MySQL, PostgreSQL, Microsoft SQL Server, Oracle, et d'autres.

Principales caractéristiques du langage SQL
Création, modification et suppression de données dans une base de données ;
Interrogation des données stockées dans une base de données ;
Définition de la structure des données dans une base de données. Cela inclut la création
et la gestion de tables, d'index, de contraintes, de vues et d'autres objets de base de données ;
Définir et gérer les droits d'accès aux données et aux fonctionnalités de la base de données ;
Prise en charge les transactions qui permettent d'assurer la cohérence et l'intégrité des données,
même en cas d'échec d'une opération.

Injection SQL

L'injection SQL (SQLi) est une technique visant à exploiter les failles de sécurité

inhérentes aux entrées non validées afin de faire passer des commandes SQL

à travers une application web pour qu'elles soient exécutées par une base de

données ;

Un pentester utilise différentes techniques d’injection pour tester une application

web afin de découvrir des SQLi ;

Les tests SQLi réalisés par un pentester peuvent être manuels et/ou automatisés ;

Une SQLi est bien une faille applicative web et non une vulnérabilité issue d’un

serveur d’une base de données ou d’un serveur web.

Injection SQL : quelques chiffres

En 2012, 97 % des violations de données étaient dues à des injections SQL.

Aujourd’hui, ce chiffre reste élevé, mais il est beaucoup plus facile à gérer ;

En 2023, les injections SQL restent l’une des attaques les plus courantes sur le web.

Rien qu’en 2022, 1162 vulnérabilités liées aux injections SQL ont été ajoutées à la

base de données de sécurité CVE ;

La bonne nouvelle, c’est que les injections SQL ne sont plus aussi répandues

qu’auparavant. La plupart des applications ont évolué pour se protéger contre

les attaques SQL.

L’actualité SQLi
Le fléau persistant des attaques Des failles par injection SQL Vulnérabilité d’injection SQL
par injection SQL et XSS ciblant des entreprises découverte dans plugin de formulaires
(LMI - 18 Juillet 2022) françaises aux enchères de contact pour WordPress
(LMI - 5 Mai 2021) (Guide Wordpress – 3 Novembre 2023)
PrestaShop vulnérable à Une faille critique met à mal La sécurité des WAF cassée par
une attaque de type injection SQL la sécurité de Magento des chercheurs en sécurité chinois
(KookiApps – 30 Mars 2023) (LMI – 1 Avril 2019) (LMI – 16 Mai 2022)
Références :
https://www.lemondeinformatique.fr/actualites/lire-le-fleau-persistant-des-attaques-par-injection-sql-et-xss-87320.html
https://www.lemondeinformatique.fr/actualites/lire-des-failles-par-injection-sql-ciblant-des-entreprises-francaises-aux-encheres-82834.html
https://www.guide-wordpress.fr/news-wordpress/vulnerabilite-dinjection-sql-decouverte-dans-le-populaire-plugin-fluent-forms-constructeur-de-formulaires-de-contact-pour-wordpress/
https://www.kookiapps.fr/faille-de-securite-prestashop/
https://www.lemondeinformatique.fr/actualites/lire-une-faille-critique-met-a-mal-la-securite-de-magento-74843.html
https://www.lemondeinformatique.fr/actualites/lire-la-securite-des-waf-cassee-par-des-chercheurs-en-securite-chinois-86777.html

Fonctionnement d’une application web
Requête http
Utilisateur Internet Firewall Serveur web Serveur Base de données

d’application
SELECT * from users where id = 6534

Comprendre une SQLi
• texy45’ or 1=1 -- • Un hacker lance une attaque SQLi

• leonardovinci
SELECT Count(*) FROM Users WHERE UserName=’ ?’ AND Password=’ ?’

• =1 si UserName et Password matchent dans la table Users
SELECT Count(*) FROM Users WHERE UserName=’texy45’ or 1=1 --’ AND Password=’leonardovinci’
SELECT Count(*) FROM Users WHERE UserName=’texy45’ or 1=1 --’ AND Password=’leonardovinci’
Requête SQL exécutée Code en commentaires et donc
non exécuté
Le hacker est authentifié !!!

Impacts applicatifs d’une SQLi
Contournement de Un attaquant peut s’authentifier à une application sans connaître

l’authentification les secrets de connexion
Divulgation d’information Un attaquant peut obtenir des informations sensibles enregistrées

dans la base de données
Compromission de l’intégrité des Un attaquant peut modifier le contenu d’une base de données,
données d’une base de données insérer des données malveillantes dans les pages web
Compromission de la Un attaquant peut supprimer les données en base de données,

disponibilité des données d’un supprimer les logs ou altérer toute information enregistrée en base
base de données de données
Exécution de code sur le serveur Un attaquant peut exécuter du code et compromettre ainsi le
cible système

SQLi « classique »

SQLi classique: implique l'insertion de requêtes SQL malveillantes directement

dans les champs d'entrée, exploitant ainsi les vulnérabilités de l'application ;

Blind SQLi

Les attaquants exploitent les vulnérabilités sans obtenir directement les résultats

de la requête, mais en discernant les réponses par des techniques telles que les

erreurs de la base de données ou les retards temporels ;
• Content-based SQLi : réalise une injection SQL en utilisant le contenu de la page

• de réponse obtenue à partir de requêtes qui renvoient "VRAI" ou "FAUX" ;
• Timing Based SQLi : réalise une injection SQL en utilisant le temps de réponse
• du serveur web à une requête normale.
• Exemple d’injection Time Based Blind SQLi :


; IF (LEN(DB_NAME())=4) WAITFOR DELAY ‘00:00:10’--

Union-based SQLi
• Union-based SQLi: se produit lorsque l'attaquant utilise l'opérateur UNION pour

• combiner les résultats d'une requête injectée avec ceux d'une requête existante ;
• Exemple d’injection Union-based SQLi :


‘ UNION SELECT username FROM users --

Error-based SQLi
• Élabore des requêtes d'injection sql à l'aide des messages d'erreur obtenus ;
• Les erreurs générées par la base de données sont exploitées pour obtenir des informations sensibles.
• Exemples d’injections Error-based SQLi :


‘

‘ or 1=1 --
• Grâce à l’injection SQL ‘ or 1=1 -- , un message d’erreur SQL est retourné par le serveur de base de données ;
• On apprend que le type de serveur bdd est MySQL ;
• On identifie également un point d’injection SQL à travers le paramètre id ;
• L’erreur SQL dévoile également la structure de la bdd avec les tables pmw_info et pmw_infoclass.

Méthodologie de recherche d’une SQLi
01 Identifier les points d’injection

02 Identifier le type du serveur de base de données
03 Déterminer le schéma de la base de données
04 Extraire les données de la base
05 Altérer les données en base
06 Réaliser une attaque DoS
07 Contourner l’IDS
08 Contourner l’authentification
09 Exécuter une commande à distance
10 Escalade de privilèges

Tests SQLi manuels vs Tests SQLi automatisés

Chaque méthode de pentest SQLi a ses forces et ses faiblesses ;

Un test SQLi manuel reste complexe et long, mais il s'agit d'une méthode complète

pour évaluer la cible par rapport à toutes les vulnérabilités possibles en matière

d'injection de code SQL ;

Un test SQLi automatisé prend moins de temps, mais ne peut évaluer la cible que

sur la base de vulnérabilités SQLi classiques ;

Il est conseillé de réaliser des tests SQLi manuels et automatisés sur la cible.

Acquérir une cible
• Avant de pouvoir attaquer une cible, il est nécessaire d’identifier une cible ;
• Pour acquérir une cible, il est possible d’utiliser différentes techniques dont celle faisant
• appel au Google Hacking ;
• Google Hacking est la technologie de recherche avancée de Google ;
• A partir d’une utilisation de différentes commandes avancées, il est possible d’obtenir une
• liste de sites web répondant à des critères spécifiques de sélection.
inurl:index.php?id=
inurl:article.php?ID=
inurl:pageid=
inurl:

Identification des points d’injection SQL

Lister tous les points d'entrée à partir desquels l'application construit des instructions
SQL au niveau du back-end à partir des données fournies par l'utilisateur ;

La plupart des points d’entrée pour les SQLi sont :

Les formulaires d’authentification ;

Les paramètres passés dans les URLs HTTP GET et POST ;

Les champs texte libres des formulaires web (commentaires, adresses,…) ;

Pages web liées à un compte financier ou à un compte de commerce électronique ;

Valeurs d'entrée des formulaires web ;

Cookies, Host, Referer, User-Agent ;

...

Identification manuelle des points d’injection SQL
Pour notre exemple: http://framingworkshop.je/photoclub/index.php?module=news&pId=101&id=%27
L’erreur SQL générée suite à l’injection confirme le point d’injection

Identification des points d’injection SQL avec SQLMap
• Lancer SQLMap depuis Kali Linux ;
• Exécuter la commande ci-dessous afin d’identifier les points d’injection SQL pour une requête GET :

sqlmap -u <url>

Identification du serveur de base de données
• Souvent, l’injection SQL dans un paramètre retourne l’empreinte du serveur

• de base de données
Type de base de données utilisée par la

webapp

Identification de la base de données avec SQLMap
• Lancer SQLMap depuis Kali Linux ;
• Exécuter la commande ci-dessous afin d’identifier les bases de données:


sqlmap -u <url> --dbs
PHP 5.3.29
Apache
MySQL ≥ 5.0
Base de données

Identification des tables avec SQLMap
• Exécuter la commande ci-dessous afin d’identifier les tables de la base de données:


sqlmap -u <url> -D <base de données> --tables
Base de données

Identification des colonnes d’une table avec SQLMap
• Exécuter la commande ci-dessous afin d’identifier les colonnes de la table :


sqlmap -u <url> -D <base de données> -T <table> --columns
Base de données

Extraction des données d’une table avec SQLMap
• Exécuter la commande ci-dessous afin de dumper une table :


sqlmap -u <url> -D <base de données> -T <table> --dump

Best practices pour éviter les SQLi

De manière générale, il faut filtrer (sécuriser) l’ensemble des informations que le serveur

reçoit avant qu’elles ne soient interprétées par le moteur d’exécution du serveur de base

de données ;

Utiliser les requêtes SQL préparées (PHP: prepare; JAVA: PreparedStatement ) ;

L’ANSSI mentionne qu’il faut toujours filtrer côté client en complément du côté back-end;

Pour filtrer les données en entrée, utiliser des expressions régulières (regex) ;

Le développeur ne doit pas « réinventer la roue » ! Il doit utiliser des frameworks pour ses

développements (Python : Django ; PHP : Symfony ; Drupal ; Wordpress ; Ruby on Rails) ;

Penser à utiliser les préconisations contre les SQLi présentes dans le WSTG v4.2 de

l’OWASP.

Cross-Site Request (CSRF)
Une attaque CSRF (Cross-Site Request Forgery) est une attaque de sécurité qui exploite la
confiance entre un utilisateur et un site web auquel il est authentifié. L'attaque CSRF vise à
effectuer des actions non autorisées CRUD (création, modification, suppression) sur un site web
en utilisant les informations d'authentification de l'utilisateur légitime, sans que ce dernier en soit
conscient.
Impacts d’une attaque CSRF :


L'impact des attaques CSRF peut être grave, allant de transferts de fonds non autorisés et de
vols d'identité à la modification/suppression d'informations de compte cruciales.

De plus, ces attaques peuvent ternir la réputation d'un site web et éroder la confiance des
utilisateurs, entraînant des conséquences juridiques et des pertes financières pour les
entreprises.

Comment les attaques CSRF fonctionnent ?
Exécution de la requête forgée

Pour un retrait bancaire
3
1 à l’insu de la victime
La victime est connectée

sur le serveur bank.com 4 Consultation standard de
la page par la victime qui
ne s’est rendu compte de Serveur
Victime rien bank.com
2
Envoi d’un email
avec un lien malicieux
Attaquant
L’attaquant souhaite réaliser un transfert bancaire pour son compte en se faisant passer pour la victime

Conditions nécessaires à une attaque CSRF
L’ authentification doit être basée uniquement sur les cookies. Le déclenchement de

l’attaque implique une ou plusieurs requêtes HTTP et l’application s’appuie seulement sur les
cookies pour permettre l’authentification de l’utilisateur (cf. transfert du contexte dans le
navigateur).
Tous les paramètres de requête doivent être prévisibles. Les requêtes contiennent des
paramètres dont l’attaquant peut déterminer ou deviner les valeurs (cf. token anti-csrf dont la
valeur est imprévisible)
L’application cible doit contenir une fonctionnalité intéressante et/ou critique pour un
attaquant. Plusieurs cas possibles : des fonctionnalités liées à des niveaux de droits élevés,
des actions qui modifieront des données spécifiées par l’utilisateur, etc.

Comment se protéger contre les attaques CSRF ?
Implémenter des jetons CSRF pour prévenir les attaques : les jetons CSRF sont des valeurs
uniques générées aléatoirement côté serveur et envoyées au client.
Elles permettent de renforcer la sécurité d’une application en rendant difficile (voire impossible)
pour un attaquant de les deviner et donc d’exploiter une vulnérabilité CSRF.
On peut imaginer un jeton CSRF comme « une session dans une session applicative »

Injection de commande

L'injection de commande du système d'exploitation permet à un hacker

d'exécuter des commandes du système d'exploitation sur le serveur qui exécute
une application, et généralement de compromettre complètement l'application et
ses données.

Souvent, un attaquant peut tirer parti d'une vulnérabilité liée à l'injection de
commandes pour compromettre d'autres parties de l'infrastructure d'hébergement et
exploiter les relations de confiance pour faire pivoter l'attaque vers d'autres
systèmes au sein de l'organisation.

Comment fonctionne une injection de commande ?

Hypothèses :

Dans cet exemple, une application d'achat permet à l'utilisateur de savoir si un article est en
stock dans un magasin particulier. Cette information est accessible via une URL:
https://insecure-website.com/stockStatus?productID=381&storeID=29

Pour fournir les informations sur les stocks, l'application doit interroger divers systèmes
existants. Pour des raisons historiques, la fonctionnalité est mise en œuvre en faisant appel à
une commande shell avec les identifiants du produit et du magasin comme arguments :
stockreport.pl 381 29

Cette commande affiche l'état des stocks de l'article spécifié, qui est renvoyé à l'utilisateur.
L'application web n'implémente aucune défense contre l'injection de commande, de sorte qu'un
attaquant peut soumettre l'entrée suivante pour exécuter une commande arbitraire : && echo
aiwefwlguh &&

Comment fonctionne une injection de commande ? (suite)

Résultats :

Si cette entrée est soumise dans le paramètre productID, la commande exécutée par
l'application est la suivante : stockreport.pl && echo aiwefwlguh && 29

La commande echo permet à la chaîne de caractères fournie d'être répercutée dans la
sortie. C'est un moyen utile de tester certains types d'injection de commandes du système
d'exploitation. Le caractère & est un séparateur de commandes de l'interpréteur de
commandes. Dans cet exemple, il provoque l'exécution de trois commandes distinctes, l'une
après l'autre. La sortie renvoyée à l'utilisateur est la suivante :
Error - productID was not provided
aiwefwlguh
29: command not found

Injection de commande : commandes utiles

Après avoir identifié une vulnérabilité d'injection de commande, il est utile d'exécuter
quelques commandes initiales pour obtenir des informations sur le système.

Une injection de commande ne pourra être exécuté que si l’utilisateur sous lequel
« tourne » la webapp a les droits suffisants ;

Ci-dessous quelques commandes utiles sur les plateformes Linux et Windows :
Commande Linux Windows

Nom de l’utilisateur whoami whoami
OS uname -a ver
Configuration réseau ifconfig ipconfig /all
Connexions réseau netstat -an netstat -an
Processus ps -ef tasklist

Exemple d’injection de commande
Nom de la requête
Exécution de la requête
1) A la création d’une requête on doit nommer cette dernière (par exemple : <nom requête>) ;
2) Si la requête est exécutée, un fichier SQL est généré à partir de cette requête. Ce fichier
prend pour nom exec_<n° d’ordre>_<nom requête>.sql
3) Ce fichier est passé en paramètre de la commande postgresql psql ;
4) Si on nomme la requête de la manière suivante : <nom requête>.sql || <commande OS> ;

alors les paramètres passés à la commande psql seront : psql <paramètres autres….>
exec_<n° d’ordre>_<nom requête>.sql || <commande OS> ; .sql
Exemple d’injection de commande (suite)
 La commande OS sera exécutée quelque soit le résultat de l’exécution du script associé

à la requête ;
 Le résultat de l’exécution de la commande ls -l est consultable dans le fichier log.
ls -l

Inclusion de fichier
L'inclusion de fichiers locaux (LFI) est le processus d'inclusion de fichiers présents

localement sur le serveur, par l'exploitation de procédures d'inclusion vulnérables
implémentées dans l'application.
Bien que la plupart des exemples concernent des scripts PHP vulnérables, il convient de
garder à l'esprit que ce phénomène est également courant dans d'autres technologies,
telles que JSP, ASP, etc. d'autres.

Inclusion de fichier (suite)
Cette vulnérabilité survient, par exemple, lorsqu'une page reçoit, en entrée, le chemin
du fichier qui doit être inclus et que cette entrée n'est pas correctement analysée, ce
qui permet d'injecter des caractères de traversée de répertoire (tels que point-point-
oblique).

Inclusion de fichier (suite)
Cela peut conduire à l'affichage du contenu du fichier, mais en fonction de la gravité, cela
peut également conduire à :

l'exécution de code sur le serveur web ;

l'exécution de code côté client, tel que JavaScript, qui peut conduire à d'autres
attaques telles que le cross site scripting (XSS) ;

le déni de service (DoS) ;

la divulgation d'informations sensibles.
Remédiation :

Éviter de transmettre des données d’entrée soumises par l’utilisateurà un système de
fichier ;

Maintenir une liste de fichiers autorisés qui peuvent être inclus par la page et utiliser un
identifiant pour accéder au fichier ;

Webshells
Un web shell est un script ou un programme informatique malveillant qui est

généralement injecté dans un serveur web afin de fournir à un attaquant un accès à
distance non autorisé.
Ce type d'outil est souvent utilisé dans le cadre d'attaques visant à compromettre des
sites web, des serveurs web ou d'autres systèmes en exploitant des vulnérabilités de
sécurité.

Webshells : upload de fichier malicieux
Si le serveur est configuré pour exécuter du code, il peut être possible d'obtenir
l'exécution de commandes sur le serveur en téléchargeant un fichier connu sous le nom
de web shell, qui permet d'exécuter du code arbitraire ou des commandes du système
d'exploitation.
Le téléchargement de ce type d'interpréteur de commandes sur un serveur Internet est

dangereux, car il permet à quiconque connaît (ou devine) l'emplacement de l'interpréteur
de commandes d'exécuter du code sur le serveur.
Remédiation :
-Charger l'interpréteur de commandes avec un nom généré de manière aléatoire
-Protéger le shell par un mot de passe
-Mettre en place des restrictions basées sur l'IP sur l'interpréteur de commandes
-Interdire certains suffixes de fichiers exécutables (php, jsp, aspx,...)

Webshells : la méthode HTTP PUT
En utilisant la méthode PUT, un attaquant peut être en mesure de placer un contenu

arbitraire et potentiellement malveillant dans le système, ce qui peut conduire à l'exécution
de code à distance, à la défiguration du site ou à un déni de service.
Si la méthode HTTP PUT n'est pas autorisée pour l'URL de base ou la requête, il faut
essayer d'autres chemins dans le système.
NOTE: lors d’une campagne de pentests, après avoir réussi à télécharger un webshell, il
est « normal » de le supprimer ou de s’assurer que l'équipe de sécurité de la cible est au
courant et qu'elle supprime le composant rapidement après votre PoC.
Les phases
d’intrusion
Post-exploitation

Phase de post-exploitation
• Consolidation d’un accès à un système compromis à travers :


L’exfiltration d’informations ;

L’escalade de privilèges ;

L’exploration de fichiers sensibles ;

L’installation de back-doors ;

Le pivoting (rebond sur un autre serveur à partir de la machine compromise) ;

La recherche de moyens pour rester indétectable.
• Objectif : maintenir un accès continu et maximiser l’exploitation du système compromis.

Phase de post-exploitation
Post-exploitation Objectif Technique utilisée

Escalade de Acquérir les droits d’un autre Exploiter des vulnérabilités
privilèges utilisateur ou de l’admin connues du système
Chevaux de Troie,
Exécution Créer ou maintenir un accès
Spywares, Backdoors,
d’applications distant
Keyloggers
Cacher les activités

Cacher des fichiers malveillantes et les vols de Rootkits, stéganographie
données
Collecter les données

Exfiltrer des sensibles / personnelles /
Malwares, canaux cachés,
données secrètes
vulnérabilités réseau
Accéder à un autre serveur

Tunnel, services exposés,
Pivoting depuis la machine
partages réseau
compromise

Escalade de privilèges
-Un attaquant peut accéder au réseau en utilisant un compte d'utilisateur non

administrateur, et l'étape suivante consisterait à obtenir des privilèges
d’administrateur ;
-L'attaquant effectue une attaque par escalade des privilèges qui tire parti des
défauts de conception, des erreurs de programmation, des bogues et des oublis
de configuration dans le système d'exploitation et l'application logicielle pour
obtenir un accès administratif au réseau et à ses applications associées ;
-Ces privilèges permettent à l'attaquant de consulter des informations critiques /

sensibles, de supprimer des fichiers ou d'installer des programmes malveillants
tels que des virus, des chevaux de Troie, des vers, etc.

Types d’escalade de privilèges
Escalade de privilège verticale :

-L'objectif est d'obtenir des privilèges plus élevés que ceux qui existent déjà.
Escalade de privilège horizontale :

-Désigne le fait d'acquérir le même niveau de privilèges que ceux déjà accordés,
mais en prenant l'identité d'un autre utilisateur disposant de privilèges similaires.

Escalade de privilèges par piratage de DLL
-Le piratage de DLL consiste à insérer du code malveillant dans une application pour
infecter le chargement des DLL (Dynamic Link Library) ;
-Le piratage de DLL exploite les plates-formes Windows et peut compromettre

l’ensemble d’un système avec un seul fichier infecté ;
-Lorsque qu’attaquant introduit un fichier infecté sur votre ordinateur, ce fichier est
exécuté au lancement de l’application vulnérable au piratage de DLL.

Exécution d’applications
L'attaquant exécute des programmes malveillants à distance sur l'ordinateur

de la victime afin de :
-Recueillir des informations qui conduisent à l'exploitation ou à la perte de données
privées ;
-Obtenir un accès non autorisé aux ressources du système ;
-Déchiffrer le mot de passe ;
-Faire des captures d'écran ;
-Installer une porte dérobée pour maintenir un accès facile, etc.

Cacher des fichiers par Rootkits
-Un rootkit est un programme qui dissimule sa présence ainsi que les activités
malveillantes de l'attaquant, lui accordant un accès total au serveur ;
-Un rootkit remplace certains appels et utilitaires du système d'exploitation

par ses propres versions modifiées de ces routines, ce qui compromet la sécurité
du système cible et entraîne l'exécution de fonctions malveillantes ;
-Un rootkit typique comprend des programmes de portes dérobées, des

programmes DDoS, des renifleurs de paquets, des utilitaires d'effacement de
journaux, des bots IRC, etc.

Cacher des fichiers par Rootkits
L'attaquant place un Rootkit en :

-Recherchant des ordinateurs et de serveurs vulnérables sur le web ;
-L’enveloppant dans un paquet spécial, comme des jeux ;
-L'installant sur des ordinateurs publics ou des ordinateurs d'entreprise par le
biais de l'ingénierie sociale ;
-Lançant une attaque "zero-day" (escalade des privilèges, dépassement de la
mémoire tampon, exploitation du noyau Windows, etc.).
Objectifs d’un Rootkit :

-Obtenir un accès à distance par une porte dérobée ;
-Masquer les traces des attaquants et la présence d'applications ou de processus malveillants ;
-Recueillir des données sensibles, trafic réseau, etc... du système auquel les attaquants
pourraient être restreints ou ne pas avoir accès ;
-Stocker d'autres programmes malveillants sur le système et agir comme un serveur de ressources
malveillantes.

Cacher des fichiers par Stéganographie
Qu’est ce que la stéganographie ?
-La stéganographie est une technique qui consiste à dissimuler un message

secret dans un message ordinaire et à l'extraire à destination afin de préserver
la confidentialité des données ;
-L'utilisation d'une image graphique comme couverture est la méthode la plus

répandue pour dissimuler les données dans les fichiers ;
-L'attaquant peut utiliser la stéganographie pour cacher des messages tels que
la liste des serveurs compromis, le code source de l'outil de piratage, des plans
pour de futures attaques, etc...

Les phases
d’intrusion
Masquer les traces

Masquer les traces
• Peut être incluse dans la post-exploitation.

• Masquer les traces de l’attaquant en supprimant :

Les logs ;

Les fichiers d’activités suspecte ;

Toute indication de la présence du hacker sur le système.
• Objectif : rendre plus difficile la détection de l’intrusion et prolonger l’accès non autorisé.

Masquer les traces
Une fois que les intrus ont réussi à obtenir un accès administrateur à un système,
ils essaient de brouiller les pistes pour éviter d'être détectés.
Obtention
d'un accès Masque des traces
administrateur
Utilisateur cible
Les attaquants utilisent les techniques suivantes pour masquer leurs traces sur le
système cible :
-Désactiver l'audit
-Effacer les logs
-Manipuler des logs

Avenue Alan Turing - 59410 Anzin – France
+33 3 74 01 09 84 - contact@ecole-it.com
www.ecole-it.com

16 PhasesIntrusion - 5SOA

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

16 PhasesIntrusion - 5SOA

Transféré par

Droits d'auteur :

Formats disponibles

Les phases

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

ECOLE IT – 5SOA- Année Académique 2023-2024 – © Tous droits réservés

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

SELECT * from users where id = 6534

Utilisateur Internet Firewall Serveur web Serveur Base de données

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Client Couche métier

Couche accès base de données

Firewall Serveur base de données

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

HTTP (HyperText Transfer Protocol) est un protocole (couche 7

HTTP est considéré comme un protocole sans état, ce qui signifie

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

A ce jour, il existe plusieurs versions du protocole HTTP, qui sont :

HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/1.1bis HTTP/2 HTTP/3

Le protocole une Utilisation de Clarification de

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Client « Voici le doc au format HTML, sa taille est de 3200 caractères »

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Méthode HTTP Description

GET Demande une représentation de la ressource spécifié

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Le protocole HTTP est principalement utilisé pour la communication entre un client

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

• Ils sont regroupés en différentes catégories, chacune ayant sa signification spécifique.

1xx Codes de réponse 100 : continuer

Les en-têtes HTTP permettent au client et au serveur de transmettre des informations

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Schéma User/mot de passe (facultatif) Alias serveur Port Chemin

http :// user : password @ www.evil.com : 80 /index.html

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

La prise d’empreinte d'un serveur web consiste à identifier le type et la version

La découverte précise du type de serveur web sur lequel fonctionne une

En particulier, les serveurs exécutant d'anciennes versions de logiciels sans

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Version du serveur web Produits Exploit-db.com Google Hacking

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Identification des produits et versions

Recherche des vulnérabilités publiques

Utilisation des exploits

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

01 Explorer manuellement la webapp pour identifier toutes les fonctionnalités

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Analyser minutieusement le code source HTML de la webapp

Rechercher les commentaires < !-- et les balises <META écrits

Rechercher les liens URL car ils peuvent aider à comprendre la

Rechercher la destination des attributs ‘action’ des formulaires

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Utiliser des fonctionnalités avancées des moteurs de recherche

Utiliser les commandes définis dans Google Hacking Database

Les informations collectées vont délivrer la version du serveur

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Connaître le type de WAF permet parfois d’appliquer des

Utiliser l’outil wafw00f pour détecter l’existence d’un WAF en

• Exemple : wafw00f https://www.loreal.com

ECOLE IT – 5SOA - Année Académique 2023-2024 – © Tous droits réservés

Le principe consiste à analyser la réponse du serveur afin d’en

L’information ainsi recueillie aide le pentester à sélectionner les