N: 0 0 4 / 2 0 2 1

Université Sultan Moulay Slimane

Faculté Polydisciplinaire
Département de Mathématique et Informatique
- Béni Mellal -

Master : Systèmes de Télécommunications et Réseaux

Informatique
*****

Projet de fin d’études

Pentest des applications web :

Evaluation des scanners de vulnérabilité Web à
l’aide du benchmark OWASP

Réalisé par :
BELFAIK Nissrine

Soutenue le 28/10/2021 devant le jury composé de

Président [Link] Prof. à FP, Béni Mellal

Encadrant [Link] Prof. à FP, Béni Mellal
Examinateur [Link] Prof. à FP, Béni Mellal

Année Universitaire : 2020-2021

 DÉDICACES

C’est avec une joie immense et le cœur ému que je dédie ce travail :

À mes chers parents. Mes mots ne seraient jamais à la hauteur de vos efforts et sacrifices
durant toute ma vie, ainsi vos encouragements et vos soutiens. Que ce travail traduit ma
gratitude et ma reconnaissance .

À mes chers frères et soeurs, qui ont été toujours à mes côtés pour me soutenir et m’en-
courager.

À tous les membres de ma famille.

À tous mes amis qui m’ont toujours motivé et encouragé.

À tous mes professeurs du master Système de Tèlécommunication et Réseaux Informa-

tique.

Et à tous les chers lecteurs.

2
 REMERCIEMENTS

En tout premier lieu, je remercie ALLAH de m’avoir accordé la puissance et la volonté

pour achever ce travail.

Mes plus sincères remerciements vont à mon encadrant Monsieur SADQI YASSINE
professeur à la faculté poly disciplinaire de Béni-mellal, pour son orientation, sa rigueur
au travail, ses multiples conseils, ses orientations et sa disponibilité. Je le remercie aussi
de son suivi permanent de mon travail, ses remarques et suggestions sans lesquelles ce
mémoire n’aurait pas lieu.

Mes vifs remerciements vont également à tous les professeurs qui m’ont enseigné et qui
par leurs compétences m’ont soutenu dans la poursuite de mes études.

je tiens aussi à exprimer mes sincères remerciements à chaque membre de notre équipe
‘Cybersecurity Team’ pour leurs aides et leur contribution tout au long de ce projet.

Enfin, je tiens à adresser mes remerciements à toutes les personnes qui ont contribué de
près ou de loin à l’aboutissement de ce travail.

3
 TABLE DES MATIÈRES

Dédicaces 2

Remerciements 3

Liste des abréviations 10

Résumé 11

Introduction générale 13

1 Généralités sur la sécurité web et les tests de pénétration 15

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Généralités sur la sécurité web . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.1 Les termes essentielle . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.2 Les éléments de la sécurité d’information . . . . . . . . . . . . . . 16
1.2.3 Les menaces sur la sécurité d’information . . . . . . . . . . . . . . 17
1.2.4 Le piratage et le piratage éthique . . . . . . . . . . . . . . . . . . 20
[Link] La différence entre le piratage et le piratage éthique . . . 20
[Link] Les effets du piratage sur les entreprises . . . . . . . . . 20
1.2.5 Les Risques de sécurité les plus critiques des applications web
(OWASP Top 10) . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.6 OWASP Risk Rating Methodology . . . . . . . . . . . . . . . . . 20
1.2.7 OWASP Top 10 2021 . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.8 Protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
[Link] Requête Http . . . . . . . . . . . . . . . . . . . . . . . . 33
[Link] La forme d’une Réponse Http . . . . . . . . . . . . . . . 34
[Link] Méthodes GET/POST . . . . . . . . . . . . . . . . . . . 35
[Link] En-têtes HTTP . . . . . . . . . . . . . . . . . . . . . . . 35
[Link] URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
[Link] Les cookies . . . . . . . . . . . . . . . . . . . . . . . . . 35

4
Projet de Fin d’études Pentest des applications web : . . .

1.3 Les tests de pénétration . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

1.3.1 Les types des tests de pénétration . . . . . . . . . . . . . . . . . . 38
1.3.2 Types d’exploration ou crawling . . . . . . . . . . . . . . . . . . . 38
1.3.3 Couverture du robot d’exploration . . . . . . . . . . . . . . . . . 38
1.3.4 Types de scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2 Généralités sur OWASP Benchmark et les concepts des applications

des tests de sécurité web 40
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2 Vue d’ensemble sur OWASP Benchmark . . . . . . . . . . . . . . . . . . 40
2.3 Les versions du OWASP Benchmark . . . . . . . . . . . . . . . . . . . . 41
2.3.1 Historique des versions . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.2 La différence entre les versions . . . . . . . . . . . . . . . . . . . . 42
2.4 Les catégories de cas de test dans le Benchmark OWASP . . . . . . . . . 43
2.4.1 La catégorie injection de commande . . . . . . . . . . . . . . . . . 43
2.4.2 La catégorie des algorithmes de chiffrement faibles . . . . . . . . . 43
2.4.3 La catégorie d’algorithme de hachage faible . . . . . . . . . . . . . 44
2.4.4 La catégorie des injections de type LDAP . . . . . . . . . . . . . 44
2.4.5 La catégorie Path traversal . . . . . . . . . . . . . . . . . . . . . . 45
2.4.6 La catégorie des cookies non sécurisés . . . . . . . . . . . . . . . . 45
2.4.7 La catégorie des injections de type SQL . . . . . . . . . . . . . . . 46
2.4.8 La catégorie de « trust boundary » . . . . . . . . . . . . . . . . . 46
2.4.9 La catégorie de « weak randomness » . . . . . . . . . . . . . . . . 46
2.4.10 La catégorie de « XPATH injection » . . . . . . . . . . . . . . . . 46
2.4.11 La catégorie de Cross site scripting (XSS) . . . . . . . . . . . . . 47
2.5 Les applications de test de sécurité statiques, dynamiques et interactives 47
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 Analyse du OWASP Benchmark et Évaluation comparative des scan-

ners 50
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Analyse du OWASP Benchmark par les applications de test de sécurité . 54
3.3.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.2 Le choix des outils de travail . . . . . . . . . . . . . . . . . . . . . 54
3.3.3 Analyse du Benchmark OWASP par FindBugs, SpotBugs, Find-
SecBugs et PMD . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.4 Analyse du Benchmark OWASP par OWASP ZAP . . . . . . . . 58
3.3.5 Analyse du Benchmark OWASP par ShiftLeft . . . . . . . . . . . 61
3.4 Les métriques de comparaison des performances des applications de test
de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 5/81
Projet de Fin d’études Pentest des applications web : . . .

3.5.1 Les résultats des métriques TP, FP, TN, FN . . . . . . . . . . . . 64

3.5.2 Les résultats des métriques : TPR, FPR, Score . . . . . . . . . . . 64
3.5.3 Les taux des vulnérabilités detéctés pour chaque catégorie . . . . 65
3.5.4 Les métriques de comparaison : Précision, Recall, F-value et Indice
de Youden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.5 La vitesse du scan . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.1 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Conclusion générale et perspectives 73

Annexe : Installation et configuration du Benchmark OWASP 74

Références 78
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Webographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 6/81
 TABLE DES FIGURES

1.1 Statistiques des plaintes pour la cybercriminalité par IC3 . . . . . . . . 17

1.2 Cinq principaux types de cybercriminalité . . . . . . . . . . . . . . . . . 18
1.3 Les Top 10 OWASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 La forme d’une requête HTTP . . . . . . . . . . . . . . . . . . . . . . . 33
1.5 Réponse HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.1 L’application Benchmark OWASP . . . . . . . . . . . . . . . . . . . . . 40

2.2 Les cas de test pour la catégorie command injection . . . . . . . . . . . . 41

3.1 Le graphe d’évaluation du OWASP Benchmark . . . . . . . . . . . . . . 54

3.2 L’IDE de SpotBugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 La phase du scan pour SpotBugs sur OWASP Benchmark . . . . . . . . 57
3.4 Les résultats du scan pour SpotBugs . . . . . . . . . . . . . . . . . . . . 58
3.5 Les détails des bugs détectés par SpotBugs . . . . . . . . . . . . . . . . . 58
3.6 Le processus d’analyse de OWASP ZAP . . . . . . . . . . . . . . . . . . 59
3.7 L’IDE du OWASP ZAP avec la phase du démarrage rapide effectué . . . 59
3.8 La fenêtre de technologie du OWASP ZAP . . . . . . . . . . . . . . . . . 60
3.9 La fenêtre de la progression du scan de OWASP ZAP . . . . . . . . . . . 60
3.10 Les alertes d’analyse trouvés . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.11 Authentification avec ShiftLeft sur GitHub . . . . . . . . . . . . . . . . 61
3.12 Les méthodes fournis par GitHub pour le scan . . . . . . . . . . . . . . 62
3.13 Interface de choix de scan fournis par ShiftLeft . . . . . . . . . . . . . . . 62
3.14 Les résultats obtenus après le scan . . . . . . . . . . . . . . . . . . . . . 63
3.15 Les catégories des vulnérabilités trouvées après le scan . . . . . . . . . . 63
3.16 Les scores enregistrés pour chaque scanner de test . . . . . . . . . . . . 65
3.17 Les taux des vulnérabilités détectés . . . . . . . . . . . . . . . . . . . . . 66
3.18 Les taux des vulnérabilités détectés . . . . . . . . . . . . . . . . . . . . . 68
3.19 Précision, Recall, F-value pour les scanners de test . . . . . . . . . . . . . 69
3.20 Indice de Youden pour les scanners de test . . . . . . . . . . . . . . . . . 69
3.21 Guide d’interprétation du OWASP WBE . . . . . . . . . . . . . . . . . 70

7
Projet de Fin d’études Pentest des applications web : . . .

A.1 L’interface GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.2 L’ajout du apache-maven-3.8.1 à la path . . . . . . . . . . . . . . . . . . 74
A.3 L’exécution de la commande pour apache-maven . . . . . . . . . . . . . 75
A.4 L’exécution de la commande pour Java . . . . . . . . . . . . . . . . . . . 75
A.5 Importer le Benchmark OWASP de GitHub . . . . . . . . . . . . . . . . 75
A.6 Exécution de la commande « mvn compile » . . . . . . . . . . . . . . . . 76
A.7 Compilation du OWASP Benchmark . . . . . . . . . . . . . . . . . . . . 76
A.8 Compilation et exécution du OWASP Benchmark . . . . . . . . . . . . . 76
A.9 Compilation et exécution du OWASP Benchmark . . . . . . . . . . . . . 77

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 8/81
 LISTE DES TABLEAUX

1.1 Différences entre un test automatique et un test manuel . . . . . . . . . 37

2.1 Les domaines et le nombre de cas de test pour les versions de Benchmark
OWASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2 Procédure d’analyse des SAST, DAST et IAST . . . . . . . . . . . . . . 48
2.3 Les caractéristiques des SAST, DAST et IAST . . . . . . . . . . . . . . . 49

3.1 Les métriques des scanners de test : TP, FP, TN et FN . . . . . . . . . . 64

3.2 Les métriques des scanners de test : TPR, FPR et Score . . . . . . . . . 65
3.3 Les métriques de comparaison : Précision, Recall, F-value et Youden Index 68
3.4 La vitesse du scan des outils de test . . . . . . . . . . . . . . . . . . . . 71

9
 LISTE DES ABRÉVIATIONS

— OWASP : Open Web Application Security Project

— SAST : Static Application Security Testing
— DAST : Dynamic Application Security Testing
— IAST : Interactive Application Security testing
— CWE : Common Weaknesses Enumeration
— SQLI : Script Query Language Injection
— LDAPI : Structured Query Language Injection
— XSS : Cross Site Scripting
— PFS : Perfect Forward Secrecy
— TLS : Transport Layer Security
— NIST : National Institute of Standards and Technology
— HTTP : Hypertext Transfer Protocol
— HTML : Hypertext Markup Language
— URL : Uniform Resource Locator
— URI : Uniform Resource Identifier
— TP : True Positive
— FP : False Negative
— TN : True Negative
— FN : False Negative
— TPR : True Positive Rate
— FPR : False Positive Rate
— IC3 : Internet Crime Complaint Center
— PRNGs :Standard pseudo-random number generators

10
 RÉSUMÉ

Résumé
L’exigence d’effectuer les tests de sécurité a augmenté avec le développent croissant
d’Internet à cause des cyberattaques qui n’hésitent pas d’attaquer les systèmes d’infor-
mations et exploiter les vulnérabilités existant dès qu’ils soient divulgués afin de briser
la sécurité du système et accéder aux données sensibles.

Pour faire face à ces malveillances, il est nécessaire d’utiliser des outils de sécurités
qui vont nous informer sur les faiblesses de conception, les failles et les défauts techniques
ainsi, identifier les menaces de sécurité sur l’application web cible afin d’améliorer l’in-
frastructure de ces systèmes de sécurité et éviter prochainement les problèmes liés aux
attaques malveillants.

Dans ce travail, nous avons testé les performances des applications de test de sécurité :
FindBugs v3.0.1, SpotBugs v4.2.3, PMD v 6.29.0, FindSecBugs v1.11.0, OWASP ZAP
v2.10.0 et ShiftLeft, en effectuant le scan pour chaque outil sur l’application cible OWASP
Benchmark v1.2, cette dernière contient des cas de test bien définies des catégories de
la liste CWE. Ainsi, l’évaluation expérimentale des performances de ces applications de
test de sécurité en utilisant OWASP Benchmark, par la génération du « scorecard » et
intérpreter les résultats obtenus en utilisant les métriques de comparaison. En effet, le
calcul des métriques a montré que OWASP ZAP a la meilleur valeur de précision de
detéction (97%). Ainsi, la plus grande valeur de l’indice de youden était de ShiftLeft
(0.77), aussi que la valeur de Recall (100%). De plus, FindSecBugs a pu atteindre la
valeur la plus élevé de F-value (80%). Ces résultats obtenus nous a permis de conclure
que chaque scanner a une performance qui le caractérise et le rend distinct par rapport
aux autres scanners.

Mots clés : OWASP Benchmark, application security testing, penetration testing,

vulnerability, metrics, performance, scorecard.

11
 ABSTRACT

Abstract
The requirement to perform cybersecurity has increased with the increasing deve-
lopment of the Internet due to cyber-attacks that do not hesitate to attack information
systems and exploit existing vulnerabilities as soon as they are disclosed in order to break
down system security and access sensitive data.

To deal with these malicious acts, it is necessary to use security tools that will inform
us about design weaknesses and technical flaws as well, identify security threats on the
target web application in order to improve the infrastructure of these security systems
and prevent problems related to malicious attacks in future.

In this work, we tested the performance of security testing applications : FindBugs

v3.0.1, SpotBugs v4.2.3, PMD v 6.29.0, FindSecBugs v 1.11.0, OWASP ZAP v 2.10.0
and ShiftLeft by performing the scan for each tool on the target application OWASP
Benchmark v 1.2, which contains well-defined test cases from the categories of the CWE
list. Thus, the experimental evaluation of the performance of these security test appli-
cations using OWASP Benchmark, by generating the "scorecard" and interpreting the
results obtained using the comparison metrics. Indeed, the calculation of the metrics sho-
wed that OWASP ZAP has the best detection precision value (97%). Thus, the greatest
value of the index of youden was for ShiftLeft (0.77), as well as the value of Recall (100
%). Additionally, FindSecBugs was able to achieve the highest Percentage of F-value (80
%). These results obtained allowed us to conclude that each scanner has a performance
that characterizes it and makes it distinct from other scanners.

Keywords : OWASP Benchmark, application security testing, penetration testing,

vulnerability, metrics, performance, scorecard.

12
 INTRODUCTION GÉNÉRALE

1. Contexte et problématique du projet

L’évolution des technologies de l’information et de la communication, notamment avec
le développement d’Internet, a mené les réseaux et les systèmes d’information à jouer un
rôle important dans notre société, dont la sécurité des citoyens n’est pas marginalisée. Il
est donc nécessaire pour les entreprises d’assurer une protection efficace de leur système
d’information à cause des cyberattaques qui sont de plus en plus fréquentes, et bien évi-
demment, il est très important de savoir comment nous pouvons protéger, sauvegarder
tout type d’information sensible et les systèmes d’informations contre l’accès, la divulga-
tion, l’altération, la perturbation et la destruction non autorisés. L’un des éléments clés
de ce processus de sécurisation du réseau consiste à effectuer un test de pénétration du
réseau et des applications Web.

2. Objectifs et contributions
L’objectif principale de ce travail est présenté dans l’état d’art suivante, dont on
illustre la sécurité des applications Web :
— L’identification des problèmes liés à la sécurité de ces applications.
— L’étude des risques les plus critiques des applications web en se basant sur la
classification d’OWASP.
— Etude des composants du Benchmark OWASP et les catégories des vulnérabilités
qu’elle contient.
— Analyser le Benchmark OWASP v1.2 par des applications de test de sécurité :
FindBugs v3.0.1, SpotBugs v4.2.3, PMD v 6.29.0, FindSecBugs v 1.11.0, OWASP
ZAP v 2.10.0 et ShiftLeft.
— Evaluation expérimentale des performances des applications de test de sécurité
choisi en utilisant les résultats d’évaluation obtenues par le Benchmark OWASP
en se basant sur les métriques de comparaison.

13
Projet de Fin d’études Pentest des applications web : . . .

3. Organisation du rapport
Ce mémoire regroupe l’ensemble des travaux effectués. Il est constitué de quatre
chapitres, et une conclusion générale.
Le chapitre actuel présente une introduction générale dont on a présenté le contexte,
problématique et objectif du travail.
Le chapitre 1 donne une vue générale sur les applications web et la sécurité infor-
matique dont la première partie est consacré pour présenter les éléments de la sécurité
d’information, et ensuite décrire les diverses menaces sur les systèmes d’information puis,
nous avons illustré les concepts des tests de pénétration. Et finalement, nous avons pré-
senté les principes, les formes, quelques exemples et les mécanismes de préventions des
dix risques de sécurité les plus critiques des applications web OWASP Top 10 2021.
Nous avons abordé le chapitre 2 par une vue d’ensemble sur le Benchmark OWASP,
ses composants et ses versions, ensuite nous arrivons à la déscription des catégories de
test que le Benchmark OWASP contient, et la dernière partie de chapitre présente le
processus du scan des applications de test de sécurité SAST, DAST et IAST, ainsi leurs
caractéristiques.
Le chapitre 3, présente la méthodologie de travail, le processus d’analyse pour
chaque scanner sur OWASP Benchmark, ainsi l’évaluation et l’interprétation des ré-
sultats obtenus en se basant sur les métriques de comparaison sur lesquelles on a pu
déterminer les performances de chaque scanner.
Enfin, la conclusion générale récapitulera le travail réalisé et exposera les perspectives
éventuelles du projet.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 14/81
CHAPITRE 1
GÉNÉRALITÉS SUR LA SÉCURITÉ WEB ET LES TESTS
DE PÉNÉTRATION

1.1 Introduction
Pour la plupart des organisations, les informations sont la ressource essentielle à
sécuriser. Si des informations sensibles tombent entre des mauvaises mains, l’organisation
concernée peut faire face à une menace grave[27].
Dans ce chapitre nous examinerons un aperçu sur la sécurité d’information. En effet,
nous allons présenter les problèmes liés à la sécurité des applications web et les dix risques
de sécurité les plus critiques des aplications web. Ensuite, nous allons donner une vue
générale sur les tests de pénétration ou PEN Test qui est un processus d’identification
des vulnérabilités de sécurité dans le système.

1.2 Généralités sur la sécurité web

1.2.1 Les termes essentielle
— La valeur du piratage :
Les pirates informatiques trouvent que le piratage vaut la peine d’être fait ou c’est
quelque chose intéressant, c’est-à-dire les pirates pensent que briser la sécurité du
réseau le plus dur pourrait leur donner une grande satisfaction, et que c’est quelque
chose qu’ils ont accompli que tout le monde ne pourrait pas faire.
— Exploiter :
C’est le fait d’attaquer un système ou un réseau informatique afin de violer sa
sécurité via une vulnérabilité. Un exploit peut également être défini comme un
logiciel malveillant ou des commandes pouvant causer un comportement imprévu
sur des logiciels ou du matériel légitimes en tirant parti des vulnérabilités.

15
Projet de Fin d’études Pentest des applications web : . . .

— Vulnérabilité :
Existence d’une faille, faiblesse, une limitation ou d’une erreur de mise en œuvre
pouvant conduire à un événement inattendu et indésirable et qui devient une source
pour un attaquant d’entrer dans le système et accéder à des données autrement
sécurisées.
— Objectif de l’évaluation :
Un système informatique, un produit ou un composant qui est soumis à une éva-
luation de sécurité afin d’aider l’évaluateur à comprendre le fonctionnement, la
technologie et les vulnérabilités d’un système ou d’un produit particulier.
— Zero-day attaques :
Si un pirate parvient à exploiter la vulnérabilité avant que les développeurs de
logiciels puissent trouver un correctif, cet exploit devient une attaque zero-day.
— Daisy chainning :
Les attaquants accomplissent généralement leur tâche, puis reviennent en arrière
pour couvrir leurs traces en détruisant les logs, etc. En outre ils prennent le contrôle
d’autres systèmes et les utilisent pour des activités malveillantes, et par suite il
devient difficile de les identifier.
— Un vecteur d’attaque :
Est un chemin ou un moyen par lequel un attaquant accède à un système d’infor-
mation pour effectuer des activités malveillantes. Ce vecteur d’attaque permet à
un attaquant de profiter des vulnérabilités présentes dans le système d’information
pour mener une attaque particulière.

1.2.2 Les éléments de la sécurité d’information

La sécurité d’information est un processus visant à protéger des données contre l’ac-
cès, l’utilisation, la diffusion, la destruction, ou la modification non autorisée. Il repose
sur les cinq éléments principaux suivants : confidentialité, intégrité, disponibilité, au-
thenticité et non répudiation.[27]

— La confidentialité :
Il s’agit de garantir le secret de l’information transmise ou archivée et Seuls les
utilisateurs autorisés doivent y avoir accès.
— L’intégrité :
Il s’agit de préserver les informations contre les modifications. Autrement dit, c’est
la prévention d’une modification non autorisée de l’information.
— Disponibilité :
Il s’agit d’assurer que les systèmes sont responsables du transfert, du stockage et
du traitement des informations et qu’ils restent accessibles lorsqu’ils sont demandés
par les utilisateurs autorisés.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 16/81
Projet de Fin d’études Pentest des applications web : . . .

— L’authentification :
L’authentification consiste à vérifier qu’une personne possède bien l’identité, ou les
droits, qu’elle affirme avoir, c’est-à-dire confirmer qu’il est bien celui qui prétend
être et à assurer que le message est authentique et non altéré ou falsifié.
— La non répudiation :
Impossibilité, pour une personne ou pour toute autre entité engagée dans une
communication par voie informatique, de nier avoir reçu ou émis un message.

1.2.3 Les menaces sur la sécurité d’information

Les services et les possibilités offertes par les applications web d’aujourd’hui et leur
large utilisation dans divers domaines et services comme l’ecommerce, e-banking le rendre
un lieu précieux et une cible principale pour les attaquants pour exploiter et voler les don-
nées personnelles des utilisateurs comme numéro de compte, de téléphone, adresse...etc.
En mai 2000, l’IC3 a été créé en tant que centre de réception des plaintes de la cyber-
criminalité . La figure 1.1 présente les statistiques des plaintes pour la cybercriminalité,
qui sont au total, 5 679 259 plaintes ont été signalées à l’IC3 depuis sa création. Au cours
des cinq dernières années, l’IC3 a reçu en moyenne 440 000 plaintes par an. Ainsi, les
pertes financières énormes à cause de ces malveillances. [39]

Figure 1.1 – Statistiques des plaintes pour la cybercriminalité par IC3

Les actions malveillantes offensives qui visent les infrastructures, les appareils ou les
réseaux informatiques, dans le but de voler, modifier ou détruire des données, sont venu
sous forme de plusieurs types. La figure 1.2 montre les types de ces malveillances et le
pourcentage d’enregistrement au cours des cinq dernières années.[39]

Les attaquants ont généralement des motivations, des buts ou des objectifs derrière
l’exécution d’attaques de sécurité de l’information [27] :
— Les buts d’attaques : Les attaquants ont des motivations ou des objectifs tels que
perturber la continuité des affaires, vol d’informations, manipulations de données
ou vengeance.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 17/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 1.2 – Cinq principaux types de cybercriminalité

— Les motivations d’attaques : Une motivation provient de la notion que le sys-

tème cible stocke ou traite quelque chose de précieux et cela conduit à la menace
d’une attaque sur le système.
— Les objectives d’attaques : Les attaquants essaient divers outils, méthodes d’at-
taque et techniques pour exploiter les vulnérabilités d’un système informatique ou
d’une politique de sécurité et de contrôles pour atteindre leurs objectifs.

Les menaces de sécurité d’information sont classées en trois catégories, comme suit
[27] :
— Des menaces naturelles : Incluent les catastrophes naturelles telles que les trem-
blements de terre, les ouragans, les inondations ou toute autre catastrophe natu-
relle. En effet, les informations endommagées ou perdues en raison de ces menaces
ne peuvent pas être évitées car personne ne sait à l’avance que ces types de menaces
se produiront.
— Les menaces de sécurité physiques : Les menaces physiques peuvent inclure
la perte ou l’endommagement des ressources du système par le feu, l’eau, le vol et
l’impact physique. L’impact physique sur les ressources peut être dû à une collision,
intentionnel ou non. Parfois, l’alimentation peut également endommager le matériel
utilisé pour stocker des informations.
— Des menaces humaines : Incluent les menaces d’attaques effectués par des in-
ternes et des externes. En effet, les attaques internes font référence aux attaques
effectuées par des employés mécontents ou malveillants. Par contre les attaques
externes font référence aux attaques effectuées par des personnes malveillantes
n’appartenant pas à l’organisation.
Les menaces humaines peuvent être classées en trois types, comme suit [27] :

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 18/81
Projet de Fin d’études Pentest des applications web : . . .

— Les menaces sur les réseaux : Un réseau est défini comme l’ensemble des ordina-
teurs et autres matériels connectés par des canaux de communication pour partager
des ressources et des informations. Au fur et à mesure que les informations voyagent
d’un ordinateur à l’autre via le canal de communication, une personne malveillante
peut entrer dans le canal de communication et voler les informations circulant sur
le réseau.
— Les menaces sur les hôtes : Les menaces sur l’hôte sont dirigées vers un système
particulier sur lequel résident des informations précieuses. Les attaquants tentent
de violer la sécurité de la ressource du système d’information.
— Les menaces sur les applications : Si les mesures de sécurité appropriées ne sont
pas prises en compte lors du développement de l’application particulière, l’applica-
tion peut être vulnérable à différents types d’attaques d’application. Les attaquants
profitent des vulnérabilités présentes dans l’application pour voler ou endommager
les informations.
L’attaquant adopte pour pirater un système ou un réseau des différents types des
attaques, telles que les attaques du système d’exploitation et les attaques au niveau des
applications. Ainsi, un attaquant peut accéder à un système de plusieurs manières. Alors
il doit être capable d’exploiter une faiblesse ou une vulnérabilité dans un système [27] :
— Les attaques du système d’exploitation : Les attaquants recherchent les vul-
nérabilités du système d’exploitation et les exploitent pour accéder à un système
réseau. En effet, Les systèmes d’exploitation d’aujourd’hui, riches en fonctionnali-
tés, sont de plus en plus complexes. Alors que les utilisateurs tirent parti de ces
fonctionnalités, le système peut avoir des diverses vulnérabilités, attirant ainsi les
attaquants. La plupart des programmes d’installation des systèmes d’exploitation
installent un grand nombre de services et ouvrent des ports par défaut. Cette si-
tuation conduit les attaquants à rechercher des diverses vulnérabilités.
— Attaques au niveau des applications : Les applications logicielles sont livrées
avec diverses fonctionnalités, et un codage plus complexe, les développeurs né-
gligent généralement la sécurité de l’application, ce qui entraîne des vulnérabilités
dans les applications et deviennent une source d’attaque. Les attaquants trouvent
et exploitent ces vulnérabilités dans les applications utilisant différents outils et
techniques.
— Attaques de mauvaise configuration : La plupart des administrateurs n’ont
pas les compétences nécessaires pour gérer ou résoudre les problèmes, ce qui peut
entraîner des erreurs de configuration. De telles erreurs de configuration peuvent
devenir les sources permettant à un attaquant de pénétrer dans le réseau ou le
système de la cible.
— Attaques de « Shrink wrap » : Les applications du système d’exploitation sont
livrées avec de nombreux exemples de scripts pour faciliter le travail d’administra-
teur, mais les mêmes scripts présentent diverses vulnérabilités, ce qui peut conduire
à des attaques par code Shrink Wrap qui est l’acte d’exploiter des failles dans des
logiciels non corrigés ou mal configurés.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 19/81
Projet de Fin d’études Pentest des applications web : . . .

1.2.4 Le piratage et le piratage éthique

[Link] La différence entre le piratage et le piratage éthique
Le piratage et le piratage éthique peuvent être différenciés en fonction des inten-
tions des personnes qui effectuent une activité de piratage. Cependant, comprendre les
véritables intentions des pirates peut être assez difficile [27] :
— Le piratage :
Le piratage sert à l’exploitation des vulnérabilités du système et à la compromis-
sion des contrôles de sécurité pour obtenir un accès non autorisé ou inapproprié
aux ressources du système, ainsi de modifier les fonctionnalités du système ou de
l’application pour atteindre un objectif en dehors de l’objectif initial du créateur.
— Le piratage éthique :
Il s’agit de l’utilisation d’outils, d’astuces et de techniques de piratage pour identi-
fier les vulnérabilités afin d’assurer la sécurité du système, En effet il se base sur la
simulation des techniques utilisées par les attaquants pour vérifier l’existence des
vulnérabilités exploitables.

[Link] Les effets du piratage sur les entreprises

Selon l’enquête Symantec 2012 sur l’état de l’information, l’information coûte aux
entreprises du monde entier 1,1 billion de dollars par an. Ainsi que Le vol des informations
personnelles des clients peut mettre en danger la réputation de l’entreprise et entraîner
des poursuites judiciaires. Le piratage peut être utilisé pour voler, et redistribuer la
propriété intellectuelle entraînant des pertes commerciales. D’autre part les attaquants
peuvent voler des secrets d’entreprise et les vendre à des concurrents, compromettre des
informations financières critiques et divulguer des informations à des concurrents.[27]

1.2.5 Les Risques de sécurité les plus critiques des applications

web (OWASP Top 10)
Le Top 10 OWASP est un document de sensibilisation standard pour les développeurs
et la sécurité des applications Web. Il représente les risques de sécurité les plus critiques
pour les applications Web. En effet, La liste OWASP Top 10 contient les 10 princi-
pales vulnérabilités applicatives. Leur objectif principale est d’informer les développeurs,
concepteurs, architectes, managers et les entreprises aux conséquences des faiblesses des
applications web.[43]

1.2.6 OWASP Risk Rating Methodology

Depuis la version 2010, OWASP a changé sa méthodologie de classification. Elle a
passé d’une classification des failles à une classification basée sur les risques de sécurité
les plus critiques rencontrés dans les projets de développement des applications web.
Dans cette méthode, les dix failles de sécurité sont classées selon l’ordre décroissant de

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 20/81
Projet de Fin d’études Pentest des applications web : . . .

leur facteur de risque global, c’est à dire la vulnérabilité classée en première position est
celle qu’a le facteur de risque le plus élevé. Pour chaque faille, le facteur de risque globale
est calculé par la multiplication de facteur de vraisemblance (prévalence, détectabilité,
exploitabilité) et l’impact technique de la faille divisé sur 3

Σ(prévalence, détectabilité, exploitabilité)

Risk = × T echnicalImpact (1.1)
3
— Prévalence (Prevalence) : La fréquence de la faille soit elle très répandu, répandu
ou faible.
— Détectabilité (Detectability) :La fréquence de détection, c’est à dire est une vulné-
rabilité qui est facile, moyenne ou difficile à détecter.
— Exploitabilité (Exploitability) : La probabilité d’exploitation de la vulnérabilité
(faible, moyenne ou élevée).
— Impact Technique (Technical Impact) : Le résultat d’attaque sur les données et les
fonctions de l’application.

1.2.7 OWASP Top 10 2021

La figure 1.3 montre le nouveau classement du Top 10 OWASP pour l’année 2021
avec trois nouvelles catégories et quatre catégories avec des changements de nom et de
portée, et un certaine renforcement.[43]

Figure 1.3 – Les Top 10 OWASP

Ces Top 10 OWASP sont classés par ordre d’importance, et par suite nous allons pré-
senter le principe, les formes, des exemples et les mécanismes de prévention de chaque
attaque.

A1. Contrôle d’accès cassé :

Principe d’attaque :

Le contrôle d’accès cassé applique une stratégie telles que les utilisateurs ne peuvent
pas agir en dehors de leurs autorisations prévues. Les défaillances conduisent générale-
ment à la divulgation non autorisée d’informations, à la modification ou à la destruction

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 21/81
Projet de Fin d’études Pentest des applications web : . . .

de toutes les données ou à l’exécution d’une fonction commerciale en dehors des limites
de l’utilisateur. [17]

Les formes d’attaque :

Les vulnérabilités courantes de contrôle d’accès incluent :

— Transcender les contrôles d’accès en modifiant l’URL, l’état interne de l’application
ou la page HTML,
— Permettre à la clé primaire d’être remplacée par l’enregistrement d’un autre utili-
sateur, permettant de visualiser ou de modifier le compte de quelqu’un d’autre,
— Fournir un accès complet à l’utilisateur non autorisé.

Les Exemples d’attaque :

Exemple1 : L’application utilise des données non vérifiées dans un appel SQL qui
accède aux informations du compte :
[Link](1, [Link]("acct")) ;
ResultSet results = [Link]( ) ;
Un attaquant modifie simplement le paramètre ’acct’ dans le navigateur pour envoyer
le numéro de compte qu’il souhaite. S’il n’est pas correctement vérifié, l’attaquant peut
accéder au compte de n’importe quel utilisateur.
http ://[Link]/app/accountInfo ?acct=notmyacct
Exemple2 : Un attaquant force simplement les navigations vers les URL cibles. Les droits
d’administrateur sont requis pour accéder à la page d’administration
http ://[Link]/app/getappInfo
http ://[Link]/app/admin_getappInfo
Si un utilisateur non authentifié peut accéder à l’une ou l’autre des pages, c’est un défaut.
Si un non-administrateur peut accéder à la page d’administration, il s’agit d’une faille.

Les mécanismes de prévention :

Le contrôle d’accès n’est efficace que s’il est appliqué dans un code côté serveur de
confiance, où l’attaquant ne peut pas modifier le contrôle d’accès ou les métadonnées,
Pour se protéger contre ce type d’attaque, on cite quelques solutions à effectuer, notam-
ment :
— Refuser l’accès aux fonctionnalités par défaut.
— Utilisez des listes de contrôle d’accès et des mécanismes d’authentification basés
sur les rôles.
— Consignez les échecs de contrôle d’accès, alertez les administrateurs le cas échéant
(par exemple, échecs répétés).

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 22/81
Projet de Fin d’études Pentest des applications web : . . .

— Désactivez la liste des répertoires du serveur Web et assurez-vous que les métadon-
nées des fichiers de sauvegarde ne sont pas présentes dans les racines Web.

[Link] cryptographique :

Principe d’attaque :

Dans cette vulnérabilité, les données sensibles telles que les informations financières,
les dossiers médicaux, les informations d’identification des utilisateurs, etc. qui doivent
généralement être cryptées ou cachés sont visibles en texte clair.[18]

Les formes d’attaque :

— Des données sont transmises en texte clair, cela concerne les protocoles tels que
HTTP, SMTP et FTP. Le trafic Internet externe est particulièrement dangereux.
— Des algorithmes cryptographiques anciens ou faibles sont utilisés par défaut ou
dans un code plus ancien, ce qui permet les pirates à accéder à des informations
sensibles en exécutant des attaques de types man-in-the middle pour voler les don-
nées en transit.

Les exemples d’attaque :

Exemple1 : Une application crypte les numéros de carte de crédit dans une base de
données à l’aide du cryptage automatique de la base de données. Cependant, ces don-
nées sont automatiquement déchiffrées lors de leur récupération, permettant à une faille
d’injection SQL de récupérer les numéros de carte de crédit en texte clair.
Exemple2 : un site n’utilise pas ou n’applique pas le TLS pour toutes les pages ou prend
en charge un cryptage faible. Un attaquant surveille le trafic réseau (par exemple sur
un réseau sans fil non sécurisé), intercepte les requêtes et vole le cookie de session de
l’utilisateur. L’attaquant rejoue alors ce cookie et détourne la session (authentifiée) de
l’utilisateur, en accédant ou en modifiant les données privées de l’utilisateur et il peut
modifier toutes les données transportées, par exemple le destinataire d’un transfert d’ar-
gent.
Exemple3 :La base de données de mots de passe utilise des hachages simples pour stocker
les mots de passe de tout le monde. Une faille de téléchargement de fichier permet à un
attaquant de récupérer la base de données des mots de passe.

Mécanismes de prévention :

— Stockez les mots de passe à l’aide de fonctions de hachage adaptatives et puissantes,

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 23/81
Projet de Fin d’études Pentest des applications web : . . .

— Classer les données traitées, stockées ou transmises par une application. Identi-
fiez les données sensibles en fonction des lois sur la confidentialité, des exigences
réglementaires ou des besoins de l’entreprise,
— Assurez-vous de chiffrer toutes les données sensibles,
— Chiffrez toutes les données en transit avec des protocoles sécurisés tels que TLS
avec des chiffrements PFS (Perfect Forward Secrecy).
[Link] :

Principe d’attaque :

Une attaque d’injection SQL se produit lorsque des données non fiables sont envoyées
à l’application dans le cadre d’une commande ou d’une requête, l’exécution de ces at-
taques permet à un attaquant d’accéder à la quasi-totalité des informations contenues
dans la base de données de l’application sans autorisation appropriée.[19]

Les formes d’attaque :

— L’attaquant peut ajouter une requête SQL distincte à la requête existante, ce qui
conduit l’application à supprimer la table entière ou à manipuler le résultat renvoyé.
— L’attaquant stocke le contenu malveillant dans la base de données et en déclenche
l’exécution ultérieurement (injection SQL de seconde ordre).

Exemple d’attaque :
Dans le langage SQL, une requête normale est généralement comme suit :
SELECT * FROM user WHERE Username = ’$username’ AND Password = ’$password’ ;

Si un attaquant tente de se connecter avec un mot de passe incorrect, la requête

devient alors la suivante :
SELECT * FROM user WHERE Username = ’$username’ AND Password = ’pass’
OR ’1’=’1’ ;
Si un attaquant tente de se connecter sans username, ni mot de passe, il peut saisir
la requête suivante :

SELECT * FROM user WHERE Username = ’name’ or ’1 = 1’– ’AND Password =

’1111’.

L’étape d’authentification sera ignorée. Car l’ajout de la condition OR ’1’ = ’1’ fait
que la clause ’where’ est toujours évaluée comme étant vrai. Ainsi, le reste de la chaîne
qui suit – devient un commentaire, la requête devient donc logiquement équivalente à :
SELECT * FROM user ;

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 24/81
Projet de Fin d’études Pentest des applications web : . . .

Mécanismes de prévention :

— Utilisation des validations « White Liste » d’entrée côté serveur, c’est une liste qui
contient l’ensemble des URLs internes vers lesquels la navigation est autorisée,
— Utilisation des techniques d’échappement pour échapper les caractères spéciaux,
A4. Conception non sécurisée :

Principe d’attaque :

Est une nouvelle catégorie pour 2021 se concentre sur les risques liés aux défauts de
conception et d’architecture, avec un appel à une plus grande utilisation de la modélisa-
tion des menaces, des modèles de conception sécurisés et des architectures de référence.
En effet La conception sécurisée est une culture et une méthodologie qui évalue en per-
manence les menaces et garantit que le code est conçu et testé de manière robuste pour
empêcher les méthodes d’attaque connues. La modélisation des menaces doit être inté-
grée aux sessions de raffinement (ou à des activités similaires) et l’un des facteurs qui
contribuent à la conception non sécurisée est le manque de profilage des risques commer-
ciaux inhérent au logiciel ou au système en cours de développement.[20]

Exemple d’attaque :

Un flux de travail de récupération d’informations d’identification peut inclure des

« questions et réponses », ce qui est interdit par le NIST 800-63b, l’OWASP ASVS et
le Top 10 de l’OWASP. Les questions et les réponses ne peuvent pas être considérées
comme une preuve d’identité en tant qu’une autre personne peut connaître les réponses,
c’est pourquoi elles sont interdites. Un tel code doit être supprimé et remplacé par une
conception plus sécurisée.

Mécanismes de prévention :

— Établir et utiliser une bibliothèque de modèles de conception sécurisés ou de com-

posants prêts à l’emploi pour routes pavées.
— Utilisez la modélisation des menaces pour l’authentification critique, le contrôle
d’accès, la logique métier et les flux de clés.
— Intégrer le langage et les contrôles de sécurité dans les user stories
— Intégrez des contrôles de plausibilité à chaque niveau de votre application (du
frontend au backend).
— Rédigez des tests unitaires et d’intégration pour valider que tous les flux critiques
résistent au modèle de menace.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 25/81
Projet de Fin d’études Pentest des applications web : . . .

A5. Mauvaise configuration de sécurité :

Principe d’attaque :

De telles failles donnent fréquemment aux attaquants un accès non autorisé à cer-
taines données ou fonctionnalités du système. Parfois, de telles failles entrainent une
compromission complète du système.[21]

Les formes d’attaque :

Parmi les événements qui peuvent provoquer des attaques à cause de la mauvaise
configuration de sécurité, on peut citer :
— Les fonctionnalités inutiles sont activées ou installées (par exemple : services, pages,
comptes ou privilèges inutiles).
— Les attaquants tentent fréquemment d’exploiter des vulnérabilités non corrigées ou
accéder aux comptes par défaut, aux pages inutilisées, aux fichiers et répertoires non
protégés, etc.. . . afin d’obtenir des accès non autorisés et une meilleure connaissance
du système visé.
— La gestion des erreurs révèle des traces de pile ou d’autres messages d’erreur trop
informatifs aux utilisateurs.

Exemples d’attaques :

Exemple1 : Si la liste des répertoires n’est pas désactivée sur le serveur et si l’atta-
quant découvre la même chose, l’attaquant peut simplement répertorier les répertoires
pour trouver n’importe quel fichier et l’exécuter. Il est également possible d’obtenir la
base de code réelle qui contient tout votre code personnalisé et ensuite de trouver de
sérieuses failles dans l’application.
Exemple2 : La configuration du serveur d’applications permet de renvoyer les traces de la
pile aux utilisateurs, exposant potentiellement des failles sous-jacentes. Les attaquants
récupèrent les informations supplémentaires fournies par les messages d’erreur, ce qui
leur suffit pour pénétrer.

Mécanismes de prévention :

— Tous les environnements tels que les environnements de développement, d’assurance

de qualité et de production doivent être configurés de manière identique à l’aide
des mots de passe différents utilisés dans chaque environnement qui ne peuvent pas
être piratés facilement.
— Assurez-vous qu’une architecture d’application solide est adoptée qui fournit une
séparation efficace et sécurisée entre les composants.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 26/81
Projet de Fin d’études Pentest des applications web : . . .

— Il peut également minimiser la possibilité de cette attaque en exécutant des analyses

automatisées et en effectuant des audits fréquemment.
— Un processus automatisé pour vérifier l’efficacité des configurations et des para-
mètres dans tous les environnements.

A6. Composants vulnérables et obsolètes :

Principe d’attaque :

Cette section fait référence aux problèmes et aux attaques qui peuvent se produire aux
applications web à cause de l’utilisation des composants contenants des vulnérabilités.[22]

Les formes d’attaque :

Ce type d’attaque peut arriver dans les cas suivants :

— Si vous ne connaissez pas les versions de tous les composants que vous utilisez (à
la fois coté client et coté serveur),
— Si le logiciel est vulnérable, non pris en charge ou obsolète. Cela inclut le sys-
tème d’exploitation, le serveur web/d’application, le système de gestion des don-
nées(SGBD), les environnements d’exécution et les bibliothèques,
— Si les développeurs de logiciels ne testent pas la compatibilité des bibliothèques
mises à jour, mise à niveau ou corrigées,
— Si vous ne réparez pas ou ne mettez pas à niveau la plate-forme, les Framework et
les dépendances sous-jacents de manière opportune,

Exemple d’attaque :

Un attaquant essaie de faire une demande au site Web, et supposons que cette de-
mande charge une page qui présente la vulnérabilité. Le site Web répond à la demande
qui divulgue également les composants vulnérables. Et une fois que l’attaquant trouve les
composants et la version vulnérables, il ira sur Internet et recherchera les vulnérabilités
connues. Quoi qu’il en soit, il est facile de trouver les risques associés aux composants
vulnérables sur le Web, de sorte que les attaquants obtiennent des informations sur la
manière dont ce risque pourrait être exploité. Ensuite, l’attaquant s’en va et lance l’at-
taque avec le site Web.

Mécanismes de prévention :

Il devrait y avoir un processus de gestion des correctifs en place pour :

— Supprimer les dépendances inutilisées, les fonctionnalités, les composants, les fi-
chiers et la documentation inutiles.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 27/81
Projet de Fin d’études Pentest des applications web : . . .

— N’obtenez des composants que de sources officielles via des liens sécurisés. Choi-
sissezles packages signés pour réduire le risque d’inclure un composant malveillant
modifié.
— Surveillez les bibliothèques et les composants qui ne sont pas maintenus ou ne
créent pas des correctifs de sécurité pour les anciennes versions.

A7. Échecs d’identification et d’authentification :

Principe d’attaque :

L’authentification est le moyen de confirmer l’identité d’un utilisateur en s’assurant

qu’il est vraiment ce qu’il prétend être. Une authentification brisé fait référence à un
acte permettant à des personnes non autorisées de voler les données de connexion d’un
utilisateur ou de falsifier des données de session, telles que des cookies, pour obtenir un
accès non autorisé aux sites Web.[23]

Les formes d’attaque :

Les attaquants utilisent une gamme de techniques pour exploiter une authentification
brisée, notamment :
— Credential stuffing : il sert à autoriser les attaques automatisées, où l’attaquant
dispose d’une liste de noms d’utilisateurs et de mots de passes valides qui sont
associées à un compte existant.
— Pulvérisation de mot de passe : dans les attaques de pulvérisation de mot de passe,
l’attaquant contourne les contre- mesures de base telles que le verrouillage de
compte en pulvérisant le même mot de passe sur de nombreux comptes avant
d’essayer un autre mot de passe.
— Autoriser les mots de passe par défaut, faibles ou connus : tels que : "Mot de passe1"
ou "admin/admin".
— Utiliser des processus de récupération d’informations d’identification faibles ou
inefficaces : tel que : mot de passe oublié, par demander des réponses basées sur
les connaissances qui ne peuvent pas être sécurisés.
— N’invalide pas correctement les identifiants de session : les sessions utilisateur
ou les jetons d’authentification, en particulier les jetons d’authentification unique
(SSO) ne sont pas correctement invalidés pendant la déconnexion ou une période
d’inactivité.
— Campagnes de phishing étendues : qui permet à accéder à quelques comptes prin-
cipaux, en particulier les comptes d’administrateur qui peuvent compromettre l’en-
semble d’application.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 28/81
Projet de Fin d’études Pentest des applications web : . . .

Mécanismes de prévention :

— Limitez ou retardez de plus en plus les tentatives de connexion infructueuses. En-

registrez tous les échecs et alertez les administrateurs lorsqu’un bourrage d’infor-
mations d’identification, une force brute ou d’autres attaques sont détectés.
— Utilisez un gestionnaire de session intégré, sécurisé et côté serveur qui génère un
nouvel ID de session aléatoire après la connexion. Les identifiants de session ne
doivent pas figurer dans l’URL, être stockés de manière sécurisée et invalidés après
la déconnexion, l’inactivité et les délais d’attente absolus.
— Alignez les politiques de longueur, de complexité et de rotation des mots de passe.

A8. Défaillances du logiciel et d’intégrité des données :

Principe d’attaque :

Une nouvelle catégorie pour 2021 se concentre sur la formulation d’hypothèses re-
latives aux mises à jour logicielles, aux données critiques et aux pipelines d’intégration
et de distribution sans vérifier l’intégrité. Les défaillances d’intégrité des logiciels et des
données concernent le code et l’infrastructure qui ne protègent pas contre les violations
d’intégrité.[24]

Les formes d’attaque :

— Une application s’appuie sur des plug-ins, des bibliothèques ou des modules prove-
nant de sources, de référentiels et de réseaux de diffusion de contenu (CDN) non
fiables.
— Un pipeline CI/CD non sécurisé peut introduire un potentiel d’accès non autorisé,
de code malveillant ou de compromission du système.
— De nombreuses applications incluent désormais une fonctionnalité de mise à jour
automatique, où les mises à jour sont téléchargées sans vérification d’intégrité suf-
fisante et appliquées à l’application précédemment approuvée.
— Les attaquants pourraient potentiellement télécharger leurs propres mises à jour à
distribuer et à exécuter sur toutes les installations.
— Des objets ou des données sont codés ou sérialisés dans une structure qu’un atta-
quant peut voir et modifier est vulnérable à une désérialisation non sécurisée.

Exemple d’attaque :

Mise à jour sans signature : de nombreux routeurs domestiques, décodeurs, micro

logiciels d’appareils et autres ne vérifient pas les mises à jour via un micro logiciel signé.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 29/81
Projet de Fin d’études Pentest des applications web : . . .

Le micro logiciel non signé est une cible croissante pour les attaquants et ne devrait
qu’empirer. Il s’agit d’une préoccupation majeure car il n’y a souvent aucun mécanisme
de correction autre que de corriger dans une version future et d’attendre que les versions
précédentes vieillissent.

Mécanismes de prévention :

— Utilisez des signatures numériques ou des mécanismes similaires pour vérifier que le
logiciel ou les données proviennent de la source attendue et n’ont pas été modifiés.
— S’assurer qu’un outil de sécurité de la chaîne d’approvisionnement logiciel, tel que
OWASP Dependency Check ou OWASP CycloneDX, est utilisé pour vérifier que
les composants ne contiennent pas de vulnérabilités connues.
— Assurez-vous que les données sérialisées non signées ou non cryptées ne sont pas
envoyées à des clients non fiables sans une certaine forme de contrôle d’intégrité
ou de signature numérique pour détecter la falsification ou la relecture des données
sérialisées.

A9. Insufficient logging and monitoring :

Principe d’attaque :

Une journalisation et une surveillance insuffisantes, associées à une intégration man-

quante ou inefficace avec la réponse aux incidents, permettent aux attaquants d’attaquer
les systèmes, de basculer vers plus de systèmes et de falsifier, extraire ou détruire des
données. La plupart des études sur les violations montrent que le délai de détection d’une
violation est supérieur à 200 jours, généralement détecté par des parties externes plutôt
que par des processus ou une surveillance interne.[25]

Les formes d’attaque :

— Ce type d’attaque arrive lorsque les événements qui doivent être auditer tels que
les connexions, les échecs de connexion et les transactions de grande valeur ne sont
pas consignés,
— Les logs des applications ne sont pas surveillés pour les activités suspectes,
— L’application est incapable de détecter ou d’alerter en cas d’attaques actives en
temps réel ou quasi réel,
— Vous êtes vulnérables aux fuites d’informations et vous rendez les événements de
logging et d’alertes visibles pour un utilisateur ou un attaquant.

Mécanismes de prévention :

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 30/81
Projet de Fin d’études Pentest des applications web : . . .

— Assurez-vous que les transactions de grande valeur ont une piste d’audit avec des
contrôles d’intégrité pour empêcher la falsification ou la suppression.
— Assurez-vous que tous les échecs de connexion, de contrôle d’accès et de validation
d’entrée côté serveur peuvent être enregistrés avec un contexte utilisateur suffisant
pour identifier les comptes suspects ou malveillants, et conservés pendant une durée
suffisante.
— Établir une surveillance et des alertes efficaces afin que les activités suspectes soient
détectées et traitées en temps opportun.
— Établir ou adopter un plan de réponse aux incidents et de récupération, tel que
NIST.

[Link]çon de demande côté serveur (SSRF) Server-Side Request

Forgery :

Principe d’attaque :

Est ajouté à partir de l’enquête de la communauté Top 10, est une vulnérabilité de
sécurité web qui permet à un attaquant d’inciter l’application coté serveur à effectuer des
requêtes http vers un domaine arbitraire de son choix. Dans une attaque SSRF typique,
l’attaquant peut amener le serveur à établir une connexion avec des services internes
uniquement au sein de l’infrastructure de l’organisation. Dans d’autres cas, ils peuvent
forcer le serveur à se connecter à des systèmes externes arbitraires, ce qui risque de di-
vulguer des données sensibles telles que les informations d’identification.[26]

Les exemples d’attaque :

Les attaquants peuvent utiliser SSRF pour attaquer des systèmes protégés derrière
des pare-feu d’application Web, des pare-feu ou des listes de contrôle d’accès réseau, en
utilisant des scénarios tels que :
Exemple1 : serveurs internes d’analyse des ports : si l’architecture du réseau n’est pas
segmentée, les attaquants peuvent cartographier les réseaux internes et déterminer si les
ports sont ouverts ou fermés sur les serveurs internes à partir des résultats de connexion
ou du temps écoulé pour se connecter ou rejeter les connexions de charge utile SSRF.
Exemple2 : Exposition des données sensibles : les attaquants peuvent accéder à des fi-
chiers locaux ou à des services internes pour obtenir des informations sensibles telles que
file :///etc/passwd</span> et http ://localhost :28017/.
Exemple3 : accéder au stockage de métadonnées des services cloud : La plupart des four-
nisseurs de cloud disposent d’un stockage de métadonnées tel que http ://[Link]/.
Un attaquant peut lire les métadonnées pour obtenir des informations sensibles.
Exemple4 : compromettre les services internes : l’attaquant peut abuser des services in-
ternes pour mener d’autres attaques telles que l’exécution de code à distance (RCE) ou

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 31/81
Projet de Fin d’études Pentest des applications web : . . .

le déni de service (DoS).

Mécanismes de prévention :

Les développeurs peuvent empêcher SSRF en mettant en œuvre tout ou partie des
contrôles de défense en profondeur suivants :
Depuis la couche réseau :
— Segmentez la fonctionnalité d’accès aux ressources à distance dans des réseaux
séparés pour réduire l’impact de SSRF.
— Appliquez des politiques de pare-feu « refuser par défaut » ou des règles de contrôle
d’accès au réseau pour bloquer tout le trafic intranet, sauf essentiel.
À partir de la couche Application :
— Désinfecter et valider toutes les données d’entrée fournies par le client.
— Appliquer le schéma d’URL, le port et la destination avec une liste d’autorisation
positive.
— Ne pas envoyer des réponses brutes aux clients.
Mesures supplémentaires à considérer :
— Ne déployez pas d’autres services liés à la sécurité sur les systèmes frontaux (par
exemple, OpenID). Contrôler le trafic local sur ces systèmes (par exemple local-
host).
— Pour les frontaux avec des groupes d’utilisateurs dédiés et gérables, utilisez le cryp-
tage du réseau (par exemple des VPN) sur des systèmes indépendants pour prendre
en compte les besoins de protection très élevés.

1.2.8 Protocole HTTP

Hypertext Transfer Protocol (HTTP) est un protocole client-serveur de communica-
tion développé pour le World Wide Web. C’est un protocole générique, sans état, cela
veut dire qu’il ne conserve pas le lien entre les anciennes requêtes et les nouvelles. HTTP
est un protocole de couche d’application construit sur TCP/IP. Il est basé sur les URI
et un paradigme requête/réponse.

La communication entre le client et le serveur est la suivante :

— Le client (navigateur) envoie une requête HTTP pour une ressource au serveur qui
la décode. Le serveur identifie la ressource, le réseau identifie les types de support
des représentations que le client est prêt à utiliser en réponse.
— Le serveur recherche des informations, doit éventuellement interpréter les résultats
et envoyer la réponse HTTP avec une représentation de la ressource. Cette réponse
contient les en-têtes du protocole HTTP et le contenu demandé.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 32/81
Projet de Fin d’études Pentest des applications web : . . .

[Link] Requête Http

Tous les messages HTTP (requêtes et réponses) sont constitués d’un ou plusieurs
en-têtes, chacun sur une ligne distincte, suivie d’une ligne vierge obligatoire, suivie d’un
corps de message facultatif.
La Figure 1.4 illustre la forme d’une requête HTTP :

Figure 1.4 – La forme d’une requête HTTP

La première ligne de chaque requête HTTP se compose de trois éléments, séparés par
des espaces :
— Un verbe en anglais indiquant la méthode HTTP utiliser. Le serveur iden-
tifie la ressource, le réseau identifie les types de support des représentations que le
client est prêt à utiliser en réponse.
— L’URL demandée. L’URL fonctionne généralement comme un nom pour la res-
source demandée, avec une chaîne de requête facultative contenant des paramètres
que le client transmet à cette ressource.
— La version HTTP utilisée. Les seules versions HTTP couramment utilisées
sur internet sont HTTP 1.0 , HTTP1.1 et HTTP2.0. La plupart des navigateurs
utilisent la version 1.1 par défaut.
Dans les autres lignes on trouve :
— L’en-tête User-Agent. est utilisé pour fournir des informations sur le navigateur
ou tout autre logiciel client qui a généré la demande. Notant que la plupart des navi-
gateurs inclure le préfixe Mozilla pour des raisons historiques. C’était l’utilisateur-
Chaîne d’agent utilisée par le navigateur Netscape dominant à l’origine, et d’autres
navigateurs voulaient affirmer aux sites Web qu’ils étaient compatibles avec cette
norme.
— L’en-tête. de requête Host spécifie le nom de domaine du serveur (pour de l’héber-
gement virtuel), et (optionnellement) le numéro du port TCP sur lequel le serveur

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 33/81
Projet de Fin d’études Pentest des applications web : . . .

é[Link] aucun port n’est donné, le port par défaut du service demandé sera é (par
exemple, "80" pour une URL HTTP).
— L’en-tête Cookie. est utilisé pour soumettre des paramètrè supplémentaires que
le serveur a émis au client.

[Link] La forme d’une Réponse Http

La Figure 1.5 illustre la forme d’une réponse HTTP :

Figure 1.5 – Réponse HTTP

La première ligne de chaque réponse HTTP se compose de trois éléments, séparés

par les espaces :
— La version HTTP utilisée.
— Un code d’état générique indiquant le résultat de la demande. 200 est le code d’état
le plus commun ; cela signifie que la demande a réussi et que la ressource demandée
est renvoyée.
— Un mot décrivant plus en détail l’état de la réponse.
Quelques autres points d’intérêt de la réponse HTTP :
— L’en-tête server contient une bannière indiquant le logiciel du serveur Web utilisé,
et parfois d’autres détails tels que les modules installés et le système d’exploitation
du serveur.
— L’entête de réponse HTTP Set-Cookie est utilisé pour envoyer un cookie depuis le
serveur à l’agent utilisateur pour qu’il puisse le renvoyer dans l’avenir.
— L’en-tête Content-Type indique que le corps de ce message contient un document
HTML.
— L’en-tête Content-Length indique la longueur du corps du message par octets.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 34/81
Projet de Fin d’études Pentest des applications web : . . .

[Link] Méthodes GET/POST

Il existe plusieurs méthodes HTTP à savoir, PUT, OPTIONS, HEAD, DELETE. etc.
Mais les plus couramment utilisées sont les méthodes GET et POST.
— GET : il s’agit de la méthode la plus courante pour demander une ressource. Une
demande GET n’a aucun effet sur la ressource, ainsi les données à envoyer au ser-
veur sont écrit directement dans l’URL dans la fenêtre de votre navigateur. Cela res-
semble à ceci : " [Link]/[Link] ?firstname=peter&amp ;name=miller&amp ;ag
mp ;gender=male". Les paramètres URL envoyés sont non seulement visibles par
tous dans la barre d’adresse du navigateur, mais sont également stockés sans chif-
frement dans l’historique du navigateur, dans le cache et dans le fichier log du
serveur.[34]
— POST : Cette méthode doit être utilisée lorsqu’une requête modifie la ressource.
Cela permet de travailler avec de gros volumes de données, de plus les requêtes de
type POST sont plus discrètes car les données ne sont pas visibles dans l’adresse
et les données n’apparaissent pas dans l’historique de navigation. Ce qui permet
une grande flexibilité et confidentialité des données.[34]

[Link] En-têtes HTTP

Les en-têtes HTTP (HTTP headers) sont les paires nom/valeur affichées dans les
messages de la demande et de la réponse des en-têtes de message pour le protocole
HTTP : AcceptCharset, Accept-Language, Content-Length,Date, User Agent...etc.

[Link] URI
Les ressources sur le Web peuvent être désignées de manière unique par un identifiant
de ressource uniforme (URI)[4] qui est caractérisé par [36] :
— Une interprétation sémantique uniforme.
— Ressource qui présente généralement tout ce qui pourrait être identifié par un URI.
— Identifiant contient les informations nécessaires pour distinguer ce qui est identifié
de tout ce qui relève de son domaine d’identification.
L’URI est une combinaison d’URL (Uniform Resource Locator) et d’URN (Uniform
Ressource Name).
— URL : Une interprétation sémantique uniforme.
— URN : qui présente généralement tout ce qui pourrait être identifié par un URI.
— Identifiant contient les informations nécessaires pour distinguer ce qui est identifié
de tout ce qui relève de son domaine d’identification.

[Link] Les cookies

Cookie HTTP est un ensemble d’informations sous forme de texte correspond à cer-
tain domaine ou site Web et possèdent une durée limitée. Il est généré lors de la consulta-

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 35/81
Projet de Fin d’études Pentest des applications web : . . .

tion d’un site, par le serveur Web dans une réponse HTTP, qui est capable de les mettre
à jour suivant l’entête Set Cookie, et stockés par le navigateur pour joint les prochaines
requêtes et gérer les sessions d’utilisateur grâce aux informations d’identification. Le co-
okie peut conserver des données critiques du point de vue de sécurité, car il est lisible
depuis un script JavaScript. Pour éviter la lecture, il est possible de restreindre l’accès à
ce cookie aux entêtes HTTP en spécifiant une valeur httponly dans le cookie.

1.3 Les tests de pénétration

Un test de pénétration ou PEN Test est un processus d’identification des vulnérabili-
tés de sécurité dans le système. l’utilisation des tests de pénétration a considérablement
augmenté par les grandes entreprises pour sécuriser leurs systèmes et services d’informa-
tion. Cela permet aux organisations de résoudre les problèmes de sécurité avant qu’ils
ne soient exploités. Il existe deux façons de réaliser un test de pénétration : Test de
pénétration manuel et Test de pénétration automatisé.[16]
— Test de pénétration manuel : Le test de pénétration manuel est effectué par un
professionnel expérimenté et qualifié qui peut contrôler tous les paramètres pendant
le test. Sur un système en test, le testeur de pénétration manuel analyse tous les
points d’entrée de l’application et effectue des tests pour identifier les vulnérabilités
potentielles, certaines vulnérabilités sont difficiles à trouver et ne peuvent être
trouvées que par un test de pénétration manuel. Un testeur de pénétration doit
avoir une connaissance approfondie des vulnérabilités des applications Web et des
méthodes de détection. Il indique également que la couverture d’un tel test dépend
en grande partie des compétences et de l’expérience des testeurs d’intrusion. Les
testeurs de pénétration suivent les normes acceptées par l’industrie pour effectuer
des tests de pénétration, comme OWASP. L’adoption de ce processus est parfois
lent et fastidieux. C’est également un processus coûteux car l’embauche d’un testeur
d’intrusion expérimenté nécessite beaucoup d’argent.
— Test de pénétration automatisé : Un test de pénétration automatisé est une tech-
nique dans laquelle un logiciel est utilisé pour analyser une application requête
par requête. L’application de scan interagit activement avec le serveur d’applica-
tion cible et analyse chaque requête et réponse pour les vulnérabilités connues. Le
scanner injecte également diverses Payload dans la requête pour détecter les vulné-
rabilités de l’application. Il existe des outils conçus uniquement pour l’identification
d’une seule vulnérabilité qui ont un taux de précision plus élevé. Mais l’utilisation
de plusieurs outils individuels pour analyser une application complète n’est pas
toujours une option applicable et cela nécessite également une compréhension plus
approfondie des vulnérabilités, dont dispose un testeur de pénétration profession-
nel. Les scanners de vulnérabilité Web modernes résolvent ce problème. Ces outils
automatisés fournissent un cadre complet d’outils auxquels sont nécessaires pour
tester l’application. Ces outils utilisent des normes approuvées par l’industrie telles
que OWASP TOP 10 et National Vulnerability Database by NIST2. Les outils de

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 36/81
Projet de Fin d’études Pentest des applications web : . . .

test de pénétration automatisés présentent un avantage par rapport au test de

pénétration manuel, car ils peuvent effectuer une analyse en utilisant plusieurs
connexions (threads) à l’application Web. Les scanners automatisés aident les tes-
teurs de pénétration à couvrir une plus grande zone de l’application. D’autre part,
les outils automatisés souffrent d’une grande quantité de taux de détection des faux
positifs.
Le tableau 1.1 résulte la différence entre le test de pénétration manuel et automatisé :

Test - Travail intensif, incohérent et susceptible aux erreurs, sans normes

manuel de qualité spécifiques,
- Élimine les erreurs et les tâches manuelles fastidieuses,
- Les résultats peuvent varier considérablement d’un test à l’autre,
- En règle générale, l’exécution et l’interprétation des tests néces-
sitent des personnes hautement rémunérées et compétentes en ma-
tière de sécurité. - Rapide, simple et sécurisé.
Test - Nécessite de nombreux outils différents,
automatisé - Centralisé et normalisé pour produire des résultats fiables et re-
productibles,
- Nécessite de nombreux outils différents.
- Facile à utiliser et offre des rapports clairs et exploitables.

Table 1.1 – Différences entre un test automatique et un test manuel

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 37/81
Projet de Fin d’études Pentest des applications web : . . .

1.3.1 Les types des tests de pénétration

— Test de la boîte noire : Ce type de test est également connu sous le nom de
test « Zero Knowledge » car le testeur n’a aucune connaissance de l’application et
de l’infrastructure sous-jacente. Il se base uniquement des informations obtenues
à partir d’application Web. La plupart des scanners automatisés sont conçus pour
effectuer un test de boîte noire. [16]
— Test de la boîte blanche : Dans le test boîte blanche, toutes les informations sur
l’application Web, telles que le code d’application, le diagramme d’infrastructure,
les détails des privilèges de l’utilisateur et les détails de la configuration du ser-
veur, sont fournies au testeur de pénétration. Des analyseurs de code statiques et
dynamiques sont utilisés pour ce test. C’est ce qu’on appelle un test d’information
complet.[16]
— Test de la boîte grise : C’est un mélange de test de boîte blanche et noire. Ici,
le testeur de pénétration a une connaissance de l’infrastructure et de l’application
Web cible. Le testeur dispose également des informations d’identification de l’utili-
sateur pour l’application, à l’aide desquelles. la logique métier et les vulnérabilités
internes peuvent être testées et identifiées. Les outils automatisés, s’ils sont confi-
gurés, peuvent effectuer des tests de boîte grise. Il ne vient pas naturellement à
l’outil automatisé d’effectuer un test de boîte grise, mais une intervention et une
configuration manuelle sont parfois nécessaires.[16]

1.3.2 Types d’exploration ou crawling

L’exploration est un type d’analyse qui consiste à mapper l’application en naviguant
requête par requête. Le robot d’exploration ou crawler répertorie les liens trouvés au
cours du processus, plus tard, ces liens sont utilisés pour effectuer l’analyse. Il existe
deux types d’exploration : l’exploration active et l’exploration passive. [16]
— Le robot d’exploration actif : Il interagit avec l’application et envoie des re-
quêtes au serveur d’application pour obtenir les liens actifs.
— Le robot d’exploration passif : Fonctionne silencieusement sans engager acti-
vement l’application. Le robot d’exploration passif fonctionne lors de la navigation
manuelle dans l’application. Par conséquent, il peut couvrir plus de liens et de
chemins dans l’application, ce qui prouve une plus grande couverture.

1.3.3 Couverture du robot d’exploration

L’exploration des applications Web fait partie de l’étape de collecte d’informations
dans le processus de test d’intrusion. Dans cette étape, un testeur d’intrusion souhaite
recueillir autant d’informations que possible sur l’application Web. Donc, il est essentiel
que le scanner automatisé couvre autant d’applications qu’il le peut sans intervention
manuelle. La couverture du robot d’exploration peut être mesurée par le nombre d’URL

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 38/81
Projet de Fin d’études Pentest des applications web : . . .

explorées par le scanner.[16] Le score pour chaque couverture rampante est présenté
comme ceci :
— Couverture 1- Couverture inférieure à 25%
— Couverture 2- 25% à 50%
— Couverture 4- 70% à 90%
— Couverture 5- supérieure à 90%

1.3.4 Types de scan

Il existe deux types de scan pour le scan des applications, le scan passif et le scan
actif. L’analyse passive analyse la requête et les réponses recueillies à partir de l’ex-
ploration manuelle ou de l’interaction par le testeur de pénétration et n’envoie pas des
données supplémentaires au serveur d’application. L’analyse passive comprend l’identifi-
cation des problèmes tels que les en-têtes de sécurité de réponse manquants, les erreurs
de configuration des certificats SSL. Il comprend également une analyse Java Script côté
client. La phase d’analyse active peut détecter la présence des vulnérabilités en inter-
agissant avec le serveur d’applications Web. Le scanner envoie des requêtes spécialement
conçues au serveur et tente d’exploiter les vulnérabilités. Le scanner essaiera de trouver
les vulnérabilités courantes telles que répertoriées dans le top 10 de l’OWASP.[16]

1.3.5 Conclusion
Dans ce chapitre, nous avons introduit quelques concepts concernant la sécurité web
et nous avons présenté les divers critiques de sécurité des applications web par OWASP
Top pour 2021, et enfin nous avons donné un aperçu concernant les tests de pénétrations.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 39/81
CHAPITRE 2
GÉNÉRALITÉS SUR OWASP BENCHMARK ET LES
CONCEPTS DES APPLICATIONS DES TESTS DE
SÉCURITÉ WEB

2.1 Introduction
Les tests de sécurité sont l’une des principales approches utilisées pour détecter les
vulnérabilités Web. Dans ce chapitre nous allons présenter l’une des applications web
open source OWASP Benchmark sur laquelle nous allons analyser les vulnérabilités de-
dans, ainsi tester les performances de chaque scanner utilisé.

2.2 Vue d’ensemble sur OWASP Benchmark

Figure 2.1 – L’application Benchmark OWASP

40
Projet de Fin d’études Pentest des applications web : . . .

OWASP Benchmark est une application Web qui est entièrement exécutable, elle
est doté des diverses catégories des vulnérabilités. La figure 2.1 présente l’interface du
OWASP Benchmark.
De plus, elle contient plus de 2740 de cas de test exploitables, (par exemple, Bench-
[Link]) comme il est présenté dans la figure 2.2, dont chacun est une seule
servlet Java qui contient une seule vulnérabilité (un vrai positif ou un faux positif), cha-
cun mappé à des CWE spécifiques, qui peuvent être analysés par tout type d’outil de
test de sécurité des applications (AST), y compris SAST, DAST (comme OWASP ZAP),
et les outils IAST.[43]

Figure 2.2 – Les cas de test pour la catégorie command injection

Le Benchmark comprend également des dizaines de générateurs de « scorecards »

pour de nombreux outils AST open source et commerciaux, et l’ensemble des outils pris
en charge ne cesse de croître.
Un [Link] est publié avec chaque version du Benchmark (par exemple,
[Link]) et il répertorie spécifiquement les résultats attendus pour chaque cas
de test qui inclue le numéro CWE (Common Weakness Enumeration) qui indique les top
25 des erreurs logicielles les plus dangereuses, et le résultat attendu (vrai résultat/faux
positif).

2.3 Les versions du OWASP Benchmark

2.3.1 Historique des versions
— La version 1.0 du Benchmark a été publiée le 15 avril 2015 et comptait 20 983 cas
de test.
— La version 1.1 du Benchmark a été publiée le 23 mai 2015. Elle a été améliorée par
rapport à la version précédente en s’assurant qu’il y a à la fois des vrais positifs et
des faux positifs dans chaque zone de vulnérabilité.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 41/81
Projet de Fin d’études Pentest des applications web : . . .

— La version 1.2 a été publiée pour la première fois le 5 juin 2016 et elle est toujours
en évolution.( et c’est la version sur laquelle on a travaillé) .

2.3.2 La différence entre les versions

Les versions 1.2 et ultérieures de Benchmark sont une application Web entièrement
exécutable, ce qui signifie qu’elle peut être analysée par tout type d’outil de détection
de vulnérabilité. La version 1.2 a été limité à un peu moins de 3 000 cas de test, pour
permettre aux outils DAST de l’analyser plus facilement donc elle ne va pas prendre si
longtemps et ils ne demandent pas un grand espace, et n’augmentent pas la taille de leur
base de données. La version 1.2 couvre les mêmes zones de vulnérabilité que la version
1.1.
Les domaines et les quantités de cas de test pour les versions de référence sont donnés
par le tableau suivant [43] :

Zone de Nombre de Nombre de Numéro CWE

vulnérabilité tests dans la tests dans la
v1.1 v1.2
Injection de 2708 251 78
commande
Cryptographie 1440 246 327
faible
Hachage faible 1421 236 328
Injection LDAP 736 59 90
Traversée de 2630 268 22
chemin
Indicateur de 416 67 614
cookie sécurisée
Injection SQL 3529 504 89
Violation des 725 126 501
limites de
confiance
Faiblesse aléatoire 3640 493 330
Injection XPATH 347 35 643
XSS(script 3449 455 79
intersites)
Total des cas de 21041 2740
test

Table 2.1 – Les domaines et le nombre de cas de test pour les versions de Benchmark
OWASP

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 42/81
Projet de Fin d’études Pentest des applications web : . . .

2.4 Les catégories de cas de test dans le Benchmark

OWASP
OWASP Benchmark a choisi des catégories parmi Le Top 25 des faiblesses logicielles
les plus dangereuses de l’énumération des faiblesses communes (CWE™) 2021 (CWE Top
25), c’est une liste démonstrative des problèmes les plus courants et les plus percutants
rencontrés au cours des deux années civiles précédentes. Ces faiblesses sont dangereuses
car elles sont souvent faciles à trouver, à exploiter et peuvent permettre à des adversaires
de prendre complètement le contrôle d’un système, de voler des données ou d’empêcher
une application de fonctionner. Le CWE Top 25 est une ressource communautaire pré-
cieuse qui peut aider les développeurs, les testeurs et les utilisateurs ainsi que les chefs de
projet, les chercheurs en sécurité et les éducateurs à fournir un aperçu des faiblesses de
sécurité les plus graves et actuelles.[30] Et par suite nous allons présenter les catégories
sur lesquelles nous pouvons faire le test sur Benchmark.

2.4.1 La catégorie injection de commande

L’injection de commandes est une attaque dont le but est l’exécution de commandes
arbitraires sur le système d’exploitation hôte via une application vulnérable. Les at-
taques par injection de commande sont possibles lorsqu’une application transmet des
données non sécurisées fournies par l’utilisateur (formulaires, cookies, en-têtes HTTP,
etc.) à un shell système. Dans cette attaque, les commandes du système d’exploitation
fournies par l’attaquant sont généralement exécutées avec les privilèges de l’application
vulnérable. Les attaques par injection de commande sont possibles en grande partie en
raison d’une validation d’entrée insuffisante. Cette attaque diffère de l’injection de code,
cette dernière permet à l’attaquant d’ajouter son propre code qui est ensuite exécuté
par l’application. Dans « Command Injection », l’attaquant étend la fonctionnalité par
défaut de l’application, qui exécute des commandes système, sans avoir besoin d’injecter
du code.[28]

2.4.2 La catégorie des algorithmes de chiffrement faibles

C’est une catégorie qui est défini comme un algorithme de chiffrement/déchiffrement
qui utilise une clé de longueur insuffisante. L’utilisation d’une longueur insuffisante pour
une clé dans un algorithme de chiffrement/déchiffrement ouvre la possibilité (ou la pro-
babilité) que le schéma de chiffrement puisse être rompu (c’est-à-dire craqué). Plus la
taille de la clé est grande, plus le chiffrement est fort. Les chiffrements faibles sont gé-
néralement connus sous le nom d’algorithmes de chiffrement/déchiffrement qui utilisent
des tailles de clé inférieures à 128 bits (c’est-à-dire 16 octets . . . 8 bits dans un octet).
Pour comprendre les ramifications d’une longueur de clé insuffisante dans un schéma de
chiffrement, un peu de connaissances en cryptographie de base sont nécessaires.[49]

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 43/81
Projet de Fin d’études Pentest des applications web : . . .

2.4.3 La catégorie d’algorithme de hachage faible

Les algorithmes de hachage sont utilisés pour générer des certificats SSL. « Disco-
very » vérifie votre certificat SSL/TLS ainsi que son certificat intermédiaire émetteur.
Par contre l’utilisation continue des certificats d’algorithmes de hachage faibles met en
danger les données sensibles de vos clients et entraînera l’affichage d’avertissements par
les navigateurs. Les avertissements créent de la méfiance lors de la connexion à un site et
peuvent amener les clients à éviter votre site.[47]Il est donc recommandé de ne pas utiliser
les hachages cryptographiques faibles car ils ne peuvent pas garantir l’intégrité des don-
nées et ne doivent pas être utilisés dans des contextes critiques pour la sécurité.[51] MD2,
MD4, MD5, RIPEMD-160 et SHA-1 sont des algorithmes de hachage cryptographiques
populaires autrefois considérés comme sûrs et souvent utilisés pour vérifier l’intégrité des
messages et d’autres données. Cependant, comme des recherches récentes sur la cryp-
tanalyse ont révélé des faiblesses fondamentales dans ces algorithmes, ils sont devenus
faibles ou cassables et ils ne devraient plus être utilisés dans des contextes critiques pour
la sécurité. Par exemple, MD5, autrefois considéré comme un algorithme de hachage sé-
curisé et incassable, est passé d’un algorithme de hachage puissant à un algorithme de
hachage faible à un algorithme de hachage cassé.[47] Des techniques efficaces pour casser
les hachages MD et RIPEMD sont largement disponibles, il ne faut donc pas se fier à ces
algorithmes pour la sécurité. Dans le cas de SHA-1, les techniques actuelles nécessitent
encore une puissance de calcul importante et sont plus difficiles à mettre en œuvre. Ce-
pendant, les attaquants ont trouvé le talon d’Achille de l’algorithme, et les techniques
pour le casser conduiront probablement à la découverte d’attaques encore plus rapides.
[51]

2.4.4 La catégorie des injections de type LDAP

« Lightweight Directory Access Protocol » est un protocole livre aux utilisateurs
des méthodes qui leur permettent, entre autres, de se connecter et se déconnecter d’un
réseau, d’insérer, modifier ou supprimer des entrées, de rechercher et de comparer des
informations. Il dispose des mécanismes de chiffrement afin de sécuriser l’accès aux in-
formations. Une injection LDAP est une attaque utilisée pour exploiter des applications
Web qui construisent des instructions LDAP basées sur l’entrée de l’utilisateur. Lors-
qu’une application ne parvient pas à nettoyer correctement les entrées de l’utilisateur, il
est possible de modifier les instructions LDAP via des techniques similaires à l’injection
SQL.[42] Les attaques par injection LDAP pourraient entraîner des autorisations à des
requêtes non autorisées et à la modification du contenu à l’intérieur de l’arborescence
LDAP. Les attaques par injection LDAP sont dû en raison de deux facteurs :
— Le manque d’interfaces de requête LDAP plus sûres et paramétrées.
— L’utilisation généralisée de LDAP pour authentifier les utilisateurs auprès des sys-
tèmes.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 44/81
Projet de Fin d’études Pentest des applications web : . . .

2.4.5 La catégorie Path traversal

Une attaque de traversée de chemin (également connue sous le nom de traversée
de répertoire) vise à accéder aux fichiers et répertoires stockés en dehors du dossier
racine Web. En manipulant des variables qui référencent des fichiers avec des séquences
« point-point-barre oblique (../) » et ses variations ou en utilisant des chemins de fichiers
absolus, il peut être possible d’accéder à des fichiers et répertoires arbitraires stockés sur
le système de fichiers, y compris le code source ou la configuration de l’application et les
fichiers système critiques. Il convient de noter que l’accès aux fichiers est limité par le
contrôle d’accès opérationnel du système (comme dans le cas de fichiers verrouillés ou
en cours d’utilisation sur le système d’exploitation Microsoft Windows). Cette attaque
est également connue sous le nom de « pointpoint-slash », « parcours de répertoire », «
escalade de répertoire » et « retour en arrière ».[48]

2.4.6 La catégorie des cookies non sécurisés

Cette vulnérabilité est créée lorsqu’un développeur ne parvient pas à désigner les
cookies d’authentification comme sécurisés. Cela signifie que les navigateurs Web sont
libres d’envoyer des cookies d’authentification sur un canal http non sécurisé. En faisant
cela, les pirates peuvent mettre en cache toutes les réponses DNS et surveiller les noms
d’hôtes qui utilisent le port 443 et se connecter à l’un des noms de domaine qui y sont sto-
ckés. Cela permet au pirate d’injecter des images à partir des parties non sécurisées (non
https) du site Web protégé afin que le navigateur envoie le cookie d’authentification.[40]
Les types de cookies non sécurisés sont donnés par :
— Cookies non sécurisés si la sécurité du transport des cookies n’est pas correc-
tement configurée, le pirate peut accéder aux informations sensibles stockées dans
ces cookies, peu importe si l’application Web utilise SSL. L’attaquant peut alors
collecter des données sensibles stockées dans ces cookies.
— Cookies de gestion de session persistants : lorsqu’un cookie de gestion de
session est défini de manière persistante, il permet au cookie d’être valide même
après qu’un utilisateur a terminé une session. Par conséquent un attaquant peut
utiliser un cookie de session stocké dans le fichier texte par le navigateur pour
accéder aux informations restreintes.
— Cookies pouvant être mis en cache : ces cookies peuvent être mis en cache
au niveau d’un proxy ou d’une passerelle. Cela peut entraîner la diffusion d’une
valeur de cookie obsolète ou périmée.
— Cookies avec l’attribut HTTPOnly non défini : HTTPOnly est un indicateur
supplémentaire inclus dans un en-tête de réponse HTTP Set-Cookie. L’utilisation
de l’indicateur HttpOnly lors de la génération d’un cookie permet d’atténuer le
risque que le script côté client accède au cookie protégé (si le navigateur le prend
en charge) [38]. Si l’attribut HTTP-Only n’est pas défini, alors le cookie peut être
consulté et manipulé dans le script. Les informations sensible contenu dans le cookie
peut être envoyé à l’ordinateur ou au site Web d’un pirate à l’aide d’un script.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 45/81
Projet de Fin d’études Pentest des applications web : . . .

2.4.7 La catégorie des injections de type SQL

(Déjà traité dans le chapitre2, le paragraphe : 1.2.7 OWASP Top 10 2021).

2.4.8 La catégorie de « trust boundary »

Une limite de confiance peut être considérée comme une ligne tracée à travers un
programme. D’un côté de la ligne, les données ne sont pas fiables. De l’autre côté de
la ligne, les données sont supposées être dignes de confiance. Le but de la logique de
validation est de permettre aux données de franchir en toute sécurité la limite de confiance
- de passer de non fiable à fiable. Une violation des limites de confiance se produit
lorsqu’un programme brouille la frontière entre ce qui est fiable et ce qui ne l’est pas.
En combinant des données fiables et non fiables dans la même structure de données, il
devient plus facile pour les programmeurs de faire confiance à tort à des données non
validées. [31]

2.4.9 La catégorie de « weak randomness »

Les générateurs de nombres pseudo-aléatoires standard ne peuvent pas résister aux
attaques cryptographiques. Des erreurs de caractère aléatoire non sécurisé se produisent
lorsqu’une fonction pouvant produire des valeurs prévisibles est utilisée comme source de
caractère aléatoire dans un contexte sensible à la sécurité. Les générateurs de nombres
pseudo-aléatoires (PRNG) approximent le caractère aléatoire de manière algorithmique,
en commençant par une graine à partir de laquelle les valeurs qui suivent sont calcu-
lées.[41]
Il existe deux types de PRNG : statistiques et cryptographiques
— Les PRNG statistiques : fournissent des propriétés statistiques utiles, mais leur
sortie est hautement prévisible et forme un flux numérique facile à reproduire qui
ne convient pas aux cas où la sécurité dépend du fait que les valeurs générées sont
imprévisibles.
— Les PRNG cryptographiques : résolvent ce problème en générant une sortie
plus difficile à prévoir. Pour qu’une valeur soit sécurisée crypto graphiquement,
il doit être impossible ou hautement improbable pour un attaquant de la distin-
guer d’une valeur réellement aléatoire. En général, si un algorithme PRNG n’est
pas annoncé comme étant crypto graphiquement sécurisé, il s’agit probablement
d’un PRNG statistique et ne doit pas être utilisé dans des contextes sensibles à la
sécurité.

2.4.10 La catégorie de « XPATH injection »

Semblable à l’injection SQL, les attaques par injection XPath se produisent lors-
qu’un site Web utilise des informations fournies par l’utilisateur pour construire une
requête XPath pour des données XML. En voyant des informations intentionnellement

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 46/81
Projet de Fin d’études Pentest des applications web : . . .

malformées sur le site Web, un attaquant peut découvrir comment les données XML
sont structurées où il peut accéder à des données auxquelles elles n’ont normalement pas
accès. Ils peuvent même être en mesure d’élever leurs privilèges sur le site Web si les
données XML sont utilisées pour l’authentification (comme un fichier utilisateur basé sur
XML).[52]

2.4.11 La catégorie de Cross site scripting (XSS)

Les attaques de type Cross-Site Scripting (XSS) sont un type d’injection, dans le-
quel des scripts malveillants sont injectés dans des sites Web. L’injection du script mal-
veillant dans les navigateurs des visiteurs de l’application. Les victimes sont les utili-
sateurs de l’application et non l’application elle-même.[29] Les attaques de cross-site
scripting peuvent être divisées en trois types : stocké, reflectée et DOM XSS :
— Le XSS stocké : se produit lorsqu’un script malveillant est injecté directement
dans une application web vulnérable à partir d’un post ou commentaire rédigé par
l’attaquant, xss stocké est souvent considéré comme un risque élevé ou critique.
— XSS réfléchi : implique la réflexion d’un script malveillant à partir d’une appli-
cation web sur le navigateur d’un utilisateur le script est intégré dans un lien et
n’est activé qu’une fois ce lien est cliqué.[
— DOM cross site scripting : Le XSS basé sur le DOM (ou, comme on l’appelle
dans certains textes, « XSS de type 0 ») est une attaque XSS dans laquelle une
payload de l’attaque est exécutée à la suite de « l’environnement » DOM dans le
navigateur de la victime utilisé par le côté client, de sorte que le code côté client
s’exécute de manière « inattendue ». C’est-à-dire que la page elle-même (c’est-à-
dire la réponse HTTP) ne change pas, mais le code côté client contenu dans la
page s’exécute différemment en raison des modifications malveillantes qui se sont
produites dans l’environnement DOM.

2.5 Les applications de test de sécurité statiques, dy-

namiques et interactives
La prévention est la bonne technique pour éviter les failles de sécurité dans le code
source. En effet, les vulnérabilités peuvent être évitées si les développeurs sont formés
au développement d’applications Web sécurisées pour éviter de faire des « erreurs » qui
pourraient conduire à des failles de sécurité. De toute évidence, la prévention va éviter
certaines vulnérabilités, mais des erreurs de programmation seront toujours commises
malgré l’application des bonnes pratiques préventives sécurisées. Par conséquent, les
outils d’analyse sont toujours nécessaires pour améliorer la reconnaissance de tout type
de vulnérabilité.
Le tableau 2.2 illustre la procédure d’analyse de chaque type d’application de test de
sécurité et la différence entre eux.[16]

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 47/81
Projet de Fin d’études Pentest des applications web : . . .

Type procédure d’analyse

SAST Les outils SAST effectuent une analyse de sécurité en boite blanche ainsi, ils
analysent l’ensemble d’application en couvrant toute la surface d’attaque, ils
sont conçus pour analyser le code source ou les versions compilées du code afin
de détecter les failles de sécurité et ils peuvent également réviser les fichiers de
configuration d’application web.
DAST Les outils DAST sont des outils qui effectuent l’analyse en boîte noire. Les tests
sont lancés contre l’interface de l’application Web. Dans une première phase,
ils essaient de découvrir toutes les entrées sources possibles de l’application
en utilisant l’outil comme proxy d’interception, par effectuant un crawling qui
rassemble certaines informations d’application [Link], les outils effec-
tuent une attaque récursive avec une « payload » malveillante sur toutes les
entrées sources d’application Web découvertes. Par suite chaque réponse http
est analysée pour vérifier si une faille de sécurité existe.
IAST les outils IAST sont des outils en boîte blanche, ce sont une combinaison des
meilleurs caractéristiques des outils SAST et DAST. L’outil IAST s’exécute
directement sur le serveur et doit être intégré dans L’[Link] reposent
sur l’exécution d’un agent sur le côté serveur. Cet agent est chargé de surveiller
le comportement d’application en cours d’intégration, offrant un contrôle des
données, et créant ainsi des scénarios d’attaque.

Table 2.2 – Procédure d’analyse des SAST, DAST et IAST

Le tableau 2.3 présente les caractéristiques de chaque type d’application de test de

sécurité[13] :

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 48/81
Projet de Fin d’études Pentest des applications web : . . .

Type Caractéristiques
SAST - Peuvent trouver des vulnérabilités automatiquement avec une grande
confiance, telles que les débordements de mémoire tampon (buffer memory),
les défauts d’injection SQL, etc.
- Ils s’adaptent bien et peuvent être exécuté sur de nombreux logiciels,
- Met en évidence les fichiers source précis, les numéros de ligne et même les
sous sections de lignes qui sont affectées.
DAST - Les outils DAST découvrent généralement moins de vrai positifs et a égale-
ment moins de faux positifs que les outils SAST,
- Ils permettent la détection des vulnérabilités dans la phase de déploiement
du développement logiciel,
- Le comportement d’un attaquant est simulé pour obtenir des résultats d’ana-
lyse.
IAST - Surveiller le trafic Web (HTTP) et accéder aux composants de l’application,
y compris les bibliothèques, les Framework et les données dans les dépendances
back-end,
- Recueillir des informations sur le contrôle et le flux des données au moment
de l’exécution ;
- La méthode IAST offre une vue complète d’une application et de son envi-
ronnement, ce qui permet de traiter davantage de code, d’offrir des résultats
plus fiables et d’identifier plus de failles de sécurité que les méthodes SAST ou
DAST,
- Accéder aux informations de configuration,
- Accéder à l’ensemble du code de l’application.

Table 2.3 – Les caractéristiques des SAST, DAST et IAST

2.6 Conclusion
Dans ce chapitre nous avons vu les composants du OWASP Benchmark en tant qu’une
application web qui contient des diverses catégories des vulnérabilités chacune contient
des cas de test sur lesquelles nous pouvons appliquer les différents outils de pénétrations
SAST, DAST et IAST.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 49/81
CHAPITRE 3
ANALYSE DU OWASP BENCHMARK ET ÉVALUATION
COMPARATIVE DES SCANNERS

3.1 Introduction
Pour mesurer l’efficacité des scanners de sécurité Web, l’évaluation comparative est
l’un des processus la plus adoptée, son but principal est d’évaluer l’efficacité de ces
scanners et conclure si les résultats rapportés refléteront fidèlement l’état de sécurité
des sites Web examinés, dans notre étude de cas, nous allons évaluer quelques outils de
sécurité en utilisant des métriques bien définies sur lesquels nous allons découvrir les
performances de ces outils.

3.2 Méthodologie de travail

L’évaluation des applications de détection des vulnérabilités est très importante dans
le domaine de sécurité web. Elle permet de fournir des recommandations et des informa-
tions pour aider les administrateurs à choisir le meilleur mécanisme de protection et le
plus adapté pour la sécurité de leur application web.
La méthodologie utilisée dans notre travail repose sur quatre étapes principales :
— Etape1 : Sélection des outils de travail. Notre travail a commencé par une
sélection d’outils. L’objectif était de sélectionner et d’évaluer des scanners de test
de sécurité que le Benchmark OWASP peut générer des résultats :
— Benchmark OWASP : c’est l’outil cible sur lequel nous avons effectué le test
de sécurité. Le projet OWASP Benchmark est une suite de tests Java conçue
pour évaluer la précision, la couverture et la vitesse des outils automatisés
de détection des vulnérabilités logicielles. Sans la capacité de mesurer ces
outils, il est difficile de comprendre leurs forces et leurs faiblesses, et de les
comparer les uns aux autres. C’est une application Web Java Maven open
source, elle fonctionne sur le serveur Tomcat 8.x et le port par défaut est

50
Projet de Fin d’études Pentest des applications web : . . .

8443.[16]. L’application est accessible à partir du navigateur à l’adresse URL :

https ://[Link] :8443/benchmark.
Les scanners que nous avons utilisé pour l’analyse du benchmark OWASP
sont les suivants :
— FindBugs : est un outil open source pour l’analyse de code statique des pro-
grammes Java où il scanne les bogues possibles. C’est également une excel-
lente motivation pour améliorer les compétences des équipes de développement
afin d’écrire un meilleur code en premier lieu. Findbugs recherche d’éventuels
bogues dans le logiciel Java. Chaque résultat est signalé comme une alerte,
mais tous ces alertes ne sont pas nécessairement des défauts, par exemple
des avertissements faisant référence à d’éventuels problèmes de performances.
Tous les alertes sont classés en quatre catégories : (i) les plus effrayants, (ii)
effrayants, (iii) troublants et (iv) préoccupants.[33]
— SpotBugs : SpotBugs est un programme qui utilise l’analyse statique pour
rechercher des bogues dans le code Java, c’est le successeur de FindBugs. Il
permet de faire une "analyse statique", en regardant à travers le code pour
trouver certaines "mauvaises idées connues" : Les choses qui sont susceptibles
de causer des problèmes occasionnels/intermittents, mauvaise performance,
etc.[35]
— PMD : est un analyseur de code source. Il trouve des défauts de program-
mation courants tels que des variables inutilisées, des blocs catch vides, la
création d’objets inutiles, etc. Il prend en charge de nombreuses langues. Il
peut être étendu avec des règles personnalisées. Il utilise JavaCC et Antlr pour
analyser les fichiers source en arbres de syntaxe abstraite (AST) et exécute des
règles contre eux pour trouver les violations. Les règles peuvent être écrites
en Java ou à l’aide d’une requête XPath. Il prend en charge Java, JavaScript,
[Link] Apex, Visualforce, Modelica, PLSQL, Apache Velocity, XML,
XSL et Scala.[32]
— FindSecBugs : Find Security Bugs est un plugin SpotBugs pour les au-
dits statiques de sécurité des applications Web Java et des applications An-
droid. Il peut détecter 128 types de vulnérabilités différents, notamment les
faiblesses de Command Injection, XPath Injection, SQL/HQL Injection, XXE
et Cryptography. SpotBugs est un outil d’analyse statique qui cible Java mais
fonctionne également avec les projets Groovy, Scala et Kotlin. [44]
— OWASP ZAP : Zed Attack Proxy (ZAP) est un outil de détection dyna-
mique open source maintenu sous l’égide de l’Open Web Application Security
Project (OWASP). Il est conçu spécifiquement pour tester des applications
Web. À la base, L’outil proxy ZAP fournit de nombreuses fonctionnalités
telles que le proxy Man-in-the-middle qui se situe entre le navigateur du tes-
teur et l’application Web afin qu’il puisse intercepter et inspecter les messages
envoyés entre le navigateur et l’application Web, modifier le contenu si néces-
saire, puis transférer ces paquets vers la destination. De plus il est équipé de

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 51/81
Projet de Fin d’études Pentest des applications web : . . .

l’outil Spider, le scanner actif, le scanner passif, le navigateur d’application

pour le test manuel, le scanner de socket Web, le scanner SSL et la détec-
tion de vulnérabilité de revue de code [16]. Il dispose également d’un module
mature pour les services Web et l’analyse des API. OWASP ZAP dispose éga-
lement d’une option qui permet aux utilisateurs d’ajouter des fonctionnalités
complémentaires facultatifs à l’outil.[45]
— ShiftLeft : ShiftLeft CORE est une plate-forme de sécurité de code pour les
développeurs, elle combine entre la SAST, détection des secrets, informations,
analyse intelligente[16], son produit NextGen Static Analysis (NG SAST) est
désormais disponible sur GitHub Marketplace. [50] C’est une solution de test
de sécurité des applications statiques (SAST) multiplateforme qui peut égale-
ment être insérée dans votre contrôle de version ou vos flux de travail CI/CD
pour fournir une analyse de code automatisée.[37]
— Etape2 : Analyse du OWASP Benchmark. Cette étape consiste à effectuer
le scan sur le Benchmark OWASP par les applications de test de sécurité choisi,
afin de détecter les divers vulnérabilités existantes.
— Etape3 : Génération des résultats. Cette phase consiste à extraire le fichier
XML des résultats du scan pour chaque scanner et les copier sous le dossier "re-
sults" du benchmark OWASP, afin de générer les resultats en utilisant la ligne de
commande "[Link]" ou .sh
— Etape4 : Evaluation des résultats par les métriques de comparaison.
La dernière étape de ce travail permette d’évaluer les performances de ces scanners
à partir des métriques de comparaison qui sont calculés en utilisant les résultats
obtenu sur la fiche d’évaluation ou "scorecard" que le Benchmark OWASP gènère.
Et par suite éstimer les capacités de chaque outil. Ces métriques sont donnés par :
— Vraie positive (TP) : Une vulnérabilité est correctement détectée.
— Faux positive (FP) : Des vulnérabilités faussement identifiés comme des
vulnérabilités
— Vraie négative (TN) : Aucune vulnérabilité présente et l’outil en n’en dé-
tectant aucune.
— Faux négative (FN) : L’outil n’identifie pas une vulnérabilité qui est réel-
lement présente.
A partir de ces métriques, plusieurs métriques peuvent être calculées :
— Précision : OWASP a défini la précision comme le pourcentage des vulnéra-
bilités correctement détectées par rapport à toutes les vulnérabilités signalées
(y compris celles mal étiquetées). Les valeurs de haute précision indiquent une
précision de détection élevée des vulnérabilités réelles.[3] La formule de cette
métrique est donnée dans l’équation suivante :
TP
P recision = (3.1)
TP + FP

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 52/81
Projet de Fin d’études Pentest des applications web : . . .

— Recall : Le Recall est le nombre de vulnérabilités correctement détectées

représentées en proportion de toutes les vulnérabilités connues (y compris
celles qui doivent être détectées par l’outil mais ne l’ont pas été).[3] La formule
du Recall est donnée dans l’équation suivante :
TP
Recall = (3.2)
TP + FN
— F-value : La moyenne harmonique de Precision et Recall, elle est donnée par
la formule suivante :
Recall × P recision
F − value = 2 × (3.3)
Recall + P recision
— L’indice de Youden : a été proposé pour évaluer la performance des tests
analytiques. Il génère des valeurs dans l’intervalle [-1, 1], où une valeur de
1 indique une détection parfaite c’est à dire la détection de toutes les vul-
nérabilités sans faux positifs, la valeur -1 n’indique que des faux positifs et
aucun vrai positif c’est-à-dire aucune vulnérabilité réelle détectée ; et un in-
dice de Youden de 0 signifie que l’outil a enregistré le même résultat pour une
application Web avec des vulnérabilités et une application web sans vulnéra-
bilités c’est-à-dire un résultat invalide. L’équation suivante montre la formule
de calcul de l’indice de Youden.[3]
TP TN
Y oudenIndex = + −1 (3.4)
TP + FN TN + FP
— Taux des vrais positifs : Le taux de détection nous indiquerait combien de
vulnérabilités l’application a pu détecter avec succès. Il montrera également
la capacité de l’application à détecter diverses vulnérabilités. Il est calculé par
la relation suivante :
TP
TPR = × 100 (3.5)
TP + FN
— Taux des faux positifs Le taux des faux positifs sont les vulnérabilités
qui ont été signalées par le scanner comme positives mais non présentes dans
l’application. Le scanner qui fournit un pourcentage inférieur de résultats
faussement positifs est préféré. Sa formule est donnée par :
FP
FPR = × 100 (3.6)
FP + TN
— Le score : c’est à dire le taux global des vrais positifs (TPR) dans toutes les
catégories de test, moins le taux global des faux positifs (FPR). Il est donné
par :
Score = T P R − F P R (3.7)
— Web Benchmark Evaluation :Le projet de référence OWASP a proposé
un système d’évaluation de l’efficacité des outils d’analyse appelé guide d’in-
terprétation des résultats WBE.. C’est une représentation visuelle des per-
formances de détection d’un outil en représentant le taux des vrais positifs

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 53/81
Projet de Fin d’études Pentest des applications web : . . .

en fonction du taux des faux positifs. Comme le montre la figure 3.1 la ligne
s’étendant du point (0%, 0%) à (100%, 100%) est appelée "ligne de devinettes".
Si un outil s’est trouvé dans le coin supérieur à droite cela veut dire que l’outil
a tout signalé comme des vulnérabilités par contre l’emplacement d’un outil
dans le coin inférieur à gauche signifie que l’outil n’a enregistré aucune vulné-
rabilité. De plus, le coin supérieur à gauche est l’emplacement idéale indiquant
la meilleur précision de détection et si l’emplacement de l’outil est au milieu de
la ligne de devinettes c’est-à-dire 50% des TPR et 50% des FPR, cela indique
que les vulnérabilités sont détectées d’une manière aléatoire par cet outil.

Figure 3.1 – Le graphe d’évaluation du OWASP Benchmark

3.3 Analyse du OWASP Benchmark par les applica-

tions de test de sécurité
3.3.1 Environnement de travail
Pour la réalisation de ce travail, nous avons utilisé un ordinateur portable HP équipé
d’un processeur IntelCore i5 avec une vitesse d’exécution de 2 .70 GHz et une mémoire
RAM de 8 Go, un disque dur de 244 Go et qui utilise comme un système d’exploitation
Windows 10 de 64 bit.

3.3.2 Le choix des outils de travail

Le benchmark de test adéquat doit être crédible, portable, représentatif, nécessiter un
minimum de modifications et être facile à mettre en œuvre, et l’exécution des outils doit

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 54/81
Projet de Fin d’études Pentest des applications web : . . .

se faire dans les mêmes conditions. Comme était étudié dans [12] plusieurs benchmarks
de sécurité pour les applications Web comme WAVSEP utilisé dans les comparaisons de
[1] et [8], Benchmark sécurisé Micro Project utilisé dans les travaux de [10] et [11], Projet
Software Assurance Metrics And Tool Evaluation (SAMATE) du National Institute of
Standards and Technology (NIST) [14] [5] [9] [6], Projet de Benchmark OWASP [43],
Delta-bench par Pashchenko et al[15]. Et OWASP Top Ten Benchmark adapté pour les
projets des catégories de vulnérabilité OWASP Top Ten 2013, 2017 et 2021 et conçu
pour l’analyse statique uniquement utilisé dans les travaux de Bermejo et al[7]. Compte
tenu des statistiques de vulnérabilités de sécurité rapportées par plusieurs études, le
benchmark de test le plus adéquat pour l’utilisation des outils SAST, DAST et IAST est
le projet de Benchmark OWASP. Ce benchmark est une application web open source en
langage Java déployée dans Apache Tomcat. Il répond aux propriétés requises pour un
benchmark et couvre les failles de sécurité dangereuses des applications Web selon les
projets OWASP Top Ten 2013, 2017 et 2021. Il contient des cas de test exploitables pour
détecter les vrais et les faux positifs, chacun mappé à des CWE spécifiques, qui peuvent
être analysés par tout type d’outil de test de sécurité des applications (AST), y compris
les outils SAST, DAST (comme OWASP ZAP) et IAST. Et comme mentionné dans [12]
320 cas de test du projet de référence OWASP ont été séléctionné au hasard et les avaient
répartis également en fonction du nombre et du type de vulnérabilités représentées dans
le benchmark de test. Parmi ces cas, la moitié sont des faux positifs et la moitié sont des
vrais positifs. Il est facilement portable en tant que projet Java et ne nécessite aucune
modification avec aucun outil.
Les scanners de test de sécurité que nous avons utilisé dans ce travail pour évaluer
leurs performances sont des outils statiques tels que : FindBugs v3.0.1, SpotBugs v4.2.3,
PMD v 6.29.0, FindSecBugs v1.11.0, ShiftLeft et dynamique, tel que : OWASP ZAP
v2.10.0 et nous avons considéré plusieurs critères pour le choix de ces scanners :
— Ils sont des outils open sources, ce qui nous permettre de bénéficier de tous leurs
caractéristiques, au contraire de certains outils commerciaux qui offrent des essais
gratuits mais avec des choix limités ce qui nous donne pas la possibilité d’avoir des
résultats bien précis aussi que, la possibilité du scan juste pour une application cible
du choix de développeur. Par contre, ShiftLeft était un outil statique commercial
que nous avons utilisé par l’essai gratuit et de profiter de ses caractéristiques et
avoir des résultats du scan pour le benchmark OWASP sans problème.
— La convivialité et la simplicité d’installation et de configuration. C’est à dire, Leur
déploiement s’intégrent dans un processus d’audit régulier et surtout structuré.
— Le reporting était un argument majeur pour le choix des scanners de vulnérabilités.
En effet, certains outils que nous avons extrait leurs fichiers xml aprés la phase du
scan, ne se conforment pas avec les fichiers xml que le benchmark OWASP peut
générer des résultats, ce qui pose un grand problème. Par conséquent nous arrivons
à travailler avec ces outils qui ne pose pas ce problème.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 55/81
Projet de Fin d’études Pentest des applications web : . . .

3.3.3 Analyse du Benchmark OWASP par FindBugs, SpotBugs,

FindSecBugs et PMD
Nous avons adopté deux approches pour effectuer l’analyse sur OWASP Bench-
mark, en utilisant la ligne de commande et la deuxième approche en utilisant l’interface
graphique. Nous avons utilisé les deux méthodes pour l’audit, la ligne de commande et
l’interface graphique, cette dernière permette d’apercevoir les différentes bugs détectés
et les alertes en indiquant la sévérité de chaque vulnérabilité.
— L’approche 1 : en utilisant l’interface graphique : La figure 3.2 présente l’IDE du
SpotBugs, nous avons ajouté un projet où nous allons analyser le benchmark en
ajoutant l’emplacement du dossier approprié pour l’audit.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 56/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 3.2 – L’IDE de SpotBugs

Ensuite, on attend quelques minutes jusqu’à ce que le scan sera terminé comme le
montre la figure 3.3.

Figure 3.3 – La phase du scan pour SpotBugs sur OWASP Benchmark

La figure 3.4 présente les différents bugs détectés lors du scan qui sont en total
6829 bugs :

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 57/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 3.4 – Les résultats du scan pour SpotBugs

La figure 3.5 montre les détails d’un bug détecté, ils sont affichés dans la barre en
bas de la page,

Figure 3.5 – Les détails des bugs détectés par SpotBugs

— L’approche 2 : En utilisant la ligne de commande : Pour les scanners FindBugs,

PMD et FindSecBugs, nous avons utilisé la ligne de commande pour analyser le
benchmark en utilisant la commande « [Link] », « [Link] » et « Find-
[Link] » respectivement, et nous avons obtenu le résultat du scan sous fichier
xml qui a été enregistré automatiquement après le scan dans le fichier « results ».

3.3.4 Analyse du Benchmark OWASP par OWASP ZAP

Pour exécuter ZAP par rapport au Benchmark, ZAP crée un serveur proxy et fait
passer le trafic du site web via le serveur. L’utilisation des scanners automatiques dans
ZAP permet d’intercepter les vulnérabilités sur le site web. Le processus d’analyse est
résumé dans la figure 3.6.[46]

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 58/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 3.6 – Le processus d’analyse de OWASP ZAP

En général le scan passe par trois étapes : la première étape est un démarrage rapide
dont on exécute l’araignée (il joue le rôle d’un crawler). Celui-ci parcourt toutes les
URLs qui composent l’application. Pour être plus précis la phase de démarrage rapide
rassemble à viser et photographier. La figure 3.7 illustre l’IDE du OWASP ZAP avec la
phase du démarrage rapide effectué.

Figure 3.7 – L’IDE du OWASP ZAP avec la phase du démarrage rapide effectué

La deuxième étape consiste à attaquer tous les entrées sources découverts pour vérifier
si une faille de sécurité existe en effectuant un scan active. Nous avons désactivé tous les
plugins sauf : XSS (Reflected), Path Traversal, SQLi, OS Command Injection. De même,
dans l’onglet Technologie, nous avons désactivé tout et activez uniquement : MySQL, OS
pour windows, Tomcat. Cette phase a permis OWASP ZAP de détecter les vulnérabilités

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 59/81
Projet de Fin d’études Pentest des applications web : . . .

qui vont être évaluer par OWASP Benchmark.

Figure 3.8 – La fenêtre de technologie du OWASP ZAP

La figure 3.9 montre la progression du scan dont OWASP ZAP a terminé la phase
d’analyse active.

Figure 3.9 – La fenêtre de la progression du scan de OWASP ZAP

La troisième étape est la visualisation des vulnérabilités trouvés lors du scanning avec
la sévérité de chaque type. La figure 3.10 montre les alertes avec les détails des failles
trouvés.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 60/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 3.10 – Les alertes d’analyse trouvés

3.3.5 Analyse du Benchmark OWASP par ShiftLeft

Aprés avoir contacter la communauté ShiftLeft, ils m’ont offert un free trial d’une
durée de 15 jour pour le test. On a commencé par configurer et s’authentifir avec ShiftLeft
en liant notre compte GitHub avec ShiftLeft.

Figure 3.11 – Authentification avec ShiftLeft sur GitHub

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 61/81
Projet de Fin d’études Pentest des applications web : . . .

Nous avons trois méthodes d’analyse pour ShiftLeft, par ligne de commande, en choi-
sissant d’autre repositories sur lesquelles nous voulons effectuer le scan ou en choisissant
l’une des repositories offerte par ShiftLeft, cette dernière est la méthode que nous avons
utilisé pour effectuer le scan.

Figure 3.12 – Les méthodes fournis par GitHub pour le scan

Ensuite, on a choisit la repository du OWASP Benchmark.

Figure 3.13 – Interface de choix de scan fournis par ShiftLeft

On attend quelques instants pour que le workflow soit préparé. Ensuite, nous avons
attendu jusqu’à ce que le scan soit terminé. Et nous pouvons visualiser les différentes
vulnérabilités trouvées lors du scan avec la sévérité comme le montre les figures 3.14 et
3.15.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 62/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 3.14 – Les résultats obtenus après le scan

Figure 3.15 – Les catégories des vulnérabilités trouvées après le scan

3.4 Les métriques de comparaison des performances

des applications de test de sécurité

3.5 Résultats
Comme était mentionné avant, pour la génération des résultats de l’ensemble des
scans efféctués, il suffit de copier les fichiers « xml » des résultats sous le dossier «
results » dans le Benchmark. Ce dernier utilise les fichiers de type « xml » pour la
génération du scorecard. En effet, les fichier « xml » des résultats du scan pour FindBugs,
SpotBugs, PMD et FindSecBugs sont enregistrés automatiquement après la fin du scan.
D’un autre coté, nous avons extrait le fichier manuellement après le scan et le copier sous
« results » pour OWASP ZAP. Par contre, la génération du scorecard pour ShiftLeft
était individuelle. Nous avons téléchargé le fichier zip après la phase du scan contenant
le scorecard des résultats du scan.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 63/81
Projet de Fin d’études Pentest des applications web : . . .

3.5.1 Les résultats des métriques TP, FP, TN, FN

D’aprés le tableau 3.1, on remarque que ShiftLeft à enregistré le grand nombre des
vrais positifs, c’est à dire le grand nombre des vulnérabilités réelles , suivi par FindSec-
Bugs, OWASP ZAP ensuite, FindBugs et SpotBugs qui ont détecté le même nombre des
(TP) et enfin PMD qui n’a pas pu détecté aucune vrai positif. Concernant le nombre
des faux positifs où l’outil détécte des vulnérabilités qui ne sont pas présentes, PMD
n’a pas les enregistré, cependant OWASP ZAP a enregistré le moins nombre par rap-
port aux autres scanners, suivi par FindBugs et SpotBugs de même nombre des (FP),
ensuite ShiftLeft et enfin FindSecBugs qui a enregistré le plus grand nombre des (FP).
En arrivant aux vrais négatifs qui signifie que l’outil ne detécte pas une vulnérabilité
qui n’est pas présente, on constate que PMD a enregistré le grand nombre, suivi par
OWASP ZAP, par suite FindBugs et SpotBugs de même nombre, suivi par ShiftLeft
et enfin FindSecBugs. En outre, les faux négatifs indiquent aux testeurs que l’outil ne
detécte pas des vulnérabilités qui sont réellement présentes. En effet, PMD a enregistré
le grand nombre des (FN) et aprés arrive FindBugs et SpotBugs suivi par OWASP ZAP
ensuite FindSecBugs et enfin ShiftLeft qui n’a pas detécté un faux négative.

Les scanners de Type TP FP TN FN

test
FindBugs v3.0.1 SAST 150 131 1194 1265
SpotBugs v4.2.3 SAST 150 131 1194 1265
PMD v6.29.0 SAST 0 0 1325 1415
FindSecBugs SAST 1375 640 685 40
v1.11.0
OWASP ZAP DAST 418 11 1314 997
v2.10.0
ShiftLeft SAST 1415 296 1029 0

Table 3.1 – Les métriques des scanners de test : TP, FP, TN et FN

3.5.2 Les résultats des métriques : TPR, FPR, Score

Le tableau 3.2 montre que ShiftLeft a le meilleur score par rapport aux autres scanners
puisque il a pu enregistré un pourcentage des vrais positifs qui attenid (100%) et un taux
des faux positifs de (25.57%). Suivi par FindSecBugs pour un score de (43.75%) vu que
le taux des vrais positifs est trés grand de (97.18%) et un taux des faux positifs de
(53.40%). Ensuite, OWASP ZAP pour un score de (19.76%) résultat du taux des vrais
positifs (20.30%) et un taux des faux positifs négligeable (0.53%). Puis, le scanner PMD
qui a un score de (0%) puisqu’il n’a pas des vrais positifs et des faux positifs. Enfin,
SpotBugs et FindBugs ont un négative score vu que le taux des faux positifs et plus
grand que le taux des vrais positifs à cause de nombre des faux négatifs qui sont plus

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 64/81
Projet de Fin d’études Pentest des applications web : . . .

grand que le nombre des vrais négatifs.

Les scanners de TPR FPR Score

test
FindBugs v3.0.1 5.12% 5.19% -0.07%
SpotBugs v4.2.3 5.12% 5.19% -0.07%
PMD v6.29.0 0% 0% 0%
FindSecBugs 97.18% 53.40% 43.75%
v1.11.0
OWASP ZAP 20.30% 0.53% 19.76%
v2.10.0
ShiftLeft 100% 25.57% 74.43%

Table 3.2 – Les métriques des scanners de test : TPR, FPR et Score

Figure 3.16 – Les scores enregistrés pour chaque scanner de test

3.5.3 Les taux des vulnérabilités detéctés pour chaque catégo-

rie
Les figures 3.17 et 3.18 illustrent les poucentages des catégories de CWE que le
benchmark OWASP contient et que chaque scanner de test a pu detécter.
— Command injection : ShiftLeft a enregistré le plus grand nombre des vulnéra-
bilités de la catégorie « command injection » pour un score de (64%), suivi par
FindSecBugs de (11%), ensuite SpotBugs, FindBugs et PMD qui n’ont pas arrivé
à detécter des vulnérabilités pour cette catégorie. Et enfin un score de (-2%) pour

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 65/81
Projet de Fin d’études Pentest des applications web : . . .

OWASP ZAP à cause du taux des faux positifs qui était plus grand que le taux
des vrais positifs.
— Insecure cookie : Concernant la catégorie « insecure cookie », FindSecBugs et
ShiftLeft ont réussi à detécter tous les vulnérabilités de cette catégorie d’un score
de (100%) pour les deux scanners, suivi par OWASP ZAP qui a pu enregistrer un
grand score de (64%). Cependant, SpotBugs, FindBugs et PMD n’ont pas detécté
des vulnérabilités de la catégorie « insecure cookie ».
— LDAP injection : Quant à la catégorie « LDAP injection », le grand score enre-
gistré était de la part de ShiftLeft de (59%), puis FindSecBugs qui a enregistré un
score de (16%). Autrement, nous remarquons une absence de détection pour cette
catégorie à propos des scanners : SpotBugs, FindBugs,PMD et OWASP ZAP.
— Path Traversal : Le grand score enregistré pour la catégorie « Path Traversal »
était de ShiftLeft d’une valeur de (47%), ensuite OWASP ZAP pour un score de
(14%), puis FindSecBugs d’un score de (4%) en quatrième lieu, SpotBugs qui n’a
detécté que (1%) et PMD qui n’a enregistré aucune valeur de ce type de catégorie
(0%). En revanche, FindBugs a enregistré un score négatif de (-2%).
— SQL injection : OWASP ZAP est le scanner qui a enregistré le maximum des
vulnérabilités de la catégorie « SQL injection » pour un score de (67%) suivi par
ShiftLeft de (63%) en troisième lieu, il arrive FindSecBugs pour un score de (9%) et
puis, FindBugs qui n’a enregistré que (1%) et absence de detéction pour PMD(0%).
Enfin, un score de (-2%) pour SpotBugs.

Figure 3.17 – Les taux des vulnérabilités détectés

— Trust Boundary : Cette catégorie des vulnérabilité était detécté par ShiftLeft
pour un score de (44%), c’est la valeur la plus grande par rapport aux autres
scanners, ensuite arrive FindSecBugs qui a enregistré une valeur de (19%) pourtant,

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 66/81
Projet de Fin d’études Pentest des applications web : . . .

SpotBugs, FindBugs, PMD et OWASP ZAP n’ont enregistré aucune vulnérabilité

pour la catégorie « Trust Boundary »
— Weak encryption : Par suite, nous arrivons à la catégorie « Weak encryption »,
FindSecBugs et ShiftLeft étaient les seules scanners qui ont pu detécter des vulnéra-
bilités de cette catégorie. De plus ils sont réussi à découvrir toutes les vulnérabilités
d’un score de (100%).
— Weak hashing : Comme ShiftLeft a découvert toutes les vulnérabilités de la caté-
gorie « Weak hashing » d’un score de (100%), FindSecBugs a pu aussi enregistrer
une valeur importante de score (69%). Alors que, les outils FindBugs, SpotBugs,
PMD et OWASP ZAP n’ont arrivé à découvrir aucune vulnérabilité de cette caté-
gorie.
— Weak randomness : Le score (100%) était enregistré par FindSecBugs et Shift-
Left comme le meilleur score. D’un autre coté, SpotBugs, FindBugs, PMD et
OWASP ZAP n’ont pu découvrir aucune vulnérabilité de la catégorie « Weak
randomness ».
— Xpath injection : Les vulnérabilités découvert par ShiftLeft pour la catégorie
« Xpath injection » étaient d’un score de (65%) et c’est la plus grande valeur
enregistré par rapport aux autres scanners, suivi par FindSecBugs qui a detécté
un score minimale de (5%) en outre, SpotBugs, FindBugs PMD et OWASP ZAP
n’ont enregistré aucune valeur pour cette catégorie.
— Cross site scripting : Enfin, la catégorie « cross site scripting » que ShiftLeft
a pu découvrir le maximum des vulnérabilités de cette catégorie par rapport aux
autres scanners, pour un score de (77%), suivi par OWASP ZAP qui a aussi réussi
d’enregistrer un grand score de (76%) et FindSecBugs d’un score de (48%) alors
que, FindBugs, SpotBugs et FindSecBugs avaient un score null pour cette catégrie.

3.5.4 Les métriques de comparaison : Précision, Recall, F-value

et Indice de Youden
L’utilisation des métriques de comparaison est une étape très importante qui permet
de nous informer plus sur la performance de chaque scanner de test de sécurité, ses
capacités, ainsi que ses faiblesses.
Le tableau 3.3 regroupe tous les valeurs des métriques calculés.
La figure 3.19 illustre le pourcentage des métriques utilisés pour la comparaison :
Précision, Recall et F-value.
— Précision : Tout d’abord le pourcentage de précision pour OWASP ZAP est le
plus élevé par rapport aux autres scanners de (97%), ce qui veut dire que OWASP
ZAP a une très haute précision de détection des vulnérabilités réelles, suivi par
ShiftLeft dont il a pu atteindre une valeur de (82.7%) de précision par suite, il
arrive FindSecBugs d’une valeur de (68%) puis, FindBugs et SpotBugs qui ont
enregistré une valeur de précision de (53%) et finalement PMD qui n’a aucune
précision de détection.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 67/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 3.18 – Les taux des vulnérabilités détectés

Les scanners de Précision Recall F-value Youden

test Index
FindBugs v3.0.1 0.53 0.106 0.176 0.007
SpotBugs v4.2.3 0.53 0.106 0.176 0.007
PMD v6.29.0 0 0 0 0
FindSecBugs 0.68 0.97 0.80 0.49
v1.11.0
OWASP ZAP 0.97 0.295 0.45 0.28
v2.10.0
ShiftLeft 0.827 1 0.45 0.77

Table 3.3 – Les métriques de comparaison : Précision, Recall, F-value et Youden Index

— Recall : La deuxième métrique est le Recall, comme ShiftLeft a enregistré la plus

grande valeur de Recall de (100%) cela montre qu’il a pu détecter tous les vulné-
rabilités connues sur OWASP Benchmark suivi par FindSecBugs d’un pourcentage
de (97%) de même il a presque pu détecter tous les vulnérabilités connues, ensuite
OWASP ZAP pour un pourcentage de (29.5%) puis, SpotBugs et FindBugs qui
n’ont enregistré qu’un pourcentage de (10.6%) et Finalement une valeur null de
Recall pour PMD puisqu’il n’a détecté aucune vrai positif.
— F-value : La métrique suivante est F-value et nous observons que FindSecBugs a
la plus grande valeur de F-value (80%). Suivi par, OWASP ZAP et ShiftLeft pour
une valeur de (45%) pour les deux scanners, ensuite arrive FindBugs et SpotBugs
d’un pourcentage de (17.6%), mais encore PMD est le dernier vu qu’il a une valeur
null pour la précision et Recall.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 68/81
Projet de Fin d’études Pentest des applications web : . . .

Figure 3.19 – Précision, Recall, F-value pour les scanners de test

— L’indice de Youden : La figure 3.20 présente les valeurs de l’indice de Youden

pour les scanners de test. En effet, ShiftLeft a l’indice de Youden le plus élevé (0,77),
ce qui indique son efficacité à détecter les vulnérabilités connues, avec peu de faux
positifs. Les prochains scanners les mieux notés étaient FindSecBugs et OWASP
Zap avec respectivement (0.49) et (0,28). Puis arrivent SpotBugs et FindBugs
(0.00714) ce qui est une valeur négligeable, de même PMD a signalé un indice de
Youden nul. Par conséquent, SpotBugs, FindBugs et PMD ont enregistré le même
résultat pour une application Web avec des vulnérabilités et une application web
sans vulnérabilités.

Figure 3.20 – Indice de Youden pour les scanners de test

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 69/81
Projet de Fin d’études Pentest des applications web : . . .

— Web Benchmark Evaluation : Comme était montré avant dans la section 3.2,
le positionnement du scanner dans le guide des résultats montre son efficacité. En
effet, d’après la figure 3.21 les scanners Find Bugs, SpotBugs et PMD sont trouvés
dans le coin inférieur à gauche, cela montre que les trois scanners ont signalé que
rien n’est vulnérable puisque les taux des faux positifs et des vrais positifs sont
bas pour FindBugs et SpotBugs et null pour PMD. De plus, OWASP ZAP est
positionné proche de la zone " outil signale rien n’est vulnérable" puisqu’il a un
taux de vrais positifs qu’on peut considérer faible et un taux des faux positifs
négligeable. En revanche, l’emplacement de FindSecBugs est en haut au milieu et
entre les deux zones "détection idéal des vulnérabilités" et "l’outil signale que le tout
est vulnérable" vu qu’il a un taux des vrais positifs très élevé et un taux de faux
positifs moyen. Et enfin, Shiftleft est positionné en haut à gauche, ce qui montre
son emplacement idéal et que ShiftLeft a une précision de détection très élevée vu
qu’il a détecté toutes les vulnérabilités réelles avec un taux des faux positifs faible
.

Figure 3.21 – Guide d’interprétation du OWASP WBE

3.5.5 La vitesse du scan

La vitesse du scan est aussi un paramètre qui indique la performance d’un outil. Par
conséquent, le temps mis par l’application pour analyser complètement l’application est
essentiel pour en comprendre l’efficacité. Dans notre évaluation, nous analysons OWASP
Benchmark et enregistrons le temps du scan. D’après le tableau 3.4 l’outil qui a enregistré
le moins temps de scan est PMD pour une durée de 50 s ensuite, SpotBugs d’une durée
de (2 min et 42s), puis FindSecBugs (2 min et 52 s). Alors que FindBugs a passé une
durée de (3 min et 34s). Par contre, ShiftLeft (11 min et 37s), et filnalement OWASP
Zap qui a effectué une durée de scan la plus élevé (2 jours et 10 heures).

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 70/81
Projet de Fin d’études Pentest des applications web : . . .

Les Scanners de test La durée du scan

FindBugs v3.0.1 3 min et 34 s
SpotBugs v4.2.3 2 min 42 s
PMD v6.29.0 50 s
FindSecBugs v1.11.0 2 min 52 s
OWASP ZAP v2.10.0 2 jours et 10 heures
ShiftLeft 11 min et 37 s

Table 3.4 – La vitesse du scan des outils de test

3.6 Discussion
Les résultats obtenus dans cette étude ont révélé que les scanners fonctionnent diffé-
remment dans différentes catégories. Par conséquent, aucun scanner ne peut être consi-
déré comme l’outil le plus performant pour analyser les vulnérabilités Web. De plus, on
a constaté que les performances des scanners varient en fonction de plusieurs critères
et métriques de comparaison, et nous avons conclu que ShiftLeft a obtenu des meilleurs
résultats pour la majorité des catégories des vulnérabilités, d’autre part la valeur la plus
élevé de l’indice de Youden et Recall était de ShiftLeft. Autrement, FindSecBugs a aussi
réussi à avoir la plus grande valeur de F-value ainsi, des résultats très intéressantes pour
détecter les vulnérabilités des catégories « insecure cookie », « weak encryption », «
weak randomness », « weak hashing » et « xss ». De plus, nos résultats ont confirmé
qu’il y avait eu beaucoup d’améliorations dans cette version de ZAP par rapport à ses
versions précédentes dans les catégories « SQLI », « Insecure cookie», « Path traversal »
et « xss » en découvrant un grand nombre des vulnérabilités pour ces catégories. D’un
autre côté, la précision de detéction du OWASP ZAP était la plus grande par rapport
aux autres scanners de test. En revanche, SpotBugs et FindBugs ont obtenu presque les
mêmes résultats du scan puisqu’ils ont les mêmes règles de scan, à la fin ils ont révélé des
valeurs minimales pour Recall, F-value et une valeur de précison moyenne. Enfin l’outil
PMD peut être considérée comme l’outil le moins performant vu qu’il n’a pas réussi à
détecter des vrais positifs et des faux positifs.

3.6.1 Recommandations
Nous recommandons aux développeurs des applications web :
— Les développeurs des scanners de vulnérabilité Web open source sont recommandés
pour améliorer l’efficacité de vérification de la sécurité de leurs outils afin de vérifier
si les vulnérabilités signalées par ces scanners sont des faux positifs ou des vrais
positifs, par exemple le cas du scanner PMD.
— Il est également recommandé d’améliorer les capacités de scan des scanners de sorte
que, les URLs de l’application web cible, soient identifiés et que toutes les pages

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 71/81
Projet de Fin d’études Pentest des applications web : . . .

Web qui sont longues aux domaines examinés sont traversées pour augmenter la
couverture d’attaque, et donc découvrir plus de vulnérabilités.
— Les testeurs de pénétration doivent également être informer des circonstances pou-
vant causer à un scanner de ne pas détecter certaines vulnérabilités ou ne pas
arriver à interpréter le comportement observé de l’application cible.[2]
— Pour les applications de référence, il est nécessaire d’améliorer la conception des cas
des tests pour que les scanners peuvent analyser des vulnérabilités plus complexes
dans d’autres catégories.
— Les rapports générés par les outils de test d’intrusion devraient également être
d’une structure adapté avec les rapports que les applications de références comme
OWASP Benchmark peuvent générer des résultats d’évaluation.

3.6.2 Conclusion
D’après ce chapitre, nous avons pu évaluer l’efficacité des scanners de sécurité Web,
en utilisant OWASP Benchmark en effet, Les variations des performances de ces scanners
dans différentes catégories de vulnérabilité ont été démontrées expérimentalement. Nous
avons présenté les résultats de cette comparaison à partir de la génération du « score-
card » et par suite conclure l’efficacité de chaque outil par rapport à l’autre en utilisant
les métriques de comparaison. Et finalement nous avons cité des recommandations pour
améliorer les performances des applications de test de sécurité.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 72/81
 CONCLUSION GÉNÉRALE ET PERSPECTIVES

L’utilisation des différents types des scanners de sécurité pour détecter des vulnéra-
bilités de sécurité qui pouvent endommager les systèmes d’informatin, aide à la fois les
développeurs et les organisations à publier des applications en toute sécurité, réduisant
ainsi le temps et les ressources qui doivent être fournis ultérieurement pour corriger les
erreurs initiales. C’est au cours du cycle de vie de développement logiciel sécurisé d’une
application que les outils de détection de vulnérabilité aident à intégrer naturellement la
sécurité dans l’application Web. Il est donc nécessaire d’utiliser les scanners de différente
types tel que : SAST, DAST et IAST dans les phases de développement d’une applica-
tion Web sécurisée. Cependant, analyser les différents composants de la cible application
pour révéler les vulnérabilités réelles et éliminer les faux positifs nécessite des outils
d’analyse améliorés pouvant détecter le plus grand nombre des vrais positifs et moins de
faux positifs afin d’avoir des informations correctes sur la structure d’application cible.
Dans notre travail nous avons étudié les performances des outils : FindBugs, SpotBugs,
PMD, FindSecBugs, OWASP ZAP et ShiftLeft chacun par rapport à l’autre à partir des
résultats d’évaluation et les métriques de comparaison qui ont montré clairement l’effi-
cacité du ShiftLeft et FindSecBugs en tant que des applications web statiques et aussi
la performance du OWASP ZAP en tant qu’une application web dynamique.
L’adoption des scanners de vulnérabilité Web avec les différences dans les fonction-
nalités fournies par leurs approches de détection de vulnérabilité permette d’avoir plus
d’informations sur le système cible.
Les résultats de notre évaluation comparative d’un ensemble des scanners open sources
et dynamique ont mis en évidence des variations dans l’efficacité de la détection des vul-
nérabilités de sécurité et ont indiqué qu’il existe des corrélations entre les différentes
propriétés de performance de ces scanners, telque :le nombre de vulnérabilités détectées,
la précision, Recall, F-value et Indice de Youden.

73
 ANNEXE : INSTALLATION ET CONFIGURATION DU
BENCHMARK OWASP

Pour l’installation du OWASP Benchmark, il faut s’assurer que les éléments suivants
sont correctement installés et configurés
— GIT : https ://[Link]/ ou https ://[Link]/

Figure A.1 – L’interface GitHub

— Maven : https ://[Link]/ (Version : 3.2.3 or newer works.) : Après

avoir installé « appache-maven » et l’ ajouter à la path :

Figure A.2 – L’ajout du apache-maven-3.8.1 à la path

S’assurons que le « maven » s’est installé correctement :

74
Projet de Fin d’études Pentest des applications web : . . .

Figure A.3 – L’exécution de la commande pour apache-maven

— Java : https ://[Link]/java/technologies/[Link] (Java

7 or 8) (64-bit).Nous avons utilisé la version 15.0.1 de Java :

Figure A.4 – L’exécution de la commande pour Java

Ensuite, nous arrivons à la construction et l’exécution du Benchmark, et pour tout

télécharger et tout construire, nous devons :
— Faire un clone du benchmark à partir du GitHub en exécutant la commande
suivante : git clone https ://[Link]/OWASP-Benchmark/Benchmark

Figure A.5 – Importer le Benchmark OWASP de GitHub

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 75/81
Projet de Fin d’études Pentest des applications web : . . .

— Accéder au répértoire du Benchmark en éxécutant la commande « cd benchmark

»
— Après, on compile le Benchmark par la commande «mvn compile»

Figure A.6 – Exécution de la commande « mvn compile »

Figure A.7 – Compilation du OWASP Benchmark

— Par suite, on compile et on éxécute le Benchmark en utilisant la commande «

[Link]/.bat »

Figure A.8 – Compilation et exécution du OWASP Benchmark

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 76/81
Projet de Fin d’études Pentest des applications web : . . .

Figure A.9 – Compilation et exécution du OWASP Benchmark

— Maintenant, on peut accéder au navigateur web pour lancer l’application web via
l’URL : https ://localhost :8443/benchmark/

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 77/81
 RÉFÉRENCES

Bibliographie
[1] Saed Alavi, Niklas Bessler et Michael Massoth. “A comparative evaluation of
automated vulnerability scans versus manual penetration tests on false-negative er-
rors”. In : Proceedings of the Third International Conference on Cyber-Technologies
and Cyber-Systems, IARIA, Athens, Greece. 2018, p. 18-22.
[2] Mansour Alsaleh et al. “Performance-based comparative assessment of open
source web vulnerability scanners”. In : Security and Communication Networks
2017 (2017).
[3] Richard Amankwah et al. “An empirical comparison of commercial and open-
source web vulnerability scanners”. In : Software : Practice and Experience 50.9
(2020), p. 1842-1857.
[4] Philippe De Ryck et al. “Web-platform security guide : Security assessment of
the web ecosystem”. In : Deliverable D1 1 (2013).
[5] Gabriel Dıaz et Juan Ramón Bermejo. “Static analysis of source code security :
Assessment of tools against SAMATE tests”. In : Information and software tech-
nology 55.8 (2013), p. 1462-1476.
[6] Katerina Goseva-Popstojanova et Andrei Perhinschi. “On the capability of
static code analysis to detect security vulnerabilities”. In : Information and Soft-
ware Technology 68 (2015), p. 18-33.
[7] Juan R Bermejo Higuera et al. “Benchmarking Approach to Compare Web Appli-
cations Static Analysis Tools Detecting OWASP Top Ten Security Vulnerabilities”.
In : Computers, Materials and Continua 64 (2020), p. 3.
[8] SE Idrissi et al. “Performance evaluation of web application security scanners for
prevention and protection against vulnerabilities”. In : International Journal of
Applied Engineering Research 12.21 (2017), p. 11068-11076.

78
Projet de Fin d’études Pentest des applications web : . . .

[9] R Krishnan, Margaret Nadworny et Nishil Bharill. “Static analysis tools for
security checking in code at motorola”. In : ACM SIGAda Ada Letters 28.1 (2008),
p. 76-82.
[10] V Benjamin Livshits et Monica S Lam. “Finding Security Vulnerabilities in Java
Applications with Static Analysis.” In : USENIX security symposium. T. 14. 2005,
p. 18-18.
[11] Michael Martin, Benjamin Livshits et Monica S Lam. “Finding application
errors and security flaws using PQL : a program query language”. In : Acm Sigplan
Notices 40.10 (2005), p. 365-383.
[12] Francesc Mateo Tudela et al. “On Combining Static, Dynamic and Interactive
Analysis Security Testing Tools to Improve OWASP Top Ten Security Vulnerability
Detection in Web Applications”. In : Applied Sciences 10.24 (2020), p. 9119.
[13] Balume Mburano et Weisheng Si. “Evaluation of web vulnerability scanners ba-
sed on owasp benchmark”. In : 2018 26th International Conference on Systems
Engineering (ICSEng). IEEE. 2018, p. 1-6.
[14] Paulo Nunes et al. “Benchmarking static analysis tools for web security”. In :
IEEE Transactions on Reliability 67.3 (2018), p. 1159-1175.
[15] Ivan Pashchenko, Stanislav Dashevskyi et Fabio Massacci. “Delta-bench : dif-
ferential benchmark for static analysis security testing tools”. In : 2017 ACM/IEEE
International Symposium on Empirical Software Engineering and Measurement
(ESEM). IEEE. 2017, p. 163-168.
[16] Mandar Prashant Shah. “Comparative Analysis of the Automated Penetration
Testing Tools”. Thèse de doct. Dublin, National College of Ireland, 2020.

Webographie
[17] A01 Ruptures de contrôles d’accès - OWASP Top 10 :2021. url : [Link]
org/Top10/fr/A01_2021-Broken_Access_Control/.
[18] A02 Défaillances cryptographiques - OWASP Top 10 :2021. url : [Link]
org/Top10/fr/A02_2021-Cryptographic_Failures/.
[19] A03 Injection - OWASP Top 10 :2021. url : [Link]
A03_2021-Injection/.
[20] A04 Conception non sécurisée - OWASP Top 10 :2021. url : [Link]
org/Top10/fr/A04_2021-Insecure_Design/.
[21] A05 Mauvaise configuration de sécurité - OWASP Top 10 :2021. url : https :
//[Link]/Top10/fr/A05_2021-Security_Misconfiguration/.
[22] A06 Composants vulnérables et obsolètes - OWASP Top 10 :2021. url : https:
//[Link]/Top10/fr/A06_2021-Vulnerable_and_Outdated_Components/.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 79/81
Projet de Fin d’études Pentest des applications web : . . .

[23] A07 Identification et authentification de mauvaise qualité - OWASP Top 10 :2021.

url : https : / / owasp . org / Top10 / fr / A07 _ 2021 - Identification _ and _
Authentication_Failures/.
[24] A08 Manque d’intégrité des données et du logiciel - OWASP Top 10 :2021. url :
[Link] Software_and_Data_Integrity_
Failures/.
[25] A09 Carence des systèmes de contrôle et de journalisation - OWASP Top 10 :2021.
url : https : / / owasp . org / Top10 / fr / A09 _ 2021 - Security _ Logging _ and _
Monitoring_Failures/.
[26] A10 Falsification de requête côté serveur (SSRF) - OWASP Top 10 :2021. url :
[Link] Server- Side_Request_Forgery_
%5C%28SSRF%5C%29/ (visité le 16/10/2021).
[27] Cehv8 Module 01 Introduction To Ethical [Link] [gen5g560x54o]. url : https:
/ / idoc . pub / documents / cehv8 - module - 01 - introduction - to - ethical -
hackingpdf-gen5g560x54o (visité le 16/10/2021).
[28] Command Injection | OWASP. en. url : [Link]
attacks/Command_Injection.
[29] Cross Site Scripting (XSS) Software Attack | OWASP Foundation. en. url : https:
//[Link]/www-community/attacks/xss/.
[30] CWE - 2021 CWE Top 25 Most Dangerous Software Weaknesses. url : https:
//[Link]/top25/archive/2021/2021_cwe_top25.html.
[31] CWE - CWE-501 : Trust Boundary Violation (4.5). url : [Link]
org/data/definitions/[Link].
[32] Documentation Index | PMD Source Code Analyzer. url : [Link]
io/latest/.
[33] Findbugs - Static Code Analysis of Java. url : [Link]
com/tools/[Link].
[34] GET et POST : comparaison des deux principales requêtes HTTP. fr. url : https:
//[Link]/digitalguide/sites- internet/developpement- web/get-
vs-post/.
[35] Guide for migration from FindBugs 3.0 to SpotBugs 3.1 — spotbugs 3.1.0-RC7
documentation. url : [Link]
latest/[Link].
[36] hjp : doc : RFC 3986 : Uniform Resource Identifier (URI) : Generic Syntax. url :
[Link]
[37] Home | ShiftLeft Docs. en. url : [Link]
[38] HttpOnly - Set-Cookie HTTP response header | OWASP. en. url : https : / /
[Link]/www-community/HttpOnly.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 80/81
Projet de Fin d’études Pentest des applications web : . . .

[39] IC3 Releases 2020 Internet Crime Report. en-us. Press Release. url : https://
[Link]/news/pressrel/press-releases/fbi-releases-the-internet-
crime-complaint-center-2020-internet-crime-report-including-covid-
19-scam-statistics.
[40] Insecure Cookies. url : [Link]
[Link].
[41] Insecure Randomness | OWASP. en. url : [Link]
vulnerabilities/Insecure_Randomness.
[42] LDAP (Lightweight Directory Access Protocol) : définition, traduction. url : https:
//[Link]/web-tech/dictionnaire-du-webmastering/1203397-
ldap-lightweight-directory-access-protocol-definition-traduction/.
[43] OWASP Benchmark. en. url : [Link]
[44] OWASP Find Security Bugs. en. url : [Link]
security-bugs/.
[45] OWASP ZAP – Getting Started. url : [Link]
started/.
[46] OWASP ZAP Tutorial : Comprehensive Review Of OWASP ZAP Tool. url :
[Link]
[47] Page not found | [Link]. url : [Link]
tools/discovery- user- guide/tlsssl- certificatevulnerabilities/weak-
hashing-algorithm/.
[48] Path Traversal | OWASP. en. url : https : / / owasp . org / www - community /
attacks/Path_Traversal.
[49] Security Sessions : Exploring Weak Ciphers - An Explanation and an Example. en.
url : [Link]
[Link].
[50] ShiftLeft NG SAST now available on GitHub Marketplace. en-US. Sept. 2020. url :
https : / / www . helpnetsecurity . com / 2020 / 09 / 10 / shiftleft - ng - sast -
github-marketplace/.
[51] Software Security | Weak Cryptographic Hash. url : [Link]
com/en/detail?id=[Link].weak_cryptographic_hash.
[52] XPATH Injection Software Attack | OWASP Foundation. url : [Link]
org/www-community/attacks/XPATH_Injection.

Master STRI Faculté Polydisciplinaire 5 novembre 2021

Page 81/81