Utilisation Des WAFs Dans La Protection Des Applications Web

People’s Democratic Republic of Algeria
‫الجمهورية الجزائرية الديمقراطية الشعبية‬

Ministry of Higher Education and Scientific Research
‫وزارة التعليم العالي و البحث العلمي‬
École Nationale Supérieure des

télécommunications et des technologies de
l’information et de la communication
Mémoire de fin d’études
Option : Télécommunications et Réseaux IP
Utilisation des WAFs dans la

sécurité des applications web
Réalisé par :
Encadré par :
Mme. Aoumeur Badra Narimène
Mme. Abderrahim Nassiba
Mr. Issoufou Baoua
Wafa
Abdoul-Salami
Soutenu le 08 Juin 2023, devant le jury composé de :
Examinateur : Mr. SEDDIK Ilies

Président : Mme. SOULIMANE Ghizlene
Promotion : IGE 43 - 2022/2023

Dédicace
“ Je dédie ce travail en premier lieu à mon père, qui a consacré toute sa

vie pour que je puisse poursuivre mes études et qui n’a jamais cessé de
croire en moi jusqu’à ces derniers jours.
Je le dédie également à ma maman chérie, qui était toujours
compréhensive à mon égard et qui a toujours respecté mes choix et
encouragé à suivre le chemin que je me suis tracée. Je te dédie ce
travail en soulignant le fait que sans toi, je n’aurais jamais pu arriver
jusque là, ou à faire part de ce travail.
A Adel, Ahmed et Chiraz, mes frères et ma soeur qui m’ont toujours
soutenus, qui sont toujours présent pour moi, et avec qui j’ai vécu mes
meilleurs et pires moments, j’espère que je vous inspirerai d’une
manière ou d’une autre.
A ma grand-mère, qui était toujours présente pour moi, à Houari et
Saida qui était des parrains à notre petite famille, donc merci pour
tous ce que vous avez fait pour nous.
A ma famille paternelle qui m’a toujours soutenu et qui veille toujours
sur nous. Tonton Hbibi, tonton Wahid, tata Khadidja, tata Rachida et
tata Malika, vous avez joué un grand rôle dans mon choix de carrière,
donc il ne sera que normal que vous faites partie des gens auxquels ce
travail est dédié, merci encore.
A mes amies : Dounia, Nihed, Ikram, Senia, Faouzia et Fatima, qui
sont plus que de simples amies, se sont mes soeurs.
Aux membres de Horizon Club, vous m’avez accompagné dans mon
cursus à l’école, certains de vous se sont gradués et ont fait leurs vies,
et d’autres y sont fraîchement intégrés. Grâce au club, j’ai pu vivre une
expérience estudiantine complète et accomplie.
”
- Aoumeur Badra Narimène
I
“ ’
Je dédie ce travail A ma famille, elle qui m’a doté d’une éducation

digne, Son amour a fait de moi ce que je suis aujourd’hui :
Particulièrement à mon père Mr Baoua Issoufou pour le goût à l’effort
qu’il a suscité en moi, de par sa rigueur. A toi ma chère maman Mme
Aissata, quoi que je fasse ou que je dise, je ne saurai point te
remercier comme il se doit. Ton affection me couvre, ta bienveillance
me guide et ta présence à mes côtés a toujours été ma source de force
pour affronter les différents obstacles. ceci est ma profonde gratitude
pour ton éternel amour, que ce rapport soit l’un des meilleurs cadeaux
que je puisse t’offrir. A vous mon frère Lamine et mes sœurs : Laila,
Ni-ima et Sakina qui m’avez toujours soutenu et encouragé durant ces
années d’études.
Sans toute fois oublier ma binôme Badra pour toute sa sympathie, son
enthousiasme et ses précieux conseils.
”
- Issoufou Baoua Abdoul Salami
II
Remerciments
“ Nous souhaitons exprimer nos remerciements les plus sincères à toutes

les personnes qui ont contribué à la réalisation de ce mémoire.
En premier lieu, nous voulons remercier notre encadrante Madame
ABDERRAHIM Wafa, pour avoir accepté de diriger ce travail et pour
ses encouragements et ses conseils judicieux tout le long de sa
réalisation.
Nous remercions aussi HAMMOU Dounia et LAHOUASSA Hamoudi
pour leur aide et leur disponibilité, sans oublier leur soutien tout le
long de la réalisation de ce mémoire.
Nous tenos également à exprimer nos remerciements les plus
chaleureux aux membres de notre jury, Mme. SOULIMANE Ghizlene
et Mr. SEDDIK Ilies, pour l’attention qu’ils ont porté à notre travail.
Pour finir, nous exprimons également notre profonde gratitude à
l’équipe LAB de l’entreprise Lablabee qui nous a donné accès à leur
contenu éducatif.
III
‫ملخص‬
‫في يومنا هذا‪ ،‬أصبحت تطبيقات الويب مستخدمة بشكل متزايد في جميع المجالات‪ .‬حيث يستخدم العديد من‬
‫الأفراد والمجموعات والمنظمات والحكومات هذه التطبيقات لتبادل المعلومات وتسهيل المهام المتعلقة بأنشطتهم‪.‬‬
‫من أجل ضمان أمان التطبيقات ضد الهجمات الإ لكترونية‪ ،‬من الضروري اتخاذ إجراءات حماية مناسبة‪ .‬ويتعلق هذا‬
‫بشكل خاص بالهجمات التي تستهدف طبقة التطبيق‪ ،‬حيث تستغل الثغرات التي يتسبب فيها المطورون أثناء التصميم‪،‬‬
‫بالإ ضافة إلى الثغرات المحتملة في التقنيات المستخدمة في عملية النشر‪.‬‬
‫في إطار مشروع التخرج هذا قمنا باجراء دراسة حول استخدام جدران الحماية للتطبيقات بهدف تعزيز أمان تطبيقات‬
‫الويب‪.‬‬
‫قمنا بتطوير مثال تطبيق بهذا الصدد باستخدام ‪ Modsecurity‬على ‪ Nginx‬بالإ ضافة إلى مجموعة القواعد الأساسية‬
‫التي اختبرناها على ‪ DVWA‬و تطبيق متجر العصير‪ ،‬وهي تطبيقات مفتوحة المصدر مليئة بالثغرات‪.‬‬
‫هدفنا الرئيسي في هذه الدراسة كان تحسين أمان تطبيقات الويب عن طريق حمايتها من مختلف أنواع الهجمات بما‬
‫في ذلك ‪ LFI‬و ‪ XSS‬و‪ SQLI‬وحقن الأوامر ونظام ‪ ،DOS‬والتي تم توفيرها باستخدام أمن ‪ ModSecurity‬و ‪V3.3.4‬‬
‫‪. CRS‬‬
‫كلمات مفتاحية ‪ :‬الأمن السيبيراني لتطبيقات الويب‪ ،‬جدران حماية التطبيقات ‪Nginx, ModSecurity, WAF,‬‬
‫‪(CRS) CoreRuleSet‬‬
‫‪IV‬‬
Résumé
De nos jours, les applications web sont de plus en plus utilisées dans tous les domaines.
De nombreux individus, groupes, organisations et gouvernements recourent à ces appli-
cations pour échanger des informations et faciliter les tâches liées à leurs activités.
Afin de garantir la sécurité des applications contre les cyberattaques, il est essentiel de
prendre des mesures de protection adéquates. Cela concerne particulièrement les attaques
ciblant la couche d’application, qui exploitent les vulnérabilités introduites par les déve-
loppeurs lors de la conception, ainsi que les failles potentielles des technologies utilisées
lors du déploiement.
Dans le cadre de ce projet de fin d’étude, nous avons mené une étude sur l’utilisation des
pare-feux d’applications dans le but d’améliorer la sécurité des applications web.
Nous avons développé un environnement applicatif à cet effet en utilisant ModSecurity
sur Nginx en tant que proxy inverse, ainsi que le jeu de règles principal (core rule set).
De plus, nous avons effectué des tests sur DVWA (Damn Vulnerable Web Application) et
Juice Shop, qui sont des applications open-source présentant de nombreuses vulnérabili-
tés.
Notre objectif principal lors de cette étude était d’améliorer la sécurité des applications
web en les protégeant contre diverses attaques, telles que les LFI (Inclusion de Fichiers
Locaux), les XSS (Cross-Site Scripting), les SQLi (Injection SQL), les injections de com-
mandes et les attaques par déni de service (DoS). Pour atteindre cet objectif, nous avons
mis en œuvre ModSecurity et utilisé le CRS v3.3.4.
Mots clés : Sécurité des applications web, Pare-feux d’applications (WAF), ModSe-
curity, Nginx, Core Rule Set (CRS).
V
Abstract
These days, web applications are more and more used in all fields. Many individuals,
groups, organizations and governments use these applications to exchange information
and support their business activities.
To guarantee the security of applications against cyberattacks, it is essential to take

appropriate protective measures. This specifically applies to attacks targeting the appli-
cation layer, which exploit vulnerabilities introduced by developers during design, as well
as potential flaws in the technologies used for deployment.
As part of this final-year project, we conducted a study on the use of application firewalls
to improve the security of web applications.
We developed a practice environment for this purpose, using ModSecurity on Nginx as
a reverse proxy, as well as the core rule set. In addition, we carried out tests on DVWA
(Damn Vulnerable Web Application) and Juice Shop, which are open-source applications
with numerous vulnerabilities.
Our main objective in this study was to improve the security of web applications by pro-
tecting them against various attacks, such as LFI (Local File Inclusion), XSS (Cross-Site
Scripting), SQLi (SQL Injection), command injection and DoS (Denial of Service) attacks.
To achieve this goal, we implemented ModSecurity and used CRS v3.3.4.
Keywords : Web applications security, Web Application Firewalls (WAF), ModSecurity,

Nginx, Core rule set (CRS).
VI
Table des matières
Dédicace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Remerciments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ‫ملخص‬
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI
Introduction Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Généralités & concepts clés . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Attaques malveillantes ( Cyber-attaques) . . . . . . . . . . . . . . . . . . 5
1.3 Open Worldwide Security Project (OWASP) . . . . . . . . . . . . . . . . 8
1.4 Sécurisation des applications web . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Les WAFs et leur fonctionnement . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Firewalls (Pare-feux) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Les WAFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Modèles de sécurité des WAFs . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Méthodes de déploiement de WAFs . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Fonctionnalités principales des WAFs . . . . . . . . . . . . . . . . . . . . 19
2.7 Les WAFs open-source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Implémentation de ModSecurity sur Nginx . . . . . . . . . . . . . . . . . 25

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Mise en œuvre de l’environnement de test . . . . . . . . . . . . . . . . . . 32
3.4 Analyses des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Conclusion et perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Annexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
VII
Table des figures
1.1 Le changement de catégories entre 2017 et 2021 . . . . . . . . . . . . . . . 10
2.1 Fonctionnement d’un routeur de filtrage[6] . . . . . . . . . . . . . . . . . . 15

2.2 Illustration du fonctionnement des pare-feux à inspection dynamique . . . 15
2.3 Illustration explicative des pare-feux au niveau d’application . . . . . . . . 16
2.4 Illustration des NGFW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 illustration des par-feux web[27] . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Nginx comme proxy inverse . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Environnement des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Topologie de l’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Avant ModSecurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Après ModSecurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Attaque LFI avant et après l’utilisation de ModSecurity . . . . . . . . . . . 34
3.7 Contourner ModSecurity avec une attaque LFI . . . . . . . . . . . . . . . . 34
3.8 Contourner ModSecurity avec une SQLi . . . . . . . . . . . . . . . . . . . 36
3.9 Attaques bloquées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.10 Résultats des tests SQLi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.11 Contourner ModSecurity avec une Injection de commande . . . . . . . . . 36
3.12 Partie des résultats du scan . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.13 Accès au serveur avec weevely . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Résultats de l’attaque DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.15 DVWA/setup.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.16 DVWA/login.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.17 DVWA home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.18 Bienvenu sur Juice Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
VIII
Liste des tableaux
2.1 Tableau comparatif entre les WAF open source populaires . . . . . . . . . 24
3.1 Les Opérateurs des règles de ModSecurity . . . . . . . . . . . . . . . . . . 27

3.2 Les Opérateurs des règles de ModSecurity . . . . . . . . . . . . . . . . . . 27
3.3 Résultats des attaques testées. . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Paramètres de slowhttptest . . . . . . . . . . . . . . . . . . . . . . . . . . 38
IX
Listings
1.1 Exemple d’un code PHP vulnérable aux inclusions de fichiers. . . . . . . . 5

1.2 Exemple d’un code PHP vulnérable aux attaques XSS réfléchis . . . . . . . 6
1.3 Exemple d’un code PHP vulnérable aux attaques SQLi . . . . . . . . . . . 7
3.1 Message d’alerte sur error.log . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Fichier YAML pour DVWA . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Juice Shop container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4 nginx.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5 pfetest.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
X
Liste des sigles et acronymes
ACL Access list.
BDD Base de données.
CI/CD Continuous Integration / Continuous Delivery.
CRS Core Rule Set.
CVE Commun Vulnerability and Exposure.
CVSS Commun Vulnerability Scoring System.
CWE Commun Weakness Enumerations.
DDoS Distributed Denial of Service.
DoS Denial of Service.
DPI Deep Packet Inspection.
DVWA Damn Vulnérable Web Application.
HTTP HyperText Transfer Protocol.
IDS Intrusion Detection System.
IETF Internet Engineering Task Force.
IIS Internet Information Service.
IPS Intrusion Prevention System.
LAMP Linux Apache MySQL PHP.
LFI Local File Inclusion.
MSRL ModSecurity Rules Language.
MSSP Managed Security Service Providers.
NAT Network Address Translation.
NAXSI Nginx anti XSS & SQLi.
XI
Listings
NGFW Next Generation Firewalls.
OS Operating System.
OSI Open System Interconnection.
OWASP Open Web Application Security Project.
PL Paranoia Level.
SCG Secure Coding Guidelines.
SI Système d’information.
SIEM Security Information and Event Management.
SQLi SQL injections.
URL Uniform Ressource Locator.
VM Virtual Machine.
VPN Virtual Private Network.
WAF Web Application Firewall.
WWW World Wide Web.
XML Extensible Markup Language.
XSS Cross Site Scripting.
XXE XML extended entity injection.
XII
Introduction Générale
1
Contexte
Les applications web, aussi connues sous le nom de “web apps”, sont des programmes
informatiques qui exécutent des tâches différentes selon le besoin, et auxquels les utilisa-
teurs accèdent par l’intermédiaire d’un navigateur web.
Quand nous parlons du développement de ces applications, nous pouvons distinguer 2
types de programmes (ou de scripts), qui dépendent l’un de l’autre, il s’agit de scripts
frontend (coté utilisateur) et de scripts backend (côté serveur) qui fonctionnent en entre-
lacement afin de créer une application interactive, rapide, et dont l’utilisation est assez
simple et claire.
Ces applications sont hébergées sur des serveurs web qui sont utilisés pour stocker les
données (scripts, images, vidéos, articles …) pour ensuite les partager avec les clients sou-
haitant obtenir ces informations. Ils fonctionnent donc en permanence pour répondre aux
demandes des internautes.
La protection des serveurs est essentielle compte tenu de leur rôle crucial. Il est impératif
de les sécuriser contre les cybercriminels et leurs attaques malveillantes, dont l’objectif
principal est de les compromettre afin de perturber leur fonctionnement et la disponibilité
des données, ce qui cause des problèmes importants pour les clients et les propriétaires de
ces applications web, qui sont généralement des entreprises. Parmi ces attaques, on peut
citer le Cross-Site Scripting (XSS) et les Injections SQL (SQLi) qui se produisent lorsque
des parties de code malveillantes sont injectées sur des sites fiables afin d’altérer leur
comportement, soit en exposant des données confidentielles ou en affichant des messages
ou des fenêtres qui peuvent nuire à l’utilisateur.
Plusieurs composants réseau ont été développés et utilisés dans la protection des appli-
cations web, tels que les systèmes de prévention d’intrusion (IPS - Intrusion Prevention
System), les systèmes de détection d’intrusions (IDS - Intrusion Detection Systems), qui
sont surtout utilisés pour la détection des potentielles attaques et d’en informer les ad-
ministrateurs, et les pare-feux (Firewalls) qui ne cessent d’évoluer afin de s’adapter à
l’évolution des cyber-attaques et de lutter efficacement contre celles-ci, tout en évitant
de causer des problèmes tels que le blocage de trafic important en raison d’une mauvaise
configuration, par exemple.
Cette évolution a donné naissance aux pare-feux des applications web ( WAFs - Web
Application Firewalls ) qui interagissent directement sur les données des paquets réseau
au niveau de la septième couche (couche application) du modèle OSI.
Problématique
Avec l’utilisation généralisée des sites web pour offrir des services et interagir avec les
clients, les entreprises optent de plus en plus pour l’hébergement cloud pour des raisons
d’efficacité et d’économie. Cependant, cette pratique soulève des préoccupations quant à
la sécurité des serveurs distants auxquels les entreprises n’ont pas accès physiquement.
En effet, les cyber-attaques sont de plus en plus fréquentes et sophistiquées, ce qui souligne
2
l’importance de mettre en place une protection adéquate pour protéger les informations
personnelles et professionnelles des entreprises.
La plupart des fournisseurs de services cloud proposent des solutions de sécurité basées
sur des pare-feux. Cependant, chaque fournisseur propose des solutions spécialisées pour
son architecture et ses services, ce qui peut entraîner des problèmes d’adaptabilité et de
maintenance pour les services hébergés chez d’autres fournisseurs de cloud.
D’où la nécessité d’utiliser des solutions largement accessibles, personnalisables et fiables,
qui peuvent répondre aux besoins de sécurité nécessaires aux applications web.
Contribution
Notre étude propose et démontre la mise en œuvre d’un pare-feu d’application pour
améliorer la sécurité des applications web en utilisant ModSecurity et Nginx comme Proxy
Inverse.
Pour atteindre notre objectif, nous commencerons par configurer des règles ou politiques
de sécurités génériques contre les cyber-attaques. Ensuite, nous testerons ces règles sur des
applications web délibérément vulnérables, telles que DVWA et Juice Shop. En parallèle,
nous mettrons en œuvre un système de gestion des événements et des informations de
sécurité (SIEM) afin d’assurer une gestion efficace des résultats obtenus.
Organisation du travail
Ce travail a été divisé en trois principaux chapitres décrits comme suit :
• Chapitre 1 :: Généralités & concepts clés

Dans ce chapitre nous allons expliquer brièvement les concepts nécessaires à la
compréhension de notre étude.
• Chapitre 2 :: Les WAFs & leurs fonctionnements

Ce chapitre va contenir la partie théorique de notre étude, à savoir la définition des
WAFs, leurs fonctionnalités, et leurs méthodes de déploiement.
Nous invoquerons aussi les pare-feux Open-source que nous avons étudiés.
• Chapitre 3 :: Implémentation de ModSecurity sur NGINX

Ce chapitre va décrire les outils utilisés lors de la mise en œuvre de notre étude,
notamment le choix du WAF open-source, la syntaxe de ses règles et leur application
pratique. Nous examinerons également les outils de pentest utilisés pour tester les
attaques contre le WAF. Enfin, nous discuterons de l’architecture de déploiement
et des résultats obtenus.
• Conclusion & Perspective
3
Chapitre 1
Généralités & concepts clés
4
Chapitre 1. Généralités & concepts clés
1.1 Introduction
Dans ce chapitre, nous allons traiter quelques technologies et concepts généraux né-
cessaires à la compréhension du travail qui va suivre, y compris les cyber-attaques les plus
courantes, le projet OWASP et les mesures de sécurisation des applications webs.
1.2 Attaques malveillantes ( Cyber-attaques)

Actuellement, les cyber-attaques détectées peuvent être classifiées en diverses caté-
gories, selon leurs degrés d’efficacités et de dangerosité. Cette section se concentre sur
les cyber-attaques les plus rependues[13] et qui serons prises en considération dans notre
étude.
Inclusion de fichiers :
L’inclusion de fichiers est une forme d’exploitation de sécurité dans laquelle un atta-
quant profite d’une vulnérabilité présente dans une application web pour inclure un fichier
du serveur web dans une page web.
L’attaquant peut utiliser cette technique pour exécuter du code ou pour accéder à des
informations sensibles sur le serveur[8].
Il existe deux types d’attaques d’inclusion de fichiers :
• Inclusion de fichiers locals (LFI - Local File Inclusion) : Un attaquant

trompe l’application web en exposant ou en exécutant des fichiers sur le serveur
web ce qui peut conduire à la divulgation d’informations, à l’exécution de code à
distance, ou même aux attaques de type XSS.
Généralement, une attaque LFI se produit lorsqu’une application utilise le chemin
d’un fichier comme entrée, si l’application traite cette entrée comme fiable, un fichier
local peut être utilisé dans l’instruction ”include”.
• Inclusion de fichiers à distance (RFI - Remote File Inclusion) : Comme

LFI, cette attaque repose sur l’exploitation des procédures d’inclusion vulnérables
mises en œuvre dans une application. Cette vulnérabilité survient, par exemple,
lorsqu’une page reçoit, en entrée, le chemin du fichier qui doit être inclus et que
cette entrée n’est pas correctement analysée, ce qui permet d’injecter une URL
externe, et télécharger un code malveillant à partir d’un serveur distant.
1 <?php
2
3 # Récuperer un fichier avec GET

4 # par exemple LFI : http :// example .com /? file= fichier .php
5 LFR : http :// example .com /? file= hackedsite .com/mal.php
6
7 $fichier = $_GET ['fichier '];

8 # fichier inclut sans validation de l' entrée
9 include ('dir /'. $fichier );
5
10
11 ?>
12
Listing 1.1: Exemple d’un code PHP vulnérable aux inclusions de fichiers.
Cross-Site Scripting (XSS) :

Le principe d’une attaque XSS consiste à insérer du code malveillant à un site web
légitime, qui s’exécute lorsqu’un utilisateur accède au site. Ce code peut être inséré en
utilisant différentes méthodes, mais la plus courante est l’insertion à la fin d’une URL, ou la
publication sur une page qui affiche un contenu généré par l’utilisateur (des commentaires
par exemple).
Il est évident que les attaques XSS sont efficaces sur les sites qui ont des champs de
saisie non validés. Par exemple, l’attaquant poste un commentaire qui contient du code
malveillant enveloppé dans des balises script : “<script> *code*</script”>” qui
incitent le navigateur web à interpréter tout ce qui est dedans en un code JavaScript.
Une fois ce commentaire posté sur la page, le code contenu dedans s’éxécute à chaque fois
qu’un utilisateur accéde au site, ce qui fera de lui une victime de cette attaque. Il existe
deux types diffrents d’attaques XSS :
• XSS réfléchie : Un code malveillant est injecté à la fin de l’URL d’un site web,
qui est généralement légitime et de confiance. Lorsque la victime charge ce lien dans
son navigateur web, celui-ci exécute le code injecté dans l’URL. L’attaquant utilise
souvent une forme d’ingénierie sociale pour inciter la victime à cliquer sur le lien.
• XSS persistante (ou stockée) : Cette attaque cible les sites qui permettent aux
utilisateurs de publier du contenu visible par d’autres utilisateurs, comme un forum
de discussions ou un site de médias sociaux. Si le site ne valide pas les entrées géné-
rées par l’utilisateur, un hacker peut injecter du code exécutable par les navigateurs
des autres utilisateurs lors du chargement de la page.
Par exemple, se rendre sur un site de médias sociaux, y publier un code malveillant
qui sera stocké dans la base de données et exécuté lorsqu’une victime interagit avec
ce qui est publié.
1 <?php
2
3 #Un champs pour inserrer un nom avce la méthode GET

4 #XSS réflechi : <script > alert (" HACKED ") </script >
5
6 if( array_key_exists (" name", $_GET ) && $_GET [" name "] != NULL){
7 echo '<pre > Coucou '. $_GET [" name "]. ' </pre >';
8 }
9
10 ?>
11
Listing 1.2: Exemple d’un code PHP vulnérable aux attaques XSS réfléchis
6
Les injections SQL (SQLi) :

L’injection SQL est une technique d’injection de code utilisée pour modifier ou ré-
cupérer des données à travers des bases de données SQL. En insérant des requêtes SQL
spécialisées dans un champ de saisie ou à la fin d’une URL, un hacker exécute des com-
mandes qui lui permettent d’accéder à une BDD (base de données) et de récupérer ainsi
des données sensibles ou de les manipuler à d’autres fins différentes, par exemple :
• Usurper l’identité d’un utilisateur plus privilégie.
• Se transformer, ou transformer d’autres personnes, en administrateurs de la BDD.
• Altérer les données existantes.
• Récupérer et/ou détruire toutes les données du serveur.
1 <?php
2
3 #Un champs pour récuperer l'id de l' utilisateur

4 #SQLi pour afficher la version de la BD
5 $query = " SELECT first_name , last_name FROM users WHERE user_id =
'". $_GET ['id ']." '";
6
7 ?>
8
Listing 1.3: Exemple d’un code PHP vulnérable aux attaques SQLi
Attaques par déni de service (DoS) :

Une attaque par déni de service (DoS) provoque l’indisponibilité d’un système en
interrompant son fonctionnement normal et en inondant la machine ciblée de trafic jusqu’à
ce que celle-ci ne puisse plus traiter les informations reçues, ce qui entraîne un déni de
service pour les utilisateurs légitimes.
Il existe deux méthodes générales d’attaques DoS :
• La première méthode est l’attaque par inondation, qui consiste à envoyer une impor-
tante quantité de données inutiles au système l’empêchant de les gérer correctement.
Les plus courantes sont les suivantes :
– Attaques par débordement de mémoire tampon : Il s’agit de l’attaque la

plus courante, dans laquelle le système reçoit un volume de donner important
que la mémoire tampon ne peut pas contenir.
– Inondation de ping : L’acteur malveillant exploite les dispositifs de réseau
mal configurés en envoyant des paquets usurpés par ping à chaque ordinateur
ou dispositif existant sur le réseau cible au lieu d’une machine spécifique. Cette
attaque est également connue sous le nom de smurf attack ou ping of death.
7
– Flood SYN : Dans cette attaque, l’acteur malveillant envoie une demande de
connexion à un serveur, mais n’achève jamais le handshake. Il continue jusqu’à
ce que tous les ports ouverts soient saturés de demandes et qu’aucun ne soit
disponible pour que les utilisateurs légitimes puissent se connecter.
• La deuxième méthode d’attaque par déni de service exploite les vulnérabilités du

système cible pour le rendre indisponible. Dans ces attaques, l’acteur malveillant
envoie trop d’informations pour provoquer des pannes ou une grave déstabilisation
du système cible.
La différence entre le déni de service distribué (DDoS) et le déni de service (DoS) est le
nombre de connexions utilisées dans l’attaque, en effet, l’attaque DDoS utilise de nom-
breuses sources de trafic d’attaque, par exemple un réseau de zombies, tandis que le déni
de service utilise une seule connexion à travers un programme dédié.
1.3 Open Worldwide Security Project (OWASP)

l’OWASP est une fondation à but non lucratif qui vise à améliorer la sécurité des
logiciels. A travers sa communauté active, ses projets de logiciels libres et ses conférences
éducatives, la fondation OWASP est une ressources essentielles qui permet aux dévelop-
peurs et aux technologues de contribuer à la sécurisation du web[15].
L’un des projets les plus importants de l’OWASP est le Top 10 Web Application Security
Risks qui est un document mondialement reconnu par les développeurs comme la première
étape vers un codage plus sécurisé. La liste des Top 10, dont la dernière mise à jour est
expliquée par la figure 1.1, est la suivante[23] :
1. A01: Contrôle d’accès non respecté : Les 34 énumérations de faiblesses com-

munes (Common Weakness Enumerations, CWE) associées au contrôle d’accès non
respecté ont eu plus d’occurrences dans les applications testées que toute autre
catégorie.
2. A02: Défaillances cryptographiques : (Cryptographic Failures) précédemment

connu sous le nom de Sensitive Data Exposure (exposition de données sensibles), qui
était un symptôme général plutôt qu’une cause fondamentale. L’accent est désormais
mis sur les défaillances liées à la cryptographie, qui conduisent souvent à l’exposition
de données sensibles ou à la défaillance d’un système.
3. A03: L’Injection : Plusieurs formes d’injections ont été détectées dans 94 % des
applications testées. En effet, les 33 CWE répertoriés dans cette catégorie sont les
deuxièmes plus fréquents dans les applications.
4. A04: Conception non sécurisée : c’est une nouvelle catégorie de risque apparue
en 2021, qui met l’accent sur les risques liés aux défauts de conception. Si une
entreprise souhaite vraiment ”passer à gauche”, il faut qu’ils utilisent d’avantage la
modélisation des menaces, les modèles et principes de conception sécurisés et les
architectures de référence.
8
5. A05: Mauvaise configuration de la sécurité : parmi les applications testées,

90 % présentaient une forme ou une autre de mauvaise configuration. Étant donné
que les logiciels hautement configurables sont de plus en plus nombreux, il n’est
pas surprenant de voir cette catégorie progresser. L’ancienne catégorie des entités
externes XML (XXE) fait désormais partie de cette catégorie
6. A06: Les composants vulnérables/obsolètes : qui était précédement intitulée

l’utilisation des composants avec des vulnérabilitées connues, est un problème connu
que nous avons du mal à tester et à en évaluer les risques. C’est la seule catégorie
à ne pas avoir de Common Vulnerability and Exposures (CVE) mappé aux CWE
inclus, donc un exploit par défaut et des pondérations d’impact de 5,0 sont pris en
compte dans leurs scores.
7. A07: Echecs d’identification et d’authentification : qui était précédemment

echec d’authentification inclut maintenant des CWEs qui sont plus liés à des échecs
d’identification. Cette catégorie fait toujours partie intégrante du Top 10, mais la
disponibilité accrue de frameworks semble aider à résoudre ce problème.
8. A08 : Défauts d’intégrité des logiciels et des données : c’est une nouvelle
catégorie pour 2021, qui se concentre sur les hypothèses liées aux mises à jour lo-
gicielles, aux données critiques et aux pipelines CI/CD sans en vérifier l’intégrité.
L’un des impacts pondérés les plus élevés des données CVE/CVSS (Common Vul-
nerability and Exposures/Common Vulnerability Scoring System) correspond aux
10 CWE de cette catégorie. La désérialisation non sécurisée de 2017 fait désormais
partie de cette catégorie plus large.
9. A09: Défauts de journalisation et de surveillance de la sécurité : était aupa-

ravant Journalisation et surveillance insuffisantes. Cette catégorie qui était élargie
pour inclure plus de types de défaillances, est difficile à tester et n’est pas bien
représentée dans les données CVE/CVSS. Cependant, les défaillances de cette ca-
tégorie peuvent avoir un impact direct sur la visibilité, l’alerte en cas d’incident et
la criminalistique.
10. A10: Falsification des requêtes du coté serveur : Cette catégorie présente le
scénario dans lequel les données montrent un taux d’incidence relativement faible
avec une couverture de test supérieure à la moyenne, ainsi que des notes supérieures
à la moyenne pour le potentiel d’exploitation et d’impact.
9
Fig. 1.1 : Le changement de catégories entre 2017 et 2021
1.4 Sécurisation des applications web

Les mesures de sécurisation des applications web ne peuvent pas être considérées
simplement en intégrant des systèmes de sécurité.
En effet, ces systèmes ne peuvent que combler les lacunes dus aux mauvaises pratiques
lors de la conception de ces applications.
Parmi les bonnes pratiques conçues pour la sécurisation des web apps, Nous pouvons citer
les trois suivantes :
Sécurisation des systèmes :

Le processus de Hardening, qui consiste à minimiser la surface de vulnérabilités, à
travers les pratiques suivantes[14] :
• Protection des comptes des utilisateurs :
– Utiliser des modules d’authentification, par exemple, Linux-PAM (Pluggable

Authentication Modules) qui est une suite de bibliothèques partagées utilisées
pour authentifier dynamiquement un utilisateur auprès des applications d’un
système Linux.
– Forcer les utilisateurs à utiliser des mots de passes robustes.
– Utiliser des politiques de vieillissement qui permettent aux systèmes de forcer
une durée de vie aux mot de passe.
– Supprimer les comptes d’utilisateurs inutiles ou qui n’ont plus de droits d’accès
au système.
• Protection des fichiers :
– Définir l’ensemble des privilèges qu’un utilisateur peut avoir sur un fichier,
adéquats (Exemple : un Umask, un Setuid et une Setguid).
– Utiliser les Sticky bits pour interdire à un utilisateur autre que le root ou le
créateur du fichier de supprimer ce dernier.
10
– Utiliser les ACL (access lists) qui contiennent les listes des utilisateurs qui ont
droit d’accéder à un certain répertoire ou fichier.
• Protection des serveurs web et des BBD :
– Utiliser les ServerTokens et la désactivation des signatures du serveurs afin
d’empêcher la divulgation d’informations sur le serveur .
– Interdire le Directory Browsing en désactivant le module d’auto-Index du ser-
veur afin qu’il affiche du contenue seulement si la recherche correspond à un
fichier spécifique.
– Limiter le temps de connexion ssh au serveur.
– Employer des ports différents que ceux utilisés par défaut pour les services
exposés au réseaux externes.
Sécurisation du code :
Il existe plusieurs directives de codage sécurisé (SCG - Secure Coding Guidelines)[7]
qui diffèrent selon le langage et le service proposé.
Parmi les meilleures pratiques de sécurisation du code, on peut citer les suivantes[24] :
• Validation des entrées :

Il est important de veiller à ce que les applications valident de manière appropriée
et restrictive les entrées provenant du clavier, des fichiers et de la base de données,
en n’autorisant que les types d’entrées corrects.
• Traitement des erreurs :
Veiller à ce que les applications gèrent correctement les erreurs est essentiel afin
d’éviter la divulgation d’informations détaillées sur le système, les refus de service,
les altérations des mécanismes de sécurité ou les pannes du système.
• Gestion du code :
Mettre en œuvre et maintenir un processus de gestion des changements, y compris
le contrôle des versions, pour les modifications apportées aux applications logicielles
existantes.
Sécurisation du réseau :
Une application web ne peut pas être complètement sécurisée si le réseau ne l’est pas.
C’est pourquoi il est important d’implémenter des pratiques de sécurisation lors de la
mise en place de l’infrastructure réseau, tout en utilisant des mécanismes qui permettent
d’ajouter une couche de sécurité intégrée au niveau réseau du modèle OSI[17].
Parmi ces mécanismes, nous pouvons citer :
• Les réseaux virtuels privés :

Les VPNs fournissent un canal de communication sécurisé vers l’internet en cryptant
les données et en les encapsulants dans un tunnel sécurisé qui permet de protéger
les données contre l’interception malveillante.
11
• Les Pare-feux :
qui sont des dispositifs qui contrôlent l’accès à un réseau et peuvent être configurés
pour bloquer ou autoriser le trafic en fonction de règles prédéfinies.
• Les Systèmes de détection d’intrusion :

Les IDS sont utilisés pour détecter et alerter les administrateurs de réseau en cas
de détection d’activité suspecte sur un réseau.
• Traduction des adresses réseau :

C’est le fait de traduire les adresses IPs entre les réseaux privés et publics ce qui per-
met de protéger les réseaux privés d’une exposition directe à l’internet et d’assurer
un certain niveau d’anonymat.
1.5 Conclusion
Après avoir listé les attaques les plus courantes qui ciblent les web apps, telles que les
LFI, RFI, SQLi, XSS et DoS, ainsi que le top10 des cyber-risques et les meilleures pratiques
pour sécuriser les applications web, nous allons présenter dans le chapitre suivant l’un des
moyens les plus répondus pour la sécurisation des web apps : les pare-feux d’application
(WAF).
12
Chapitre 2
Les WAFs et leur fonctionnement
13
Chapitre 2. Les WAFs et leur fonctionnement
2.1 Introduction
Ce chapitre ce concentre sur l’étude des mécanismes des pare-feux, en mettant par-
ticulièrement l’accent sur les pare-feux d’applications qui constituent l’élément principal
de notre contribution.
Nous allons donc examiner en détail leurs fonctionnements, leurs modèles de sécurité,
ainsi que leurs méthodes de déploiement.
2.2 Firewalls (Pare-feux)

Par définition, un pare-feu est un composant ou un ensemble de composants qui
restreint l’accès entre un réseau protégé et internet, ou entre différents ensembles de
réseaux[6]. Son rôle est de surveiller le trafic réseau entrant et sortant et décider d’auto-
riser ou de bloquer ce trafic selon un ensemble de règles de sécurité.
Donc, La fonction principale d’un pare-feu est de réguler le flux de données entre deux
réseaux informatiques.
En général, ces deux réseaux sont l’internet et le réseau local de l’entreprise qui ont des
niveaux de confiance différents : l’internet a un faible niveau de confiance, tandis que les
réseaux d’entreprise/domestiques ont un plus haut degré de confiance.
Les organisations doivent souvent utiliser des pare-feux pour répondre aux exigences de
sécurité des directives ; certaines directives, par exemple la norme de sécurité des données
de l’industrie des cartes de paiement (PCI), exigent spécifiquement l’utilisation de pare-
feux[12].
Nous citons, dans ce qui suit, les différentes générations de pare-feux :
Pare-feux de première génération - Filtrage de paquets (packet

filters) :
Le premier document de recherche sur la technologie des pare-feux a été publié en
1988, lorsque les ingénieurs de DEC (Digital Equipment Corporation) ont mis au point des
filtres (screening devices), de paquets de données, qui sont considérés comme la première
génération de pare-feux. Le filtrage de paquets est l’action d’un appareil pour contrôler
sélectivement le flux de données en provenance et à destination d’un réseau, la figure
2.1 illustre ce mécanisme. Les Filtres de paquets autorisent ou bloquent les paquets,
généralement en les acheminant d’un réseau à un autre (le plus souvent d’Internet vers un
réseau interne, et vice versa) par le biais d’un ensemble de règles qui spécifient quels types
de paquets (par exemple, ceux à destination ou en provenance d’une adresse IP ou d’un
port particulier) doivent être autorisés et quels types doivent être bloqués. Le filtrage de
paquets peut se produire au niveau d’un routeur, d’un pont ou un hôte individuel.
14
Fig. 2.1 : Fonctionnement d’un routeur de filtrage[6]
Pare-feux de seconde génération - Filtres à inspection dynamique

(stateful firewalls) :
Cette génération rajoute quelques options supplémentaires aux pare-feux de la pre-
mière génération, comme le montre la figure 2.5. Cela concerne le fait qu’il examine l’état
de chaque paquet, c’est-à-dire la connexion d’où il provient. C’est pourquoi on les appelle
filtres d’état (stateful firewalls). Ces filtres gardent toujours une trace du nombre et du
type de connexions entre les deux réseaux et peuvent également déterminer si un paquet
est le début d’une nouvelle connexion, ou la fin d’une connexion existante. Il est ainsi plus
facile de prévenir quelques types d’attaques, telles que l’attaque SYN flood par exemple.
Fig. 2.2 : Illustration du fonctionnement des pare-feux à inspection dynamique
Pare-feux de troisième génération - Passerelle au niveau d’appli-

cation (application-level gateways) :
Ces pare-feux sont également connus sous le nom de pare-feux proxy. Ils fonctionnent
au niveau de la couche application du modèle OSI, et peuvent distinguer quel programme
ou protocol essaie d’établir une nouvelle connection. Ce qui leur permet de filtrer le trafic
15
en fonction de l’application spécifique utilisée, comme l’illustre la figure 2.3. Ainsi, le pare-
feu d’applications web (Web Application Firewall - WAF) est issu de cette génération.
Fig. 2.3 : Illustration explicative des pare-feux au niveau d’application
Pare-feux de quatrième génération - Next Generation Firewalls

(NGFW) :
Un NGFW typique combine l’inspection des paquets avec l’inspection des états (sta-
teful inspection) et comprend également une certaine variété d’inspection approfondie des
paquets (DPI), ainsi que d’autres systèmes de sécurité du réseau, voir figure 2.4, tels qu’un
IDS/IPS, un filtrage des logiciels malveillants et un antivirus.
Contrairement à l’inspection des paquets dans les pare-feux traditionnels, qui se limite
exclusivement à l’en-tête du protocole du paquet, l’inspection approfondie des paquets se
concentre sur les données réelles transportées par le paquet. En plus, un pare-feu DPI suit
la progression d’une session de navigation sur le web et peut remarquer si la charge utile
d’un paquet, lorsqu’elle est assemblée avec d’autres paquets dans une réponse du serveur
HTTP, constitue une réponse légitime au format HTML.
16
Fig. 2.4 : Illustration des NGFW
2.3 Les WAFs

Le WAF est un dispositif de sécurité utilisé pour prévenir différentes menaces et at-
taques visant les applications web. Il a la capacité de filtrer les paquets, de bloquer les re-
quêtes HTTP dangereuses et d’effectuer des enregistrements sur les faits (journalisation)[20].
En effet, un WAF protège l’application web contre les attaques non autorisées et surveille
le trafic HTTP entre celle-ci et l’Internet, comme le montre la figure 2.5, afin d’interdire
les attaques malveillantes qui ciblent la couche application tels que XSS, LFI, RFI et
SQLi, etc.
Caractéristiques des WAFs :

• Un WAF est une défense de la couche application du modèle OSI et il n’est pas
conçu pour se défendre contre tous les types de cyber-attaques.
• Un WAF peut jouer aussi le rôle d’un proxy inverse, en protégeant le serveur de
l’exposition directe aux clients.
• Un WAF fonctionne grâce à un ensemble de règles souvent appelées politiques. Ces

politiques ont pour objectif de protéger les applications contre les vulnérabilités en
filtrant le trafic malveillant.
• Le plus important pour le WAF est la rapidité et la facilité avec lesquelles la modi-
fication de la politique peut être mise en œuvre, ce qui permet d’avoir une certaine
17
agilité envers les changements(nouvelles méthodes ou différents fournisseurs).
Fig. 2.5 : illustration des par-feux web[27]
2.4 Modèles de sécurité des WAFs

Les WAFs peuvent utiliser un modèle de sécurité positif ou négatif, ou une combinaison
des deux[28] :
• Modèle positif :
Un modèle de sécurité positif du WAF implique la définition d’une liste blanche qui
filtre le trafic en fonction d’une liste d’éléments et d’actions autorisés - tout ce qui
ne figure pas sur la liste est bloqué. L’avantage de ce modèle est qu’il peut bloquer
des attaques nouvelles ou inconnues que le développeur n’a pas anticipées.
• Modèle négatif :
Un modèle négatif implique la définition d’une liste noire (ou liste de refus) qui
ne bloque que des éléments spécifiques - tout ce qui ne figure pas sur la liste est
autorisé. Ce modèle est plus facile à mettre en œuvre, mais il ne garantit pas que
toutes les menaces sont prises en compte. Il nécessite également la tenue d’une liste
potentiellement longue de signatures malveillantes. Son niveau de sécurité dépend
du nombre des restrictions mises en œuvre.
• Modèle mixte/hybride (modèle inclusif) :

Un modèle de sécurité hybride mélange à la fois l’inscription sur la liste d’autori-
sation et l’inscription sur la liste de blocage. En fonction de toutes sortes de confi-
gurations, ce modèle peut être le meilleur choix pour les applications web sur les
réseaux internes ou publics.
18
2.5 Méthodes de déploiement de WAFs

Il existe trois façons principales de mettre en œuvre un pare-feu en général, et qui
peuvent être parfaitement pratiquées avec le WAF[28] :
• Pare-feu matériel :
Un pare-feu matériel est un appareil qui sert de passerelle sécurisée entre les appa-
reils situés à l’intérieur du périmètre d’un réseau et ceux situés à l’extérieur. Étant
donné qu’il s’agit d’appareils autonomes, les pare-feux matériels ne consomment pas
la puissance de traitement ni les autres ressources des appareils hôtes.
Parfois appelés pare-feu de réseau, ces dispositifs sont idéaux pour les moyennes et
grandes entreprises qui souhaitent protéger un grand nombre d’appareils. La confi-
guration et la gestion des pare-feux matériels requièrent davantage de connaissances
que celles des pare-feux hôtes.
• Pare-feu logiciel :
Un pare-feu logiciel, ou pare-feu hôte, s’exécute sur un serveur ou un autre appareil
nécessitant une protection. Les pare-feux logiciels consomment donc une partie des
ressources de l’unité centrale et de la mémoire vive de l’appareil hôte.
Ils offrent aux appareils individuels une protection importante contre les virus et
autres contenus malveillants. Ils peuvent discerner les différents programmes en
cours d’exécution sur l’hôte, tout en filtrant le trafic entrant et sortant. Ils offrent
ainsi un niveau de contrôle très fin, permettant d’autoriser les communications vers/-
depuis un programme et de les empêcher vers/depuis un autre.
• Pare-feu hébergé sur le cloud :

Les fournisseurs de services de sécurité gérés (MSSP) proposent des pare-feux hé-
bergés dans le nuage. Ce service peut être configuré pour suivre à la fois l’activité
du réseau interne et les environnements de tiers à la demande.
Également connus sous le nom de pare-feux en tant que service (firewalls as a ser-
vice), les pare-feux en nuage peuvent être entièrement gérés par un MSSP, selon le
besoin du client, ce qui en fait une bonne option pour les grandes entreprises ou
les entreprises fortement distribuées qui rencontrent des contraintes en matière de
ressources de sécurité.
2.6 Fonctionnalités principales des WAFs

Voici quelques fonctionnalités et capacités courantes des WAF :
• Filtrage basé sur des règles :

Les WAF utilisent un ensemble de règles prédéfinies pour bloquer ou autoriser le
trafic en fonction de l’adresse IP, l’agent utilisateur et la méthode HTTP.
• Protection de la couche application :

Les WAF peuvent identifier et bloquer les attaques qui ciblent des vulnérabilités
spécifiques dans les applications web, telles que SQLi, XSS et LFI.
19
• Surveillance en temps réel :

Les WAF surveillent en continu le trafic web et peuvent rapidement identifier et
répondre aux menaces potentielles.
• Personnalisation :
Les WAF peuvent être personnalisés pour répondre aux besoins spécifiques d’une
application web ou d’une organisation particulière.
• Intégration avec d’autres solutions de sécurité :
Les WAF peuvent être intégrés à d’autres solutions de sécurité telles que SIEM
(gestion de l’information et des événements de sécurité) et IDS/IPS (systèmes de
détection/prévention d’intrusion) pour fournir une posture de sécurité globale.
• Journalisation et reporting :
Les WAF fournissent des journaux et des rapports détaillés sur le trafic web et les
événements de sécurité, qui peuvent être utilisés à des fins d’audit et de conformité.
• Équilibrage de charge :
Certains WAF offrent également des capacités d’équilibrage de charge pour assurer
une haute disponibilité et performance des applications web.
• Décryptage SSL/TLS :
Les WAF peuvent décrypter le trafic SSL/TLS pour l’inspecter à la recherche de
menaces potentielles avant de le ré-crypter et de le transférer à l’application web.
• Patch virtuel :
Les WAF peuvent fournir des correctifs virtuels pour atténuer les vulnérabilités
dans les applications web avant qu’elles ne soient corrigées par les développeurs de
l’application.
Grâce à ces fonctionnalités les WAFs fournissent une couche de protection aux applications
web contre les cyber-attaques courantes et sophistiquées et aident les organisations à
maintenir une présence en ligne sécurisée.
2.7 Les WAFs open-source

Dans cette section nous allons présenter les WAF open-source les plus populaires ces
dernières années, ainsi que leurs points forts et leurs points faibles[9] [21] :
ModSecurity :
ModSecurity est un WAF multiplateforme qui peut être déployé pour sécuriser les
applications web et les API. Il est conçu pour intercepter et inspecter le trafic entrant,
filtrer les requêtes indésirables et prévenir différents types d’attaques.
ModSecurity fournit également un langage de règles puissant qui permet aux adminis-
trateurs de définir des règles personnalisées pour filtrer le trafic en fonction d’un large
éventail de critères, y compris l’adresse IP, les en-têtes de requête et le contenu de la
requête.[19]
20
Points forts :
• Il peut détecter et prévenir un large éventail d’attaques sur les applications web.
• Il peut être intégré aux serveurs web les plus courants, tels qu’Apache et Nginx.
• Il permet de surveiller et d’enregistrer le trafic web en temps réel.
• Il peut être personnalisé pour répondre aux exigences de sécurité spécifiques des
différentes applications web.
Points faibles :
• Il est difficile à configurer et à entretenir.
• Il peut avoir un impact négatif sur les performances des applications web.
• Il peut générer des faux positifs, ce qui peut entraîner un blocage du trafic légitime.
IronBee :
IronBee fournit une protection complète contre divers types d’attaques basées sur le
web. Il utilise une architecture modulaire qui lui permet d’être facilement étendu avec des
plugins personnalisés, offrant ainsi une flexibilité nécessaire pour répondre aux besoins de
sécurité spécifiques de toute application web.
Points forts :
• Il est conçu pour être hautement évolutif et peut gérer de grands volumes de trafic
web, ce qui le rend adapté aux sites web et aux applications web à fort trafic.
• IronBee comprend un système flexible de journalisation et de reporting qui facilite

l’analyse du trafic et des événements de sécurité.
Points faibles :
• Sa manipulation nécessite un certain niveau d’expertise technique.
• Certains utilisateurs ont signalé des problèmes de performance avec IronBee, en

particulier lors de l’utilisation de certains plugins ou l’utilisation du matériel plus
ancien.
NAXSI :
NAXSI (Nginx Anti XSS & SQL Injection) est un WAF très répandu. Il s’agit d’un
projet open-source conçu pour le serveur web Nginx.
21
Points forts :
• Facile à installer et à configurer.
• Il génère des journaux qui peuvent être analysés pour identifier et résoudre les
problèmes de sécurité.
Points faibles :
• Il n’est pas efficace contre les attaques sophistiquées qui ne correspondent pas aux
modèles prédéfinis.
• Il peut générer des faux positifs, ce qui peut entraîner le blocage du trafic légitime.
• Il peut avoir un impact sur les performances des applications web.
WebKnight :
C’est un WAF populaire pour le serveur web Microsoft Internet Information Services
(IIS).
Points forts :
• Il fournit un ensemble de règles préconfigurées qui couvrent de nombreux scénarios

d’attaque courants, et ces règles peuvent être personnalisées pour répondre aux
besoins de sécurité spécifiques de n’importe quelle application web.
• Il comprend un puissant système de journalisation et de reporting qui fournit des

informations détaillées sur le trafic entrant et les attaques détectées, ce qui facilite
l’identification et la réponse aux incidents de sécurité.
• Il présente une légèreté et une faible surcharge de performance, ce qui se traduit par
une absence d’impact notable sur la performance de votre application web.
Points faibles :
• Peut etre long à configurer et à maintenir.
• Certains utilisateurs ont signalé des problèmes de compatibilité avec certaines ap-
plications web, qui peuvent nécessiter une configuration manuelle pour être résolus.
• Le développement de WebKnight semble avoir ralenti ces dernières années, avec

aucune mise à jour ou version majeure depuis 2013.
• Offre un faible niveau de protection contre les techniques d’attaques avancées.
22
Shadow Daemon :
C’est un WAF conçu pour être hautement personnalisable et peut être configuré pour
répondre aux besoins de sécurité spécifiques de n’importe quelle application web. Shadow
Daemon utilise une approche multicouche pour filtrer le trafic entrant, y compris la dé-
tection basée sur les signatures, la détection des anomalies et l’analyse du comportement.
Points forts :
• Il comprend un puissant système de journalisation et de reporting qui fournit des

informations détaillées sur le trafic entrant et les attaques détectées, ce qui facilite
l’identification et la réponse aux incidents de sécurité.
• Shadow Daemon est léger et a une faible surcharge de performance, ce qui signifie
qu’il n’a pas d’impact significatif sur la performance de votre application web.
Points faibles :
• Son installation, sa configuration et son utilisation nécessitent une expertise tech-

nique plus avancée que d’autres WAFs dont le processus de configuration est plus
simple.
Le tableau 2.1 résume les différentes caractéristiques et performances des waf men-
tionnés ci-dessus, où :
• Compléxité : est la compléxité de manipulation et de mise-en-oeuvre de ses règles.
• Fléxibilité : est la possibilité d’adapter ses règles aux changements sur les réseaux.
• Système de journalisation : est la possibilité d’enregistrer et de récupérer les

informations relatifs aux attaques bloquées à partir des logs.
• Impacte sur la performance de l’application web : sont les effets de l’existence

du WAF sur le système sur les performances de la web app.
23
WAF Complexité Flexibilité Système de Impact sur la

journalisation performance de
l’application web
ModSecurity Complexe Haute Difficile à Peut avoir un
implémenter impact négatif
NAXSI Simple Limitée Facile à Peut avoir un
implémenter impact négatif
WebKnight Complexe Limitée Facile à Impact léger
implémenter
Shadow daemon Complexe Limitée Facile à Impact léger
implémenter
IronBee Complexe Moyenne Facile à Peut avoir un effet
implémenter négatif
Tab. 2.1 : Tableau comparatif entre les WAF open source populaires
2.8 Conclusion
Les pare-feux jouent un rôle essentiel dans le renforcement de la sécurité d’un réseau
ou d’un système en général. Parmi ces solutions, les WAF qui sont spécifiquement conçus
pour garantir la sécurité des applications web, répondant ainsi à des besoins cruciaux en
matière de cybersécurité.
Après avoir exploré ces aspects dans ce chapitre, il est temps de passer au chapitre suivant,
où nous aborderons les outils nécessaires la mise en œuvre de notre solution.
24
Chapitre 3
Implémentation de ModSecurity sur

Nginx
25
Chapitre 3. Implémentation de ModSecurity sur Nginx
3.1 Introduction
Dans ce chapitre, nous allons détailler notre solution de sécurisation des applications
web en utilisant le WAF ModSecurity comme proxy inverse. Le WAF a été déployé en tant
que module sur un serveur Nginx, et nous avons configuré le fichier de règles de sécurité
coreruleset à différents niveaux de paranoïa.
Notre objectif principal était d’améliorer la sécurité des applications volontairement vul-
nérables en bloquant un maximum de cyber-attaques.
3.2 Outils utilisés

Cette section présente les différents éléments utilisés pour la mise en place de notre
solution, y compris le WAF sélectionné, la syntaxe des règles appliquées, ainsi que les
applications testées en termes de sécurité et les programmes associés.
ModSecurity :
Après avoir réalisé une étude comparative dans le chapitre précédent 2.7 et consulté
plusieurs articles, nous avons opté pour le WAF ModSecurity. Ces sources soulignent que
ModSecurity présente un ensemble de fonctionnalités supérieur à celui des autres WAFs[1].
Configuration de ModSecurity :
La configuration de ModSecurity se fait par la définition des règles et des conditions

appropriées. Ces règles et conditions permettent d’identifier les comportements ou les mo-
tifs associés au trafic malveillant et de décider, ensuite, de filtrer ou bloquer ce trafic pour
protéger l’application web.
Les règles de ModSecurity peuvent être définies en utilisant un langage de configuration
spécifique appelé ”ModSecurity Rule Language” (MSRL) qui est basé sur une syntaxe
similaire à celui des fichiers de configuration Apache. Il permet aux administrateurs de
définir des règles en utilisant différents types de directives, qui décrivent les aspects spé-
cifiques d’une règle.
La syntaxe générale d’une règle est définie de la manière suivante :
SecRule VARIABLE OPERATEUR ”VALEUR de CORRESPONDANCE”
”ACTIONS”
où :
• SecRule : directive qui indique le début d’une règle ModSecurity.
• Variable : spécifie l’argument sur le quel la règle sera appliquée. Il peut s’agir
d’un en-tête de requête HTTP,du corps de cette requête, d’un paramètre d’URL,
ou d’autres éléments.
26
• Operateur : opérateurs de comparaison utilisés pour comparer la valeur de la

variable à la valeur de correspondance. Les opérateurs couramment utilisés dans les
règles ModSec sont listés dans le tableau 3.1 .
@rx correspondance d’expressions régulières

@streq égalité des chaîne
@contains correspondance de sous-chaîne
@endsWith correspondance de suffixe
@beginsWith correspondance de préfixe
Tab. 3.1 : Les Opérateurs des règles de ModSecurity
• Valeur de correspondance : Valeur à laquelle la variable sera comparée à l’aide

de l’opérateur.
• Actions : Il s’agit des actions qui seront entreprises si la règle est déclenchée. Les
actions les plus courantes sont listées dans le tableau 3.2
deny bloquer la demande

redirect rediriger la demande vers une URL différente
pass autoriser la poursuite de la demande
log enregistrer un message dans les journaux du serveur
Tab. 3.2 : Les Opérateurs des règles de ModSecurity
Voici un exemple d’une règle :

SecRule ARGS :testparam ”@contient test” ”id :1234,deny,status :403,msg :’Notre
règle de test s’est déclenchée’”
Cette règle vérifie la présence de la chaîne ”test” dans la valeur du paramètre ”testparam”
d’une requête HTTP. Si la chaîne ”test” est présente dans la valeur du paramètre, la règle
sera déclenchée et les actions suivantes seront exécutées :
• id :1234 : Ceci définit un identifiant unique pour la règle.
• deny : Ceci indique au WAF de refuser la requête.
• status :403 :Définit le code d’état de la réponse HTTP à 403 (Forbidden).
• msg :Il s’agit d’un message qui sera enregistré par le WAF pour indiquer que la
règle a été déclenchée.
En résumé, cette règle refusera toute requête HTTP dont le paramètre ”testparam”
contient la chaîne ”test” et enregistrera un message dont le texte est ”Notre règle de
test s’est déclenchée”.
27
Étapes de traitement de données de ModSecurity :

Le manuel ModSecurity[19], qui est la documentation officielle du pare-feu d’applica-
tion web ModSecurity, décrit son processus de traitement en neuf étapes :
1. Lecture de la demande : ModSecurity lit la requête entrante du serveur web.
2. Traitement des en-têtes de la demande : Il traite les en-têtes de la demande

et effectue toutes les transformations nécessaires, telles que le décodage de l’URL
ou de l’entité HTML.
3. Traitement du corps de la demande : Il traite le corps de la demande et effectue

toutes les transformations nécessaires, telles que l’analyse XML ou JSON.
4. Génération d’un journal d’audit : Il génère une entrée dans le journal d’audit
pour la demande.
5. Moteur de règles : Il applique le moteur de règles à la demande, en recherchant

les correspondances de règles.
6. Traitement des règles : Si une règle est détectée, Il exécute l’action correspon-
dante, qui peut consister à bloquer la demande, à la modifier ou à consigner l’évé-
nement.
7. Traitement de la réponse : Il traite la réponse à la demande, y compris les

en-têtes et le corps du message.
8. Écriture du journal d’audit : Il écrit le journal d’audit sur le disque.
9. Remise de la réponse : Il renvoie la réponse au serveur web ou au client.
Néanmoins, il faut savoir que certaines étapes peuvent être ignorées ou modifiées en
fonction de la demande à traiter.
ModSecurity Core rule set (CRS) :

CRS est un ensemble prédéfini de règles de sécurité conçu spécialement pour Mod-
Security afin de détecter un large éventail d’attaques, y compris le Top 10 de l’OWASP,
avec un minimum de fausses alertes[16].
Le CRS a différents niveaux de paranoïa (Paranoia Levels - PL) qui permettent de définir
son degré d’agressivité.
Les quatre niveaux de paranoïa du projet CRS sont définis comme suit[29] :
• PL1 : Le niveau de sécurité de base qui ne génère pas de fausses alertes positives.
• PL2 : Ces règles doivent être utilisées lorsque des données sensibles des clients sont
impliquées, cependant elles peuvent générer des fausses alertes positives.
28
• PL3 : Sécurité au niveau des banques en ligne qui présentes souvent un grand
nombre de fausses alertes positives. L’ingénieur de sécurité doit donc être capable
de gérer ces fausses alertes en écrivant des exclusions de règles.
• PL4 : Règles très robustes (ou paranoïaques) qui génèrent un grand nombre de
fausses alertes positives.
Applications vulnérables :
Afin de démontrer la capacité de ModSecurity à intercepter et bloquer les cyber-
attaques, nous avons déployé les applications vulnérables suivantes :
DVWA :
Damn Vulnerable Web Application est une application web, conçue avec la pile LAMP
3.5 et qui fait partie de l’OWASP.
Cette application vulnérable est utilisée dans le but d’apprendre et de pratiquer différentes
techniques de sécurité des applications web, notamment l’identification et l’exploitation
de vulnérabilités. De plus, DVWA offre un environnement sécurisé aux professionnels de
la sécurité, aux étudiants et aux développeurs, leur permettant d’acquérir une expérience
pratique dans la recherche et la résolution des failles de sécurité couramment présentes
dans les applications web [26].
Juice Shop :
Juice Shop est une application web intentionnellement vulnérable similaire à DVWA,
développée et maintenue, aussi par l’OWASP.
Cette web app est conçue complètement avec JavaScript ( AngularJS, Express.js ) et SQ-
Lite comme base de données[25]. Elle comporte divers défis sous forme de vulnérabilités
exploitables.
Nginx :
Nginx, un serveur web open-source largement utilisé, est spécialement conçu pour
traiter efficacement les requêtes HTTP et HTTPS.
Sa capacité à évoluer et à agir en tant que loadbalancer [5], nous a incités à l’utiliser
comme proxy inverse lors de la mise en place de notre solution.
La figure 3.1 illustre l’utilisation de Nginx dans notre environnement de tests.
29
Fig. 3.1 : Nginx comme proxy inverse
SIEM :
Security Information and Event Managment est la gestion et la surveillance des in-
formations de sécurité. Pour assurer cette fonction, nous avons utilisé les programmes
suivants :
Promtail :
Promtail est une application légère de type agent chargée de collecter et de transmettre
les données de journalisation (logs) pour qu’elles soient ingérées par Prometheus, Grafana
ou autre écosystèmes de surveillance et d’alertes.
Nous avons configuré Promtail de manière à extraire le contenu des fichiers error.log
, qui contiennent des enregistrements de demandes provenant de ModSecurity, et à les
envoyer à Loki.
Loki :
Loki est un système d’agrégation et de stockage de journaux (logs) inspiré de Prome-
theus. Son objectif est de fournir une solution efficace pour la collecte, l’exploration et
l’analyse des journaux générés par les applications et les infrastructures[11]. Cependant,
contrairement à Prometheus, Loki n’indexe pas le contenu des journaux, mais attribue
plutôt un ensemble d’étiquettes à chaque flux de journaux.
Grafana :
Grafana est une plateforme open source de visualisation de données et de création de
tableaux de bord. Elle permet de connecter différents systèmes, de collecter des données
et de créer des graphiques et des visualisations interactives[2] à l’aide des requêtes écrites
avec PromQl : Prometheus Query Language. En effet, ce langage permet de récupérer,
30
filtrer, agréger et effectuer des calculs sur des données de séries temporelles[18].
Nous avons configurée ce service de manière à le rendre accessible à partir du port 3000,
en utilisant les identifiants par défaut : addmin / admin . Ensuite, nous avons défini
Loki comme source de données pour ce service
Les outils de pentests :
Kali linux :
Kali Linux est une distribution Linux basée sur Debian spécialement conçue pour
les tests d’intrusion qui permettent d’évaluer la sécurité d’un système ou d’un réseau
informatique en simulant des attaques[3]. Kali offre également une large gamme d’outils
qui permettent de réaliser différentes fonctions comme :
• Zap :
Le Zed Attack Proxy de l’OWASP (ZAP) est un outil de test de pénétration intégré
et facile à utiliser. Il est conçu pour être utilisé par des personnes de tous niveaux
d’expériences pour trouver des vulnérabilités dans les applications web [10] .
• Burp Site :
Burp Suite est un outil de test de sécurité des applications web développé par
PortSwigger. Il offre une gamme de fonctionnalités pour aider les professionnels de
la sécurité à identifier les vulnérabilités et à tester la sécurité des applications web[4].
Nous l’avons utiliser comme proxy afin d’intercepter et apercevoir les requêtes et
les réponses envoyées.
• Slowhttptest :
SlowHTTPTest est un outil hautement configurable qui simule des attaques DoS
au niveau de la couche application. Il permet de prolonger les connexions HTTP de
différentes manières [22] en fonction des paramètres de configuration spécifiés lors
du lancement de l’attaque.
• Wfuzz :
Cet outil est spécialement utilisé pour le fuzzing ou l’automatisation des attaques
d’injection. Son principe est de remplacer toutes les occurrences du mot clé ”FUZZ”
par des payloads, qui sont des sources de données spécifiées par l’attaquant sous la
forme de fichiers .txt .
• Weevely :
C’est un web shell PHP conçu pour l’administration des serveurs à distance. Il
génère des fichiers PHP malveillants qui peuvent être téléchargés sur un site web et
exécutés, pour assurer un accès shell à distance.
31
3.3 Mise en œuvre de l’environnement de test

Dans cette section, nous expliquerons toutes les étapes de mise en œuvre et les tests
effectués pour démontrer l’efficacité de ModSecurity dans la protection des applications
web contre diverses cyber-attaques.
Implémentation :
Au cours de cette étape, nous avons préparé l’environnement des tests en configurant
les applications vulnérables et en mettant en place le WAF ModSecurity, comme l’illustre
la figure 3.2 .
L’implémentation s’est déroulée de la manière suivante :
• Déployer une machine virtuelle, ubuntu sur azure cloud.
• Héberge DVWA et Juice Shop comme containers.
• Installer Nginx et le configurer comme proxy inverse.
• Installer ModSecurity puis le configurer comme module sur nginx en utilisant le

connecteur nginx-modsecurity.
• Configurer la dernière version : 3.3.4 du CRS comme règles de sécurité sur ModSe-
curity.
• Concevoir un système de SIEM en utilisant promtail et loki pour la lecture des logs,
et grafana pour leurs visualisation en temps réel.
Fig. 3.2 : Environnement des tests
32
Tests :
L’objectif de notre étude est de démontrer la capacité des WAF à améliorer la sécurité
des applications web, notamment face aux attaques de la couche application qui peuvent
compromettre leur bon fonctionnement.
Pour mener nos tests, nous avons procédé à des attaques cybernétiques sur les applica-
tions déployées dans deux scénarios : sans l’utilisation de ModSecurity, et en utilisant
ModSecurity avec les 4 PL (Politiques de Paranoïa) du core rule set, en exploitant les
outils de pentesting mentionnés dans la section précédente 3.2 .
Pour la simulation des attaques, nous avons adopté la topologie suivante :
Fig. 3.3 : Topologie de l’implémentation
Nous avons utilisé une machine virtuelle Kali Linux dotée des outils mentionnés pré-
cédemment 3.2 pour simuler le comportement d’un attaquant.
En ce qui concerne les attaques incluses dans nos tests, nous avons évalué les vulnérabi-
lités suivantes : LFI (inclusion de fichiers locaux), SQLi (injection SQL), XSS (cross-site
scripting), DoS (déni de service), les attaques d’injection de commandes et les scans de
vulnérabilités.
Le tableau 3.3 résume les résultats des attaques testées.
Attaques PL=1 PL=2 PL=3 PL=4

LFI Passée Passée Passée Bloquée
SQLi Passée Bloquée Bloquée Bloquée
XSS Bloquée Bloquée Bloquée Bloquée
Injection de commandes Passée Bloquée Bloquée Bloquée
Scans des vulnérabilités Bloquée Bloquée Bloquée Bloquée
Téléchargement des fichiers Passée Passée Bloquée Bloquée
DoS Bloquée Bloquée Bloquée Bloquée
Tab. 3.3 : Résultats des attaques testées.
33
3.4 Analyses des résultats
Détection des LFI :

ModSecurity réagit aux attaques LFI en appliquant les règles spécifiées dans le fi-
chier REQUEST-930-APPLICATION-ATTACK-LFI.conf . Ces règles permettent
de comparer le contenu de la requête HTTP avec un ensemble de caractères ou de chaînes
de caractères. Cependant, il est important de noter que si des caractères indétectables
sont inclus, il serait possible de contourner facilement le WAF.
Lorsque nous avons tenté de récupérer le contenu du fichier /etc/passwd, nous avons
reçu une réponse ”403 Forbidden” du WAF, indiquant que l’accès était interdit, comme
le montre la figure 3.6 .
Par contre, aprés plusieurs tentatives nous avons pu accéder à des fichiers dont l’accés
n’est pas restreint par les règles de sécurité, dont /proc/modules comme le montre la
figure 3.7.
Fig. 3.5 : Après ModSecurity

Fig. 3.4 : Avant ModSecurity
Fig. 3.6 : Attaque LFI avant et après l’utilisation de ModSecurity
Fig. 3.7 : Contourner ModSecurity avec une attaque LFI
Après avoir appliqué le quatrième niveau de paranoïa, toutes les tentatives d’accès
aux fichiers sur le serveur ont été bloquées, et une alerte de type ”Inbound Anomaly
Score Exceeded” a été enregistrée dans le journal d’erreurs de nginx. Cette alerte indique
34
que le trafic entrant a dépassé un seuil prédéfini de comportement anormal. En effet,

ModSecurity attribue un score d’anomalie à chaque requête en fonction de divers facteurs
tels que le nombre et la gravité des anomalies détectées, ainsi que du niveau de sensibilité
configuré. Si le score cumulatif d’anomalie dépasse un certain seuil, le message ”Inbound
Anomaly Score Exceeded” est généré.
Le listing ?? est le message enregistré sur le journal d’erreur de nginx aprés avoir essayé
d’accéder au fichier /proc/modules au niveau PL=4 .
1 [date] [time] [ error ] 11244#11244: *1 [ client 41.98.12.144] ModSecurity
: Access denied with code 403 ( phase 2). Matched " Operator `Ge ' with
parameter `5' against variable `TX: ANOMALY_SCORE ' ( Value : `8' ) [file "/
usr/ local / coreruleset -3.3.4/ rules /REQUEST -949 - BLOCKING - EVALUATION .conf "]
[line "81"] [id "949110"] [rev ""] [msg " Inbound Anomaly Score Exceeded
(Total Score : 8) "] [data ""] [ severity "2"] [ver " OWASP_CRS /3.3.4"] [
maturity "0"] [ accuracy "0"] [tag " application - multi "] [tag "language -
multi "] [tag "platform - multi "] [tag "attack - generic "] [ hostname
"10.1.0.4"] [uri "/ vulnerabilities /fi /"] [ unique_id
"168504108830.762878"] [ref ""] , client : 41.98.12.144 , server :
20.223.129.220 , request : "GET / vulnerabilities /fi /? page =%2 fproc %2
fmodules HTTP /1.1" , host: "20.223.129.220"
2
Listing 3.1: Message d’alerte sur error.log
Détection des SQLi :

La configuration nécessaire pour bloquer ce type d’attaques est définie dans le fichier
REQUEST-942-APPLICATION-ATTACK-SQLI.conf , qui est utilisé pour filtrer
les requêtes HTTP contenant des motifs indiquant une attaque SQLi.
Nous avons effectué 252 attaques à l’aide de wfuzz 3.2 , à chaque niveau de paranoïa, afin
d’injecter des charges maximales. Parmi ces injections, seules deux ont réussi à contourner
le WAF au niveau PL=1 :
11’+or++WEIGHT_STRING(version)=WEIGHT_STRING(version) et
1 exec sp_ (or exec xp_) AND 11̄ .
La figure 3.10 le démontre.
À partir du niveau PL=2, toutes les attaques ont été bloquées. Un message identique à
celui mentionné précédemment est affiché dans le journal d’erreurs de Nginx, à l’exception
des détails spécifiques à chaque attaque.
35
Fig. 3.9 : Attaques bloquées

Fig. 3.8 : Contourner ModSecurity avec
une SQLi
Fig. 3.10 : Résultats des tests SQLi
Détection des XSS :

En utilisant wfuzzer et burpsuite, nous avons lancés plus de 90 attaques XSS, sto-
ckées ou réfléchies, qui ont été tous bloquées par les règles du fichier REQUEST-941-
APPLICATION-ATTACK-XSS.conf.
Détection des Injection de commandes :

Nous avons réussi à détecter une seule faille exploitable après avoir lancé près de 70
attaques d’injection de commandes. Cette faille peut contourner le WAF au niveau PL=1
en rajoutant un ;) puis la commande que nous voulons exécuter. Voir figure 3.11 .
Cependant, cette faille devient inexploitable aux niveaux de paranoïa supérieurs et Mod-
Security bloque tous les motifs de ce type d’attaques.
Fig. 3.11 : Contourner ModSecurity avec une Injection de commande
Scans de vulnérabilités :
Nous avons utilisé zaproxy 3.2 pour lancer un scan de vulnérabilités sur l’application,
en lançant plusieurs requêtes HTTP de type GET et POST dans le but de détecter le
maximum de failles.
Le WAF a pu reconnaître et bloquer la majorité de ses requêtes, selon leurs motifs.
36
La figure 3.12 démontre les résultats du scan, en citant la méthode, l’URL visée et la
réponse du serveur.
Fig. 3.12 : Partie des résultats du scan
Détection des téléchargements des fichiers sur le serveur :

ModSecurity s’est révélé robuste lorsqu’il s’agissait de télécharger des fichiers .php
. Nous avons également testé d’autres formats de fichiers tels que .sh, qui contient des
scripts en bash, et .pht, qui correspond à des pages HTML contenant du code PHP. Pour
réaliser ce test, nous avons utilisé weevely 3.2 pour générer un fichier PHP qui permettrait
de créer une porte dérobée donnant accès au serveur sur lequel l’application est hébergée.
Ensuite, nous avons modifié le format de ce fichier en .pht afin de pouvoir le télécharger
sur le serveur distant.
Cependant, lorsque nous avons essayé d’accéder au fichier avec weevely, nous avons été
bloqués par ModSecurity, comme le démontre la figure 3.13 , ce qui nous a empêchés
d’exploiter le fichier.
Notons qu’à partir du niveau PL=3, toutes nos tentatives de téléchargement de n’importe
quel fichier ont été bloquées.
Fig. 3.13 : Accès au serveur avec weevely
Détection des DoS :

Nous avons utilisé slowhttptest 3.2 pour simuler une attaque par déni de service (DoS)
en utilisant les paramètres répertoriés dans le tableau 3.4 . Ces paramètres impliquent
1000 connexions effectuant des requêtes GET vers l’URL de l’application. La taille de la
charge utile de cette requête est de 4096 octets, avec une taille maximale de 52 octets
pour les données de suivi, et un intervalle de 10 secondes entre l’envoi de ces données. Les
37
connexions par seconde sont réglées sur 200, avec un délai d’expiration de connexion de
3 secondes. ModSecurity a réussi à bloquer ces connexions après un court laps de temps,
Type de tests Slow Headers

Nombre de connections 1000
Action GET
valeur de content-length de l’en-tête 4096
Taille max des données 52
intervalle d’attente 10s
Nombre de connexions par seconde 200
Délai d’attente de connexion 3s
Durée du test 240s
Tab. 3.4 : Paramètres de slowhttptest
qui varie de 60 à 65 secondes. Selon la Figure 3.14 qui représente les résultats du test
de l’application au niveau PL=1, le service était disponible pendant les six premières
secondes. À la septième seconde, il y avait un total de 786 connexions, dont 214 ont
été fermées par le WAF. Cette situation a persisté jusqu’à la soixantième seconde, où le
nombre de connexions fermées a considérablement augmenté, et le service est devenu à
nouveau disponible.
Fig. 3.14 : Résultats de l’attaque DoS
3.5 Conclusion
Le CRS v3.3.4 est un ensemble de règles négatives, ce qui le rend potentiellement
vulnérable aux attaques dont les motifs ne sont pas configurés dans sa liste. Cependant,
ModSecurity a réussi à bloquer la grande majorité des attaques dirigées contre les appli-
cations web vulnérables.
Bien qu’il y ait eu quelques attaques qui ont pu contourner le WAF sans être détectées,
il est important de souligner que ModSecurity a détecté et bloqué la grande majorité de
ces attaques. De plus, il a même réussi à stopper une attaque de type DoS, ce qui ajoute
une couche de sécurité significative aux applications web.
38
Conclusion et perspective
39
Conclusion et perspective
Conclusion Générale
Dans le cadre de ce mémoire, nous avons réalisé une étude approfondie sur les Web Ap-
plication Firewalls (WAF), en examinant leur fonctionnement, leur déploiement et leurs
modèles de règles de sécurité. Notre objectif était de démontrer leur capacité à atténuer
les cyberattaques courantes telles que LFI, RFI, XSS, SQLi et DoS.
Les résultats obtenus suite aux tests de sécurité des applications web en utilisant ModSe-
curity sur Nginx en tant que proxy inverse mettent en évidence le rôle essentiel des WAF
pour renforcer la sécurité des applications web.
En effet, nous avons pu ajouter une couche de protection contre les attaques d’inclusion
de fichiers, les attaques XSS , les SQLi, les injections de commandes et les attaques de
type DoS.
Ces mesures ont permis de masquer les vulnérabilités identifiées par l’OWASP (Open Web
Application Security Project). Cependant, il est important de noter que l’utilisation de
l’ensemble de règles CRS v3.3.4 pour la configuration de ModSecurity le rend potentielle-
ment vulnérable aux nouvelles attaques et à celles qui ne sont pas définies dans ses règles.
Malgré cette limitation, nos résultats ont démontré l’efficacité de ModSecurity dans la
détection et la prévention d’un large éventail d’attaques, ce qui a considérablement ren-
forcé la sécurité des applications web. Toutefois, il convient de souligner que les WAF ne
peuvent pas à eux seuls garantir une protection totale contre toutes les cyberattaques.
Pour conclure notre mémoire, nous tenons à mettre en avant l’importance des bonnes
pratiques de sécurisation lors de la conception d’une application web, afin que le WAF
puisse jouer un rôle complémentaire dans le dispositif de sécurité. Chaque entreprise doit
également mettre en place des mécanismes de sécurité adaptés à la taille, au domaine
d’activité et aux besoins spécifiques de ses applications web.
Perspective
Les recherches que nous avons menées dans le cadre de ce projet nous ont permis de
comprendre l’importance de combiner un modèle d’apprentissage avec les règles de sécu-
rité des WAFs.
Cette approche permet d’assurer une évolution constante des règles de sécurité en prenant
en compte les nouvelles attaques, au lieu d’être limitée à des motifs d’attaques spécifiques.
Envisager une étude conceptuelle pour répondre à ce besoin serait une contribution pro-
metteuse visant à améliorer les performances des WAFs.
40
Bibliographie & Webographie
[1] Diogo Sampaio & Jorge Bernardino. Evaluation of Firewall Open Source Software.
WEBIST, 2017.
[2] Dashboard anything. Observe everything.
[3] David De Smet De Willie L. Pritchett. Kali Linux Cookbook. Packt publishing,
2013.
[4] David De SmetSagar Rahalkar De Willie L. Pritchett. A Complete Guide to
Burp Suite : Learn to Detect Application Vulnerabilities. Apress, 2021.
[5] Derek DeJonghe. NGINX Cookbook, 2nd edition. O’Reilly Media, Inc., 2022.
[6] Simon Cooper D. Brent Chapman Elizabeth D. Zwicky. Building Internet Fi-
rewalls. ISBN, 2000.
[7] Tiago Espinha & Ulrike Lechner & Daniel Mendez Fernandez. Awareness of Se-
cure Coding Guidelines in the Industry - A first data analysis. IEEE, 2020.
[8] File Inclusion Attacks. Jan. 2022.
[9] G2 Software Reviews. Jan. 2023.
[10] Getting started with OWASP zap.
[11] Grafana documentation, Loki.
[12] Karen Scarfone & Paul Hoffman. Guidelines on Firewalls and Firewal Policy.
Computer Security Division Information Technology Laboratory National Institute
of Standards et Technology Gaithersburg, MD 20899-8930, 2009.
[13] Thomas A. Johnson. CyberSecurity, Protecting Critical Infrastructures from Cyber
Attack and Cyber Warfare. Taylor & Francis Group, LLC, 2015.
[14] Lablabee’s Hardening lab - level 1. Juin 2020.
[15] Open Web Application Security Project’s official website. Jan. 2023.
[16] OWASP ModSecurity Core Rule Set.
[17] Saad Khan & Simon Parkinson & Yongrui Qin. Fog computing security : a review of
current applications and security solutions. Journal of Cloud Computing : Advances,
Systems et Applications, 2017.
[18] QUERYING PROMETHEUS.
[19] Christian Follini & Ivan Ristic. ModSecurity Handbook, second edition. ISBN, 2017.
41
Bibliographie & Webographie
[20] Rizki Agung Muzaki& Obrina Candra Briliyant & Maulana Andika Hasditama &
Hamzah Ritchi. Improving Security of Web-Based Application Using ModSecurity
and Reverse Proxy in Web Application Firewall. International Workshop on Big
Data et Information Security (IWBIS) IEEE, 2020.
[21] Server Guy Ratings. Avr. 2023.
[22] SlowHTTPTest GitHub repositury.
[23] Top 10 Web Application Security Risks. Jan. 2021.
[24] University of Michigan, Best Practices for Secure Coding. Jan. 2023.
[25] Fernando Román Muñoz & Iván Israel Sabido Cortes & Luis Javier García Villalba.
Enlargement of vulnerable web applications for testing. Springer Science+Business,
New York, 2017.
[26] Gajanan Shinje & Sanjhya S. Waghere. Web Application Vulnerabilities : Ex-
ploitation and Prevention. Proceedings of the Second International Conference on
Research in Intelligent et Computing in Engineering, 2017.
[27] Web Application FIrewall (WAF). Août 2018.
[28] What is WAF | Types, Security & Features Explained. Avr. 2023.
[29] Working with Paranoia Levels. Oct. 2021.
42
Annexe
43
Annexe
La pile LAMP ( LAMP stack ) :

LAMP est une abréviation pour Linux, Apache, MySQL et PHP. Cette pile est l’une
des premières piles de logiciels open-source pour le développement web, et l’une des bases
les plus utilisées pour développer des applications web personnalisées.
Les quatres logiciels qui composent cette pile constituent un environnement assez robuste
et performant qui permet aux sites et web apps de s’exécuter dessus tout en étant gratuits
et open-source.
Configuration de la DVWA :
Nous avons pu heberger DVWA sur une VM ubuntu sur Azure en utilisant docker
compose et l’image prédéfinie de DVWA afin de faciliter sa mise en oeuvre. L’application
était exposée au port 8081 de la VM.
1 version : "3.8"
2 services :
3 dvwa:
4 container_name : dvwa
5 image: vulnerables /web -dvwa
6 restart : always
7 ports:
8 - 8081:80
9 volumes :
10 - ./ php.ini :/ etc/php /7.0/ apache2 /php.ini
11 -./ config .inc.php :/ var/www/html/ config / config .inc.php
Listing 3.2: Fichier YAML pour DVWA
44
Annexe
Une fois que l’application marche, nous pouvons accéder à la page de configuration
setup.php sur laquelle nous verrons les configurations nécessaires au bon fonctionnement
de la DVWA.
Fig. 3.15 : DVWA/setup.php
Puis, nous devons créer la base de données en cliquant sur créer / réinitialiser la
base de données ce qui va nous rediriger vers la page de login.php et nous pourrons y
connecter avec admin / password comme identifiants.
Fig. 3.16 : DVWA/login.php
45
Annexe
Nous nous retrouverons alors sur la page principale de la DVWA où il existe toutes
les pages sur lesquelles nous pourrons tester les attaques sur la couche application, et
surtout, essayer de les bloquer.
Fig. 3.17 : DVWA home page
46
Annexe
Configuration du juice shop :
Comme pour la DVWA, nous avons utilisé l’image docker prédéfinie du juice shop,
afin de l’héberger sur la meme VM.
Nous avons tout simplement lancé un docker container qui était exposé au port 8080 de
la machine.
1 docker pull bkimminich /juice -shop

2 docker run -p 8080:3000 bkimminich /juice -shop
Listing 3.3: Juice Shop container
L’application sera alors accessible.
Fig. 3.18 : Bienvenu sur Juice Shop
Configuration de nginx comme proxy inverse :
Nous avons installé et configuré nginx comme service sur notre VM, qui peut être
accéder à travers le port 80, port HTTP par défaut, et qui pointe, selon le besoin, vers
l’application qu’on veut accéder.
Voici à quoi ressembe les fichiers nginx.conf et pfetest.conf qui constituent principalement
la configuration de ce serveur :
47
Annexe
1 include /etc/ nginx /modules - enabled

/*. conf;
2 load_module /etc/ nginx / modules / 1 server {
ngx_http_modsecurity_module .so 2 root /var/www/html;
; 3 modsecurity on;
3 http{ 4 modsecurity_rules_file /
4 # Basic Settings # etc/ nginx / modsec /main.conf;
5 5
6 # Logging Settings # 6 listen 80;

7 7 listen [::]:80;
8 access_log /var/log/ nginx / 8 server_name 20.223.129.220
access .log; pfewebcommercetest .
9 error_log /var/log/ nginx / northeurope . cloudapp . azure .com
error .log; ;
10 9 location / {
11 # Virtual Host Configs # 10 proxy_pass
12 http ://127.0.0.1:8081/;
13 include /etc/ nginx /conf.d 11 # Additional settings #
/*. conf; 12 }
14 include /etc/ nginx /sites - 13 }
enabled / pfetest .conf;
Listing 3.5: pfetest.conf
15 }
Listing 3.4: nginx.conf
48

Utilisation Des WAFs Dans La Protection Des Applications Web

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Utilisation Des WAFs Dans La Protection Des Applications Web

Transféré par

Droits d'auteur :

Formats disponibles

People’s Democratic Republic of Algeria

‫الجمهورية الجزائرية الديمقراطية الشعبية‬

École Nationale Supérieure des

Mémoire de fin d’études

Option : Télécommunications et Réseaux IP

Utilisation des WAFs dans la

Soutenu le 08 Juin 2023, devant le jury composé de :

Examinateur : Mr. SEDDIK Ilies

Promotion : IGE 43 - 2022/2023

“ Je dédie ce travail en premier lieu à mon père, qui a consacré toute sa

Je dédie ce travail A ma famille, elle qui m’a doté d’une éducation

“ Nous souhaitons exprimer nos remerciements les plus sincères à toutes

To guarantee the security of applications against cyberattacks, it is essential to take

Keywords : Web applications security, Web Application Firewalls (WAF), ModSecurity,

1 Généralités & concepts clés . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Les WAFs et leur fonctionnement . . . . . . . . . . . . . . . . . . . . . . . 13

3 Implémentation de ModSecurity sur Nginx . . . . . . . . . . . . . . . . . 25

1.1 Le changement de catégories entre 2017 et 2021 . . . . . . . . . . . . . . . 10

2.1 Fonctionnement d’un routeur de filtrage[6] . . . . . . . . . . . . . . . . . . 15

3.1 Nginx comme proxy inverse . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.1 Tableau comparatif entre les WAF open source populaires . . . . . . . . . 24

3.1 Les Opérateurs des règles de ModSecurity . . . . . . . . . . . . . . . . . . 27

1.1 Exemple d’un code PHP vulnérable aux inclusions de fichiers. . . . . . . . 5

ACL Access list.

BDD Base de données.

CI/CD Continuous Integration / Continuous Delivery.

CRS Core Rule Set.

CVE Commun Vulnerability and Exposure.

CVSS Commun Vulnerability Scoring System.

CWE Commun Weakness Enumerations.

DDoS Distributed Denial of Service.

DoS Denial of Service.

DPI Deep Packet Inspection.

DVWA Damn Vulnérable Web Application.

HTTP HyperText Transfer Protocol.

IDS Intrusion Detection System.

IETF Internet Engineering Task Force.

IIS Internet Information Service.

IPS Intrusion Prevention System.

LAMP Linux Apache MySQL PHP.

LFI Local File Inclusion.

MSRL ModSecurity Rules Language.

MSSP Managed Security Service Providers.

NAT Network Address Translation.

NAXSI Nginx anti XSS & SQLi.

NGFW Next Generation Firewalls.

OSI Open System Interconnection.

OWASP Open Web Application Security Project.

SCG Secure Coding Guidelines.

SIEM Security Information and Event Management.

SQLi SQL injections.

URL Uniform Ressource Locator.

VPN Virtual Private Network.

WAF Web Application Firewall.

WWW World Wide Web.

XML Extensible Markup Language.

XSS Cross Site Scripting.

XXE XML extended entity injection.

• Chapitre 1 :: Généralités & concepts clés

• Chapitre 2 :: Les WAFs & leurs fonctionnements

• Chapitre 3 :: Implémentation de ModSecurity sur NGINX

• Conclusion & Perspective

Généralités & concepts clés