5

➼ Cartographie d’un site web

Failles Web ➼

➼
Types de vulnérabilités web
Contre-mesures

Dr Siham BOUCHELAGHEM
Maître de Conférences
Université de Bejaia
1
Sécurité des sites web
Une attaque lancée contre un site web peut avoir pour objectif de :

● Rendre le site indisponible pour de multiples raisons (concurrence commerciale,

pour le plaisir, etc.).
● Récupérer des informations non autorisées dans le cadre de l’espionnage
industriel, récupération d’informations bancaires ou confidentielles, etc.
● Prendre le contrôle du serveur de l’entreprise dans l’objectif de lancer une
attaque sur un autre serveur en tout anonymat.
● etc.

Dans tous les cas, la réussite d’une attaque va être le fruit d’une analyse pointue du
comportement du site web.

2
Cartographie d’un site web (1)
La cartographie d’un site web consiste à lister tous les éléments qui le composent.

Un site web est constitué d’une multitude de pages qui sont obligatoirement
organisées suivant une arborescence; c’est le plan du site.

Chaque page est généralement accessible par un lien hypertexte présent dans un
menu ou sur une page. Chaque lien pointe vers une URL (Uniform Resource
Locator) ou une URI (Uniform Resource Identifier) précisant l’endroit où se trouve
la ressource.

On distingue deux types de ressources, celles qui sont dans le même domaine que le
site consulté et celles qui sont dans un autre domaine. Pour faire une cartographie d’un
site web, on doit se limiter au domaine où se trouve ce site.

3
Cartographie d’un site web (2)
Il est parfois difficile de lister l’ensemble des pages d’un même domaine, il vaut
mieux alors essayer d’analyser son comportement et de trouver le maximum
d’informations à travers le fonctionnement normal du site. On parle alors de prise
d’empreinte plutôt que de cartographie.

● Le site est-il statique ou dynamique ? Dans quel langage est-il écrit ?

● Quelles sont les variables utilisées pour transmettre les requêtes ?
● Y a-t-il des formulaires et quels champs utilisent-ils ?
● Le serveur envoie-t-il des cookies, quelles données contiennent-ils ?
● Le site fait-il appel à des bases de données ? à du JavaScript ?
● Est-il possible d’accéder à certains dossiers, contenant des images par exemple ?
● Quel serveur est utilisé, quelle est sa version ?
● etc.

4
Cartographie d’un site web (3)
● Le site est-il statique ou dynamique ?
La première chose à regarder est l’extension du fichier appelé dans l’URL lors de la
navigation. Si l’extension est du type .html ou .htm c’est probablement une page
statique. Si celle-ci est du type .php ou .asp ou encore .jsp, c’est que le site est écrit
dans l’un des langages correspondants. Cependant, les serveurs permettent de
faire de l’URL rewriting (réécriture d’adresse) permettant de masquer le passage
des variables ainsi que le type de langage utilisé. Si l’URL ne donne aucune
information, une analyse du code source peut être fructueuse.

● Quelles sont les variables utilisées pour transmettre les requêtes ?

Dans un site web dynamique, des informations peuvent être transmises dans l’URL
en utilisant la méthode GET.

5
Cartographie d’un site web (4)
● Y a-t-il des formulaires et quels champs utilisent-ils ?
Une autre manière de transmettre des données est l’utilisation des formulaires. C’est
alors la méthode POST qui est généralement utilisée. Pour connaître les champs, il
est possible d’analyser le code source ou d’espionner la transmission des données
au serveur avec des outils comme Wireshark.

● Le serveur envoie-t-il des cookies, quelles données contiennent-ils ?

Les cookies sont des fichiers texte que le serveur peut envoyer au client afin de
stocker des informations lui permettant de mémoriser ses habitudes de navigation,
ses préférences, etc. Un des types de cookies les plus couramment utilisés est le
cookie de session, qui permet au serveur d’identifier le client de manière univoque.

6
Cartographie d’un site web (5)

● Le site fait-il appel à des bases de données ?

Il est très délicat de savoir si un site web utilise une base de données. Suivant la
nature du site on peut émettre de fortes suppositions mais il est difficile d’en obtenir
la preuve. Si le site web est dynamique, il y a de grandes chances pour qu’il utilise
une base de données, mais laquelle ?

● Quel serveur est utilisé, quelle est sa version ?

Avoir une connaissance précise du type de serveur et de son numéro de version est
très important car il existe des failles de sécurité référencées pour chacun d’eux.

7
Cartographie d’un site web (6)

● Le site fait-il appel à du JavaScript ?

Il suffit de regarder le code source, soit le code est directement écrit dans la page,
soit il est dans un fichier séparé et est chargé par la page.

● Est-il possible d’accéder à certains dossiers ?

Il arrive que les serveurs soient mal configurés et autorisent la visualisation du
contenu de dossiers sensibles. Il suffit de regarder la source des médias ou
d’autres fichiers que le site utilise pour avoir une idée des chemins à tester. Ceci peut
conduire à la consultation de fichiers bien plus importants que des images, comme
des fichiers de configuration de serveurs par exemple.

8
Burp Suite

Burp Suite est un outil de sécurité développé par

PortSwigger pour les plateformes, sites et applications
web. Grâce à lui, les pentesters peuvent découvrir les
vulnérabilités d’un site web afin de pouvoir les résoudre
et sécuriser les informations et données.

Burp Suite est composée de différents outils comme un serveur proxy

(Burp Proxy), un robot d’indexation (Burp Spider), un outil d’intrusion (Burp Intruder), un
scanner de vulnérabilités (Burp Scanner) et un répéteur HTTP (Burp Repeater).

9
Attaques par injection
Une attaque par injection consiste à insérer des données malveillantes dans une
application web afin qu’elles puissent être interprétées et exécutées en tant que
commande ou requête.

L’attaquant tente de changer le cours d’exécution de sa cible en injectant des données

inattendues qui forcerait l’application à faire quelque chose qu’elle n’était pas
censée faire. Ces attaques peuvent engendrer une multitude de conséquences
telles que la propagation de logiciels malveillants, le vol et/ou la perte de données,
ou encore des dénis de service.

● Injection de code dans les commandes transmises aux interpréteurs.

● Injection de code par téléversement de fichiers.

10
OWASP
Créée en 2001, l’OWASP (Open Web Application Security Project)
est une organisation internationale à but non lucratif qui se
consacre à la sécurité des applications web.

Elle fonctionne selon un modèle de « communauté ouverte », ce qui signifie que

tout le monde peut participer et contribuer aux discussions en ligne, aux projets,
et plus encore. Des outils et vidéos en ligne, aux forums et événements,
l'OWASP veille à ce que ses offres restent gratuites et facilement accessibles via
son site web.

OWASP : https://owasp.org/

11
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 un large consensus sur les risques
de sécurité les plus critiques pour les applications Web et est mondialement reconnu
par les développeurs comme la première étape vers un codage plus sécurisé.

12
Injection SQL
Une injection SQL, ou SQLi, est une cyberattaque lors de laquelle un hacker entre, ou
injecte, un code SQL malveillant dans une application Web pour la forcer à transmettre
ce code à la base de données en tant que requête légitime.

Ces attaques ne sont possibles que lorsque l’application ne dispose pas de mesures
suffisantes de validation des inputs afin de s’assurer que les données entrées par
les utilisateurs ne s’immiscent pas dans le code, se faisant ainsi passer pour du
code exécutable côté serveur.

Les injections SQL n’exploitent pas une vulnérabilité dans un logiciel spécifique, elles
touchent directement à des applications Web cibles qui ne suivent pas les meilleures
pratiques de secure coding afin de pouvoir accéder et manipuler le stockage de
données dans les BD Relationnelles.

13
Criticité des injections SQL

● Bypass de l’authentification et accès à une zone protégée, voire la gain d’un accès
administrateur, sans pour autant fournir des identifiants valides.
● Divulgation et exposition d’informations sensibles stockées dans une base de
données (numéros de cartes de crédit, mots de passe, etc.).
● Compromission de l’intégrité des données en effaçant une page web, en
insérant un script malicieux, ou encore en altérant le contenu de la BD.
● Compromission de la disponibilité des données en supprimant par exemple les
différentes informations dans la BD, les logs, les informations d’audit, etc.
● Exécution de code arbitraire afin d’atteindre le système d’exploitation et prendre le
contrôle du serveur web.

14
Exemple de scénario (1)

Le principe d’une injection SQL est de fermer la requête prématurément en insérant

une simple côte (‘) puis en complétant la requête afin d’obtenir une autre réponse que
celle qui doit normalement être donnée à l’utilisateur.

SELECT * FROM Utilisateur

WHERE identifiant = 'myusername'
Connexion AND motdepasse = 'mypassword';
Identifiant : myusername

Mot de passe : mypassword

OK
SELECT * FROM Utilisateur
WHERE identifiant = 'Bob'; --'
AND motdepasse = 'blabla';

15
Exemple de scénario (2)

Le principe d’une injection SQL est de fermer la requête prématurément en insérant

une simple quote ‘ puis en complétant la requête afin d’obtenir une autre réponse que
celle qui doit normalement être donnée à l’utilisateur.

SELECT * FROM Utilisateur

WHERE identifiant = 'myusername'
Connexion AND motdepasse = 'mypassword';

Identifiant : myusername

Mot de passe : mypassword

SELECT * FROM Utilisateur
OK
WHERE identifiant = 'blabla' OR 1=1; --'
AND motdepasse = 'blabla';

16
Types d’injection SQL
Injection SQL basée sur les erreurs

Ce type d’injection repose entièrement sur les erreurs générées par les requêtes SQL.

L’attaquant insère intentionnellement une mauvaise entrée dans une application, ce

qui l'amène à générer des erreurs de base de données.

L’idée est d’obtenir plus d’informations sur la structure de la base de données,

des tables et des colonnes que l’application Web suit, à travers les messages
d’erreur.

Sur cette base, l'attaquant injecte alors des requêtes SQL spécifiquement conçues
pour compromettre la sécurité des données de l'application cible.

17
Types d’injection SQL
Blind SQL injection (1)

L’injection SQL aveugle est utilisée lorsqu'une application Web est vulnérable à une
injection SQL, mais que les résultats de l'injection ne sont pas visibles pour l'attaquant.

C'est par exemple le cas pour tous les scripts à réponse binaire, comme les formulaires
d'authentification: soit l'authentification a réussie, soit elle a échouée, mais dans
tous les cas, aucune donnée de la base n'est affichée sur la page.

● Injection aveugle booléenne : dans cette forme d’injection SQL, l’attaquant envoie
diverses requêtes à la base de données pour analyser comment l’application évalue
ces requêtes. Comme cette technique hasardeuse s'appuie sur des essais
successifs, elle est souvent automatisée par des scripts.

18
Types d’injection SQL
Blind SQL injection (2)

● Injection aveugle basée sur le temps : l’attaquant utilise une fonction temporelle
prédéfinie du système de gestion de base de données utilisé par l’application pour
retarder les résultats des requêtes.

Par exemple, dans MySQL, la fonction sleep() indique à la base de données

d’attendre un certain nombre de secondes. L'attaquant peut voir à partir du
temps que la base de données met pour répondre, si une requête est vraie ou fausse.

Exemple :

SELECT identifiant, username FROM users WHERE identifiant = -1 OR (SELECT

SLEEP(3) FROM users WHERE identifiant = 1 AND motdepasse LIKE 0x6125) ;

19
Contre-mesures

● Échapper les caractères spéciaux contenus dans les inputs de l'utilisateur.

● Vérifier de manière précise et exhaustive l'ensemble des données de l'utilisateur.

● Configurer le report d'erreur pour qu'il soit le moins verbeux possible.

● Minimiser les privilèges attribués à chaque compte de base de données.

● Paramétrer les requêtes au lieu d'y intégrer directement la saisie de l'utilisateur.

20
Qu’est-ce qu’une session ?

Une session est est une série d'interactions entre deux entités communicantes qui
se produit pendant la durée d'une seule connexion.
Lorsqu'un client se connecte à une application, une session est créée sur le serveur
afin de maintenir l'état des autres requêtes provenant du même client.
La session est maintenue active sur le serveur tant que l'utilisateur est connecté
au système. Elle est détruite lorsque l'utilisateur se déconnecte du système ou
après une période d'inactivité prédéfinie.
Un ID de session est une chaîne d'identification qui est transmise entre le client et le
serveur. Les ID de session sont généralement stockés dans des cookies, des URL et
des champs cachés de pages Web.

21
Cross-Site Scripting (1)

Une attaque Cross-Site Scripting, ou XSS, est une attaque par injection qui permet à
un attaquant de compromettre les interactions des utilisateurs avec une application
vulnérable.

Elle se produit lorsqu'un attaquant utilise une application Web pour envoyer un code
malveillant, généralement sous la forme d'un script côté navigateur, à un autre
utilisateur final.

Un attaquant qui exploite une vulnérabilité XSS sera généralement capable de se faire
passer pour l'utilisateur victime, réaliser toute action que l'utilisateur est capable
d'effectuer, lire toutes les données auxquelles l'utilisateur peut accéder, diffuser un
malware, etc.

22
Cross-Site Scripting (2)
Les attaques XSS peuvent se produire lorsque :

1. Des données pénètrent dans une application Web via une source non fiable, le plus
souvent une requête Web.
2. Des données sont incluses dans un contenu dynamique envoyé au navigateur Web
d'un utilisateur sans être validées.

Le contenu malveillant envoyé au navigateur Web prend souvent la forme d'un

code JavaScript, mais peut également inclure du code HTML, Flash ou tout autre type
de code que le navigateur peut exécuter.

Ce script malveillant peut accéder aux cookies de l’utilisateur, voler le jeton de session
ou d’autres informations sensibles conservées par le navigateur et utilisées avec ce site.

23
Exemple de scénario

● L'attaquant crée un e-mail avec un script malveillant et l'envoie à la victime :

<A HREF=http://bank.com/registration.cgi?clientprofile=<script>code
malveillant</script>>Cliquez ici</A >

● Lorsque l'utilisateur clique sur le lien, l'URL est envoyée au serveur hébergeant
le site Web bank.com avec le code malveillant.

● Le serveur renvoie une page à l'utilisateur, y compris la valeur de clientprofile, et

le code malveillant est exécuté sur la machine cliente.

24
Types d’attaque XSS
● Reflected XSS : elle représente l’attaque XSS la plus courante. La charge utile XSS
de l’attaquant fait partie de la demande envoyée au serveur Web. Elle est ensuite
renvoyée de manière à ce que la réponse HTTP inclut la charge utile de la demande.

● Stored XSS : aussi connu sous le nom de XSS persistant, elle est considérée
comme l’attaque XSS la plus dévastatrice. Le script injecté est stocké en
permanence sur le serveur cible. Les points d'entrée sont généralement des
messages sur les forums, des commentaires sur des blogs, etc.

● DOM XSS : la charge utile de l'attaque est exécutée à la suite de la modification de

l'environnement DOM dans le navigateur de la victime, de sorte que le code côté
client s'exécute de manière inattendue.

25
Contre-mesures

● Filtrer aussi strictement que possible les inputs des utilisateurs au moment où ils
sont reçus en fonction en fonction de l'entrée attendue ou valide.

● Encoder les données en sortie pour éviter qu'elle ne soit interprétée comme un
contenu actif, lorsque les données contrôlables par l'utilisateur sont incluses
dans les réponses HTTP.

● Utiliser les en-têtes de réponse appropriés pour empêcher les failles XSS dans les
réponses HTTP qui ne sont pas destinées à contenir du HTML ou du JavaScript.

● Utiliser une politique de sécurité du contenu pour réduire la gravité des vulnérabilités
XSS qui se produisent encore.

26
Cross-Site Request Forgery

Une attaque Cross-Site Request Forgery, ou CSRF, est une attaque qui oblige un
utilisateur final à exécuter des actions indésirables sur une application Web à laquelle il
est actuellement authentifié.

Ces attaques sont généralement menées à l'aide de l’ingénierie sociale, comme un

e-mail ou un lien qui incite la victime à envoyer une requête falsifiée à un serveur.

Comme l'utilisateur peu méfiant est authentifié par l’application au moment de

l'attaque, il est impossible de distinguer une requête légitime d'une requête falsifiée.

Si l'utilisateur compromis a un rôle privilégié au sein de l'application, l'attaquant peut

être en mesure de prendre le contrôle total de toutes les données et fonctionnalités de
l'application.

27
Exemple de scénario (1)

Alice souhaite transférer 5000 DA à Bob en utilisant l'application Web bank.com qui est
vulnérable au CSRF. Eve, une attaquante, veut inciter Alice à lui envoyer l'argent à la
place. L'attaque comprendra les étapes suivantes :

1. L’attaquant étudie l’application cible afin de faire apparaître une requête falsifiée
aussi légitime que possible.
2. Inciter Alice à exécuter l'action avec l'ingénierie sociale.

Par exemple, une requête GET typique pour un virement bancaire de 5000 DA pourrait
ressembler à :

GET http://bank.com/transfer.do?acct=Bob&amount=$5000 HTTP/1.1

28
Exemple de scénario (2)

Eve peut modifier l’URL afin d’entraîner un transfert de 5000 DA sur son propre compte.
Maintenant, la requête malveillante pourrait ressembler à :

GET http://bank.com/transfer.do?acct=Eve&amount=$5000 HTTP/1.1

Elle peut ensuite intégrer cette requête dans un lien hypertexte innocent :

<a href="http://bank.com/transfer.do?acct=Eve&amount=$5000">En savoir plus !</a>

Eve peut alors envoyer le lien hypertexte par e-mail à Alice ou le diffuser à un grand
nombre de clients de la banque. Ceux qui cliquent sur le lien alors qu'ils sont connectés
à leur compte bancaire lanceront involontairement le transfert de 5000 DA.

29
Exemple de scénario (3)
Si l’application Web de la banque n'utilise que des requêtes POST, il est impossible de
livrer des requêtes malveillantes à l'aide de balises standard <a>. Cependant, l'attaque
pourrait être livrée dans une balise <form> avec exécution automatique du JavaScript
intégré.

<body onload="document.forms[0].submit()">
<form action="http://bank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="Eve"/>
<input type="hidden" name="amount" value="$5000"/>
<input type="submit" value="En savoir plus !"/>
</form>
</body>

30
Autres utilisations malveillantes

● Utiliser un système de gestion de contenu pour ajouter/supprimer du contenu

sur un site Web. Si la victime est l'administrateur d'un site Web, l'attaquant
prend alors le contrôle de l'intégralité du site.

● Modifier le mot de passe d'un utilisateur. Si la victime est connectée à son

compte, l'attaquant peut simplement falsifier une demande de modification
de son e-mail. Après cela, il peut falsifier une demande de réinitialisation du
mot de passe et prendre le contrôle total du compte de la victime.

● Ajouter des articles au panier d'un utilisateur ou modifier l'adresse de livraison

d'une commande. Sur le site Web, la victime apparaît comme l'auteur de ces
modifications.

31
Contre-mesures

Pour les utilisateurs

● Se déconnecter des applications Web lorsqu'elles ne sont pas utilisées.

● Sécuriser les noms d'utilisateur et les mots de passe.
● Ne pas autoriser les navigateurs à se souvenir des mots de passe.
● Éviter de naviguer simultanément tout en étant connecté à une application.

Pour les applications

Générer des jetons aléatoires uniques (tokens) pour chaque demande de session ou ID
et l’insérer dans la requête HTTP. Les requêtes ayant des jetons en double ou des
valeurs manquantes sont rejetées.

32
File Upload vulnerabilities (1)
Les vulnérabilités de téléchargement de fichiers surviennent lorsqu'un serveur Web
permet aux utilisateurs de télécharger des fichiers sur son système de fichiers sans
valider des éléments tels que leur nom, leur type, leur contenu ou leur taille.

Si une application Web n’applique pas des restrictions sur ces éléments, cela pourrait
signifier que même une fonction de téléchargement d'image de base peut être
utilisée pour télécharger des fichiers arbitraires et potentiellement dangereux à
la place. Cela pourrait même inclure des fichiers de script côté serveur qui permettent
l'exécution de code à distance.

Dans certains cas, le fait de télécharger le fichier est en soi suffisant pour causer des
dommages.

33
File Upload vulnerabilities (2)

L'impact des vulnérabilités de téléchargement de fichiers dépend généralement de

deux facteurs clés :

● Quel aspect du fichier l’application Web ne parvient pas à valider correctement.

● Quelles restrictions sont imposées au fichier une fois qu'il a été téléchargé.

Dans le pire des cas, le type de fichier n'est pas validé correctement et la
configuration du serveur permet à certains types de fichiers d'être exécutés en
tant que code.

Un attaquant pourrait alors potentiellement télécharger un fichier de code côté serveur

qui fonctionne comme un shell Web, lui accordant ainsi un contrôle total sur le serveur.

34
File Upload vulnerabilities (3)

Si le nom de fichier n'est pas validé correctement, cela pourrait permettre à un

attaquant d'écraser des fichiers critiques simplement en téléchargeant un fichier
portant le même nom.

Ne pas s'assurer que la taille du fichier soit dans les seuils attendus pourrait
permettre une forme d'attaque par déni de service, par laquelle l'attaquant
remplit l'espace disque disponible.

35
Contre-mesures
● Vérifier l'extension de fichier par rapport à une liste blanche d'extensions autorisées
plutôt qu'à une liste noire d'extensions interdites.

● S’assurer que le nom de fichier ne contient aucune sous-chaîne pouvant être

interprétée comme un répertoire ou une séquence de parcours (../).

● Renommer les fichiers téléchargés pour éviter les collisions qui pourraient
entraîner l'écrasement des fichiers existants.

● Ne pas télécharger de fichiers sur le système de fichiers permanent du serveur tant

qu'ils n'ont pas été entièrement validés.

● Utiliser un framework établi pour le prétraitement des téléchargements de fichier

plutôt que d'essayer d'écrire ses propres mécanismes de validation.

36