Administration et Sécurité du

Web
Dr Beman KAMAGATE
[Link]@[Link]

1
PARTIE I : SECURITE DU WEB

I- Notion de base de la sécurité

Les besoins de sécurité
Notions de vulnérabilité, menace, attaque
Panorama de quelques menaces
II- Sécurité du web
Introduction
Comprendre le problème
Les mythes de sécurité du web
Principe des attaques
OWASP Top -10 best practices /WASC
Injection de code
Violation d’authentification et de session
Cross -Site scripting XSS
Référencement
Exposition de données sensibles
Manque de contrôles d’acces au niveau fonctionnel
Falsification de requête intersite (CSRF)
2
Les besoins de sécurité

a. Introduction aux critères DIC

• Comment définir le niveau de sécurité d’un bien du S.I. ? Comment évaluer si ce bien
est correctement sécurisé ?

• 3 critères sont retenus pour répondre à cette problématique, connus sous le nom de
D.I.C.
Disponibilité
Propriété d'accessibilité au moment voulu
des biens par les personnes autorisées (i.e. le bien
doit être disponible durant les plages d’utilisation prévues)

Bien à
protéger
Intégrité
Propriété d'exactitude et de complétude des biens
et informations (i.e. une modification illégitime
d’un bien doit pouvoir être détectée et corrigée)

Confidentialité
Propriété des biens de n'être accessibles
qu'aux personnes autorisées

04/03/2020 Sensibilisation et initiation à la cybersécurité 3

Les besoins de sécurité

b. Besoin de sécurité : « Preuve »

• Comment définir le niveau de sécurité d’un bien du S.I. ? Comment

évaluer si ce bien est correctement sécurisé ?

• 1 critère complémentaire est souvent associé au D.I.C.

Preuve
Propriété d'un bien permettant de retrouver, avec
une confiance suffisante, les circonstances dans
Bien à lesquelles ce bien évolue. Cette propriété englobe
protéger Notamment :
La traçabilité des actions menées
L’authentification des utilisateurs
L’imputabilité du responsable de l’action effectuée

04/03/2020 Sensibilisation et initiation à la cybersécurité

Les besoins de sécurité

c. Exemple d’évaluation DICP

Ainsi, pour évaluer si un bien est correctement sécurisé, il faut auditer son niveau de
Disponibilité, Intégrité, Confidentialité et de Preuve. L’évaluation de ces critères sur une
échelle permet de déterminer si ce bien est correctement sécurisé.

L’expression du besoin attendu peut-être d’origine :

• Interne : inhérente au métier de l’entreprise
• ou externe : issue des contraintes légales qui pèsent sur les biens de l’entreprise.

Exemple des résultats d’un audit sur un bien sur une échelle (Faible, Moyen, Fort, Très
fort) :

Niveau de Disponibilité du bien Très fort

Niveau d’Intégrité du bien Moyen
Niveau de Confidentialité du bien Très fort
Niveau de Preuve du bien Faible

Le bien bénéficie d’un niveau de sécurité adéquat

04/03/2020 Sensibilisation et initiation à la cybersécurité
Les besoins de sécurité

d. Exemple d’évaluation DICP

• Tous les biens d’un S.I. n’ont pas nécessairement besoin d’atteindre les mêmes niveaux de DICP.
• Exemple avec un site institutionnel simple (statique) d’une entreprise qui souhaite promouvoir ses
services sur internet :

Disponibilité = Très fort Confidentialité = Faible

Un haut niveau de disponibilité du site Un faible niveau de confidentialité
web est nécessaire, sans quoi suffit. En effet, les informations
l’entreprise ne peut atteindre son contenues dans ce site web sont
objectif de faire connaitre ses services publiques par nature!
au public

Intégrité = Très fort Serveur Preuve = Faible

Un haut niveau d’intégrité des
informations présentées est
web Un faible niveau de preuve suffit.
nécessaire. En effet, l’entreprise ne En effet, ce site web ne permet
souhaiterait pas qu’un concurrent aucune interaction avec les
modifie frauduleusement le contenu du utilisateurs, il fournit simplement
site web pour y insérer des des informations fixes.
informations erronées (ce qui serait
dommageable)
04/03/2020 Sensibilisation et initiation à la cybersécurité
Les besoins de sécurité

e. Mécanismes de sécurité pour atteindre les besoins DICP

Un Système d’Information a besoin de mécanismes de sécurité qui ont pour objectif d’assurer de
garantir les propriétés DICP sur les biens de ce S.I. Voici quelques exemples de mécanismes de
sécurité participant à cette garantie :
D I C P
Mécanisme technique permettant de détecter toute attaque
Anti-virus virale qui a déjà été identifiée par la communauté sécurité ✓ ✓ ✓

Mécanisme permettant d’implémenter du chiffrement et des

Cryptographie signatures électroniques ✓ ✓ ✓
Équipement permettant d’isoler des zones réseaux entre-elles
Pare-feu et de n’autoriser le passage que de certains flux seulement ✓ ✓

Mécanismes permettant de restreindre l’accès en

Contrôles d’accès lecture/écriture/suppression aux ressources aux seules ✓ ✓ ✓
logiques personnes dument habilitées

Sécurité physique des Mécanismes de protection destinés à protéger l’intégrité

physique du matériel et des bâtiments/bureaux.
✓ ✓ ✓
équipements et locaux
04/03/2020 Sensibilisation et initiation à la cybersécurité
 Les besoins de sécurité

e. Mécanismes de sécurité pour atteindre les besoins DICP

D I C P
Mécanismes organisationnels destinés à s’assurer de l’efficacité
Capacité d’audit et de la pertinence des mesures mises en œuvre. Participe à ✓ ✓ ✓ ✓
l’amélioration continue de la sécurité du S.I.

Mécanismes organisationnels destinés à s’assurer que les

Clauses contractuelles partenaires et prestataires mettent en œuvre les mesures
avec les partenaires nécessaires pour ne pas impacter la sécurité des S.I. de leurs ✓ ✓ ✓ ✓
clients

Mécanismes organisationnels dont l’objectif est d’expliquer aux

utilisateurs, administrateurs, techniciens, PDG, clients, grand
Formation et public, etc. en quoi leurs actions affectent la sécurité des S.I.
sensibilisation Diffusion des bonnes pratiques de sécurité. ✓ ✓ ✓ ✓
Le cours actuel en est une illustration !

Certains de ces mécanismes seront présentés dans le cadre cette

sensibilisation à la cybersécurité

04/03/2020 Sensibilisation et initiation à la cybersécurité

Notions de vulnérabilité, menace, attaque

a. Notion de « Vulnérabilité »

• Vulnérabilité
• Faiblesse au niveau d’un bien (au niveau de la conception, de la
réalisation, de l’installation, de la configuration ou de l’utilisation du
bien).

Vulnérabilités

04/03/2020 Sensibilisation et initiation à la cybersécurité

Notions de vulnérabilité, menace, attaque

b. Notion de « Menace »

• Menace
• Cause potentielle d’un incident, qui pourrait entrainer des dommages sur
un bien si cette menace se concrétisait.

Personnes extérieures malveillantes

Stagiaire
malintentionné

Perte de service

Menaces
Code malveillant
04/03/2020 Sensibilisation et initiation à la cybersécurité
Notions de vulnérabilité, menace, attaque

c. Notion d’« Attaque »

• Attaque
• Action malveillante destinée à porter atteinte à la sécurité d’un bien. Une
attaque représente la concrétisation d’une menace, et nécessite
l’exploitation d’une vulnérabilité.

Attaques

04/03/2020 Sensibilisation et initiation à la cybersécurité

Notions de vulnérabilité, menace, attaque

c. Notion d’« Attaque »

• Attaque
• Une attaque ne peut donc avoir lieu (et réussir)
que si le bien est affecté par une vulnérabilité.

Ainsi, tout le travail des experts sécurité consiste à s’assurer que le

S.I. ne possède aucune vulnérabilité.
Dans la réalité, l’objectif est en fait d’être en mesure de maitriser ces
vulnérabilités plutôt que de viser un objectif 0 inatteignable.

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

a. Sources potentielles de menaces

capacité

Etat
tiers

Groupe de Capacité
cybercriminels degré d’expertise et ressources
de la source de menaces

Concurrents
Exposition
opportunités et intérêts de la
Personnel
source de menaces
interne
Cyber-
délinquant

exposition
Exemple d’une cartographie des principales sources de menaces
qui pèsent sur un S.I.
Attention : cette cartographie doit être individualisée à chaque organisation car toutes les
organisations ne font pas face aux mêmes menaces.
Exemple : le S.I. d’une administration d’état ne fait pas face aux mêmes menaces que le S.I. d’un e-commerce ou d’une université

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces
b. Panorama de quelques menaces

Hameçonnage & Violation d’accès

Fraude interne
ingénierie sociale non autorisé

Déni de service
Virus informatique
distribué

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

c. Hameçonnage & ingénierie sociale

L’hameçonnage (anglais : « phishing ») constitue une « attaque de masse » qui vise à abuser de la
« naïveté » des clients ou des employés pour récupérer leurs identifiants de banque en ligne ou leurs
numéros de carte bancaire…

1 Réception d’un mail utilisant le logo et les

couleurs de l’entreprise

2 Demande pour effectuer une opération

comme la mise-à-jour des données
personnelles ou la confirmation du mot
de passe

3 Connexion à un faux-site identique à

celui de l’entreprise et contrôlé par
l’attaquant

4 Récupération par l’attaquant des

identifiants/mots de passe (ou tout autre
donnée sensible) saisie par le client sur
le faux site

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces
c. Hameçonnage & ingénierie sociale

L’ « ingénierie sociale » constitue une « attaque ciblée » qui vise à abuser de la

« naïveté » des employés de l’entreprise :
• pour dérober directement des informations confidentielle, ou
• pour introduire des logiciels malveillants dans le système d’information de la
banque

par téléphone par réseaux par e-mail

sociaux

les scénarios d’ingénierie sociale sont illimités, avec pour seules limites
l’imagination des attaquants et la naïveté des victimes…

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

c. Hameçonnage & ingénierie sociale

Exemple de phishing ciblant les employés d’un grand groupe français…

Ce lien pointe en fait vers un site frauduleux, et non

pas vers un serveur légitime de l’entreprise

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

d. Déroulement d’une attaque avancée

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces
d. Déroulement d’une attaque avancée

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

d. Déroulement d’une attaque avancée

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces
d. Déroulement d’une attaque avancée (Exemple)

• Apple indique que :

– Ses services iCloud ou FindMyPhone
n’ont pas été compromis
– les comptes iCloud des stars
concernées ont été compromis par des
attaques ciblées de :
• compte utilisateur
• mot de passe
• questions de sécurité
• Le nombre de tentatives de mots de
Des photos intimes d’acteurs, chanteurs, présentateurs passe avant verrouillage du compte
célèbres stockées sur iCloud d’Apple ont été diffusées en
ligne.
était trop élevé.
Les célébrités incluaient Jennifer Lawrence, Kate Upton, – permettant des attaques par « brute
Rihanna, Kim Kadarshian, Selena Gomez entre autres. force »
• Il semblerait que l’attaque soit de type
« social engineering ».
– permettant de répondre aux questions
de sécurité.

[Link]

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

e. Fraude interne

La fraude interne est un « sujet tabou » pour les entreprises, mais un

véritable sujet d’importance !
Catégories de fraudeurs Vulnérabilités Typologies des fraudes

• Fraudeur occasionnel • Faiblesse des procédures • Le détournement des

de contrôle interne et de avoirs de la clientèle
• Fraudeur récurrent (petites
surveillance des opérations
sommes de manière • Le détournement des
régulière) • Gestion permissive des avoirs de l’entreprise
habilitations informatiques
• Personne qui se fait • La création de fausses
embaucher pour effectuer • Absence de séparation des opérations
une fraude tâches et de rotation • La personne qui fausse
• Fraude en groupe ses objectifs pour
augmenter sa
rémunération

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

f. Violation d’accès non autorisé : mots de passe faibles

Des mots de passe simples ou faibles (notamment sans caractères spéciaux comme
« ! » ou « _ » et des chiffres) permettent – entre autre – à des attaquants de mener les
actions suivantes :
• Utiliser des scripts automatiques pour tester un login avec tous les mots de passe
couramment utilisés (issus d’un dictionnaire) ;
• Utiliser des outils pour tenter de « casser » le mot de passe. Ces outils sont très
efficaces dans le cadre de mots de passe simples, et sont beaucoup moins efficaces
dans le cas de mots de passe longs et complexes.

Réflexion sur l’utilisation des mots de passe : les mots de passe constituent une faiblesse
significative pour la cybersécurité. En effet, les êtres humains n’ont pas la capacité de
mémoriser de nombreux mots de passe, complexes, différents pour chaque
application, etc.
Pour cette raison, d’autres moyens d’authentification émergent, de façon à libérer les
individus des problématiques des mots de passe. Quelques exemples : la biométrie,
les tokens USB, les matrices papier, la vérification via un code SMS, les « one time
password », etc.

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

f. Violation d’accès non autorisé : intrusion

Les intrusions informatiques constituent des « attaques ciblées » qui exploitent une ou des
vulnérabilité(s) technique(s) pour dérober des informations confidentielles (ex. : mots de passe, carte
bancaire…) ou prendre le contrôle des serveurs ou postes de travail
Depuis le réseau Internet sur les ressources exposées : sites institutionnels, services de e-commerce, services
d’accès distant, service de messagerie, etc.
Depuis le réseau interne sur l’Active Directory ou les applications sensibles internes

Quelques chiffres issus de tests d’intrusion menés sur de nombreux S.I. :

80% des domaines Active Directory sont compromis

en 2 heures

75% des domaines Active Directory contiennent au moins 1

compte privilégié avec un mot de passe trivial

50% des entreprises sont affectées par un défaut de

cloisonnement de ses réseaux

des tests d’intrusion ne sont pas détectés par les

80% équipes IT
Sources : tests d’intrusion Orange Consulting 2012-2013

Active Directory : est un système d’annuaire sous Windows répertoriant les ressources du réseau notamment les sites, les
machines, les utilisateurs.
04/03/2020 Sensibilisation et initiation à la cybersécurité
Panorama de quelques menaces

g. Virus informatique
Les virus informatiques constituent des « attaques massives » qui tendent…
• à devenir de plus en plus ciblés sur un secteur d’activité (télécommunication, banque, défense, énergie, etc.)
• à devenir de plus en plus sophistiqués et furtifs

Les principaux vecteurs d’infection…

• Message avec pièce-jointe
• Support amovible (clé USB…)
• Site Web malveillant ou piratés
• Partages réseaux ouverts, systèmes vulnérables…

… avec comme conséquences potentielles …

• Installation d’un « cheval de Troie » pour accéder au poste de
travail à distance
• Récupération de données ciblées : cartes bancaires,
identifiants/mots de passe…
• Surveillance à distance des activités : capture des écrans, des
échanges, du son ou de la vidéo !
Quelques virus récents et • Destruction des données des postes de travail
médiatiques : Citadel, Flame, • Chiffrement des données pour une demande de rançon
Stuxnet, Duqu, Conficker, Zeus, • …
Shamoon (Aramco)…

04/03/2020 Sensibilisation et initiation à la cybersécurité

Panorama de quelques menaces

h. Déni de service distribué (DDoS)

La déni de service distribué (DDoS) constituent une « attaque ciblée » qui consiste à saturer un site
Web de requêtes pour le mettre « hors-service » à l’aide de « botnets », réseaux d’ordinateurs
infectés et contrôlés par les attaquants

… une menace majeure et en augmentation

pour les sites Internet

34,5 heures
durée moyenne d’une attaque

48,25 Gbps
bande passante moyenne d’une attaque

75 % des attaques au niveau infrastructure

25% des attaques au niveau application

04/03/2020 Sensibilisation et initiation à la cybersécurité

 Panorama de quelques menaces

i. Illustration d’un réseau de botnets

Cible de l’attaque

Milliers ou millions
d’ordinateurs infectés,
prêts à attaquer une cible
sur ordre de l’attaquant

Serveurs de
commande
(relais)
Un botnet est un ensemble de systèmes
contrôlables par un attaquant via des serveurs
de commande. Les propriétaires de ces
systèmes ne savent pas que leur PC participe à
un botnet (leur PC a été compromis au préalable
et à leur insu via l’exploitation d’une vulnérabilité)
Attaquant contrôlant le botnet

04/03/2020 Sensibilisation et initiation à la cybersécurité

 Chapitr
e IV :
écurité des Applications Web
 Introduction
• Site web vs Application Web:
– Aucune définition précise
• Site Web :
– Permet l’accès à des documents statiques.
– Aucun « input » qui affecte les fonctionnalités du site.
• Application Web
– Développée autour d’un serveur Web.
– Prend des « inputs» de l’utilisateur qui affectent le «backend
business».
– Le serveur Web interagit avec un serveur d’application ou un serveur
de BD.

2
Fonctionnement de l’application Web
• Comprendre le problème

3
 Le mythe « notre site est sécurisé » ?
• « Nous utilisons des gestionnaires de vulnérabilités réseau ».
– Cette approche néglige la sécurité logicielle dans le réseau ou
celle du serveur Web.

• « Nous utilisons un Firewall »

– Les ports 80 et 443 sont ouverts

• « Les données sont cryptées avec SSL ».

– Ceci protège les données entre l’utilisateur et le site, pas
l’application Web.

4
 Ce qui peut arriver

• Affichage/fuites des données sensibles

• Vol des identités des comptes utilisateurs
• Accès illégal à des applications
• Exécution illégale de code arbitraire sur le serveur
• Modification du contenu
• Arrêt de l’application Web
• Prise de contrôle de l’application Web

• La réalité : 2/3 des applications Web présentent des vulnérabilités.

5
 Statistiques des applications Web
septembre 2014

6
 Principe des attaques
• Les attaques s’appuient généralement sur l’injection
des fautes:
– Une techniques permettant d’exploiter les vulnérabilités
de la syntaxe sémantique d’une application Web

• Les vulnérabilités de sécurité au sein d’une

application Web sont liées à:
– Des erreurs de programmation avec le langage de
l’application web ( exemple :.NET, PHP, Python, JSP, CGI…)

7
 Référencement des documents

[Link]

Le protocole
Le N° du port Tout ce qui
après le « ? »
Le nom de hôte est la partie
Chemin d’accès au document requête de
l’URL

8
 Exemples d’attaques

9
 OWASP top 10 – best practice
• OWASP: Open Web Application Security Project : est une communauté
publique open source, formée en 2001.

• Un ensemble de projets pour l’amélioration de la sécurité applicative.

• OWASP maintient le OWASP top 10, une liste qui identifie les rsiques les
plus critiques de la sécurité applicative.

• Depuis 2004 une nouvelle liste est arêtée tout les 3 ans.

• La liste est considérée comme la meilleure pratique (best practice)

industrielle pour la prévention des vulnérabilités des applications web et
elle est référencée par la plupart des organisations de sécurité comme PCI
DSS, FTC, MITRE, …

10
 OWASP top 10 – best practice

11
 WASC
• Web Application Security Consortiums
– Leurs objectifs est de développer et d’adopter des standards
pour la sécurité des applications Web.

• Site web officiel : [Link]

• Web Security Threat Classification project:

– Classement des vulnérabilités en 6 catégories.
– Clarifier et organiser les menaces de sécurité des applications Web
– [Link]

12
 WASC

13
 1. Injection de code
Une faille d'injection, telle l'injection SQL, OS et LDAP, 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.

• L’exemple le plus courant de l’attaque d’injection est l’injection SQL.

• L’injection SQL permet à un attaquant d’exécuter des commandes
SQL dans un champ de saisie.
• L’attaquant est capable de retourner et de voler des informations
sur les tables, changer des lignes, ou même supprimer le contenu
de la base

14
 1. Injection de code
• Quelles sont les conséquences:
– Fuite d’informations par le biais des messages d’erreurs du
SGBD.
– Echapper une séquence d’authentification
– Extraction des données à partir de la base.
– Prendre le contrôle complet sur la BD (insertion de
données, suppression des tables, etc.)
– Exécuter des commandes sur le système.
– Compromettre le système.

15
 1. Injection de code
• Principes d’injection SQL:
– Techniques de détection: découvrir comment l’application
interagit avec le serveur BD
• Souvent ajouter une simple quotte (') ou un point-virgule
(;) au champ ou paramètre à tester
• Les délimiteurs de commentaires (-- ou /* */, etc) et
d'autres mots clefs SQL comme 'AND' et 'OR‘.
• Analyser les erreurs retournées par l’application
– Exemple :
SELECT id FROM users WHERE username =‘test123’ and password =‘xxxxxxx’

SELECT id FROM users WHERE username =‘test123’ or 1=1-- and password =‘xxxxxxx’

16
 1. Injection de code
• Principes :
– Techniques d’exploitation: différentes techniques
• Par union: L'opérateur UNION est utilisé dans les injections SQL
pour joindre une requête.
• Booléenne: les opérateurs AND et OR.
• Basée sur les erreurs : forcer la BD à générer des erreurs
• Out-of-band: La technique consiste à utiliser des fonctions du
SGBD pour ouvrir une connexion séparée
• Par délai: mesurer les délai de la réponse du SGBD.
• Injection de procédure stockée
• Exploitation automatisée: SQLMap par exemple
– [Link]
(OTG-INPVAL-005)

17
 1. Injection de code
• Solutions:
– Validation des toutes les entrées : utiliser « white list » qui
accepte les bonnes valeurs. Taille, type,..
– Utilisation des API saines évitant toute utilisation de
l’interpréteur.
– Sinon, rejet des entrées contenant des données binaires, des
séquences de caractères d'échappement et des caractères de
commentaire.
– Utilisation des procédures stockées pour valider les entrées.
– Paramétrer les messages d’erreurs.
– Appliquer le moindre privilège de connexion à la BD.
– ….
18
 2. Violation de Gestion
d’Authentification et de Session

Les fonctions applicatives relatives à l'authentification et la

gestion de session ne sont souvent pas mises en œuvre
correctement, permettant 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.

19
 2. Violation de Gestion
d’Authentification et de Session
• Description:
– Faiblesse des fonctions de gestion de compte (ex: création de
compte, changement de mot de passe, récupération de mot de
passe, IDs de session faibles) permettant de deviner ou
d’écraser les credentials.
– Exposition des IDs de session dans l'URL. (Session hijacking)
– Vulnérabilité des IDs de session à l’attaque par fixation.
– Pas de timeout des IDs de session ou mauvaise désactivation
des sessions ou jetons d’authentification
– Non rotation des IDs de session après connexion réussie
– Les mots de passe, IDs de session et autres credentials
transitent par des canaux non chiffrés
20
 2. Violation de Gestion
d’Authentification et de Session
• Solutions
– Mécanismes pour sécuriser les mots de passe
• choisir des mots de passe forts et complexes.
• Protection et stockage des mots de passe : chiffrement
• En cas de changement des mots de passe: ils doivent saisir l’ancien
et le nouveau, validation par e-mail,..
– Mécanismes sécurisés pour la gestion des IDs de session:
• Combiner l’@IP soure avec l’ID de session
• Chaque login génère un nouvel unique ID de session.
• Forcer la ré-authentification termine le session hijacking
• Terminer la session après un time out d’inactivité.
• L’ID de session doit être long ,compliqué, aléatoire,..
• L’ID de session doit être protéger par SSL

21
 3. Cross-Site Scripting (XSS)

Les failles XSS se produisent chaque fois qu'une application

accepte des données non fiables et les envoie à un browser 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.

22
 3. Cross-Site Scripting (XSS)

• Implications
– Vol des cookies du domaine navigué
– Modifie complètement le contenu de n’importe quelle page
que vous voyez dans le domaine
– Redirige l’accès vers un site de phishing
– Exploite les vulnérabilités du browser pour prendre le
contrôle de la machine de la victime.

23
 3. Cross-Site Scripting (XSS)

24
 3. Cross-Site Scripting (XSS)

• Solutions
– L’option à privilégier est d’échapper toute donnée non fiable
selon le contexte HTML dans lequel elle sera insérée.
– 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.
– Considérez Content Security Policy (CSP) pour se protéger
des attaques XSS sur l’ensemble de votre site
– [Link]
evention_Cheat_Sheet

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

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.

26
 4. Références directes non
sécurisées à un objet
• Implications
– Une partie du ou tous les noms de ressources (fichiers, table, …) contrôlées
par l’entrée utilisateur.
– Changer un ID dans l’URL pour accéder à un autre compte.
• Solutions
– Eviter d’exposer les références aux objets (clés primaires, nom
de fichiers,…)
– Valider toutes les références aux objets.
– Vérifier toujours l’autorisation aux objets référencés.
– Utiliser le modèle de sécurité positives pour accepter
uniquement les bonnes références aux objets.

27
 5. Mauvaise configuration de
Sécurité

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

28
 5. Mauvaise configuration de
Sécurité
• Implications:
– Mise à jour des logiciels ? OS, Web/App Serveur, l’ensemble des librairies de
code,…
– Des fonctions inutiles activées (ex:ports, services, pages, comptes, privilèges,..
– Des mots de passe par défauts.
– La configuration des frameworks de développement (Spring, [Link], …) ne
sont pas configurés aves des valeurs sécurisées.
– Le Listage des répertoires est activés.
• Solutions
– Utiliser des scans et les audits pour détecter les mauvaises
configuration.
– Déployer les nouvelles versions et des correctifs de sécurité.
– Ne pas afficher les messages d’erreurs et les exceptions dans un
environnement de production
29
6. Exposition de données sensibles

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.

30
 6. Exposition de données sensibles
• Implications :
– Données stockées/archivées en clair
– Données circulent en clair.
– Algorithmes cryptographiques et clés faibles et non robuste, la gestion
des clés.
– Composants de l’application web identifiés accessibles via HTTP et HTTPS.
• Solutions
– 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.
– Ne pas conserver que les données sensibles cryptés avec des
algorithmes forts bycrypt, PBKDF2, scrypt.

31
 7. Manque de contrôle d’accès au
niveau fonctionnel

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.

32
 7. Manque de contrôle d’accès au
niveau fonctionnel
• Implications :
– L’interface utilisateur permet de naviguer vers des focntionnalités accès
restreint.
– Certaines vérifications côté serveur (authentification et autorisation) sont
manquantes.
• Solutions
– Faites en sorte que la gestion des droits soit facile à mettre à jour
et à auditer.
– La gestion des droits doit par défaut interdire tout accès . Ceci
impose l’autorisation explicite de certains rôles pour chacune des
fonctionnalités proposées.
– Si la fonctionnalité fait partie d’un Workflow, vérifier que les
conditions requises pour accéder cet état sont réunies.
33
8. Falsification de requête intersite
(CSRF)

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.

34
 8. Falsification de requête intersite
(CSRF)
• Implications :
– CSRF exploite le fait que la plupart des applications web permettent aux
attaquants de prévoir les détails de certaines actions.
– L’attaquant conçoit des pages web malicieuses, qui génèrent des requêtes
spécialement forgées, qui paraissent ainsi légitimes.
– L’attaquant force la victime à réaliser n’importe quelle opération.
• Solutions
– S’assurer que l’utilisateur est l’auteur de la requête, soit par la ré-
authentification, soit par la vérification que la demande n’est pas
automatisée.
– La meilleure option est d’inclure un jeton unique dans un champ caché.
Ce jeton, envoyé dans le corps de la requête HTTP, et non inséré à 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.
35
 8. Falsification de requête intersite
(CSRF)
1)

36
 8. Falsification de requête intersite
(CSRF)
2)

37
 9. Utilisation de composants avec
des vulnérabilités connues

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.

38
 9. Utilisation de composants avec
des vulnérabilités connues
• Implications :
– L’attaquant utilise des outils manuels ou des scanners afin d’identifier
des composants vulnérables.
• Solutions
– Identifier tous les composants et les versions utilisées, ainsi que les
dépendances (ex: le plugin des versions).
– 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.
39
 10. Redirections et renvois non
validés

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.

40
 10. Redirections et renvois non
validés
• Implications :
– Un attaquant utilise des redirections non validées afin d’inciter
l’utilisateur à cliquer sur un lien.
– Certaines redirections essayent d’encourager les victimes à installer des
logiciels malicieux ou à fournir des informations sensibles
• Solutions
– 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.
– 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. Les applications peuvent utiliser ESAPI afin de
bénéficier de la fonction sendRedirect() permettant de s’assurer
que les redirections soient sûre
41
 Chapitr
e IV :
écurité des Applications Web
 Introduction
• Site web vs Application Web:
– Aucune définition précise
• Site Web :
– Permet l’accès à des documents statiques.
– Aucun « input » qui affecte les fonctionnalités du site.
• Application Web
– Développée autour d’un serveur Web.
– Prend des « inputs» de l’utilisateur qui affectent le «backend
business».
– Le serveur Web interagit avec un serveur d’application ou un serveur
de BD.

2
Fonctionnement de l’application Web
• Comprendre le problème

3
 Le mythe « notre site est sécurisé » ?
• « Nous utilisons des gestionnaires de vulnérabilités réseau ».
– Cette approche néglige la sécurité logicielle dans le réseau ou
celle du serveur Web.

• « Nous utilisons un Firewall »

– Les ports 80 et 443 sont ouverts

• « Les données sont cryptées avec SSL ».

– Ceci protège les données entre l’utilisateur et le site, pas
l’application Web.

4
 Ce qui peut arriver

• Affichage/fuites des données sensibles

• Vol des identités des comptes utilisateurs
• Accès illégal à des applications
• Exécution illégale de code arbitraire sur le serveur
• Modification du contenu
• Arrêt de l’application Web
• Prise de contrôle de l’application Web

• La réalité : 2/3 des applications Web présentent des vulnérabilités.

5
 Statistiques des applications Web
septembre 2014

6
 Principe des attaques
• Les attaques s’appuient généralement sur l’injection
des fautes:
– Une techniques permettant d’exploiter les vulnérabilités
de la syntaxe sémantique d’une application Web

• Les vulnérabilités de sécurité au sein d’une

application Web sont liées à:
– Des erreurs de programmation avec le langage de
l’application web ( exemple :.NET, PHP, Python, JSP, CGI…)

7
 Référencement des documents

[Link]

Le protocole
Le N° du port Tout ce qui
après le « ? »
Le nom de hôte est la partie
Chemin d’accès au document requête de
l’URL

8
 Exemples d’attaques

9
 OWASP top 10 – best practice
• OWASP: Open Web Application Security Project : est une communauté
publique open source, formée en 2001.

• Un ensemble de projets pour l’amélioration de la sécurité applicative.

• OWASP maintient le OWASP top 10, une liste qui identifie les rsiques les
plus critiques de la sécurité applicative.

• Depuis 2004 une nouvelle liste est arêtée tout les 3 ans.

• La liste est considérée comme la meilleure pratique (best practice)

industrielle pour la prévention des vulnérabilités des applications web et
elle est référencée par la plupart des organisations de sécurité comme PCI
DSS, FTC, MITRE, …

10
 OWASP top 10 – best practice

11
 WASC
• Web Application Security Consortiums
– Leurs objectifs est de développer et d’adopter des standards
pour la sécurité des applications Web.

• Site web officiel : [Link]

• Web Security Threat Classification project:

– Classement des vulnérabilités en 6 catégories.
– Clarifier et organiser les menaces de sécurité des applications Web
– [Link]

12
 WASC

13
 1. Injection de code
Une faille d'injection, telle l'injection SQL, OS et LDAP, 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.

• L’exemple le plus courant de l’attaque d’injection est l’injection SQL.

• L’injection SQL permet à un attaquant d’exécuter des commandes
SQL dans un champ de saisie.
• L’attaquant est capable de retourner et de voler des informations
sur les tables, changer des lignes, ou même supprimer le contenu
de la base

14
 1. Injection de code
• Quelles sont les conséquences:
– Fuite d’informations par le biais des messages d’erreurs du
SGBD.
– Echapper une séquence d’authentification
– Extraction des données à partir de la base.
– Prendre le contrôle complet sur la BD (insertion de
données, suppression des tables, etc.)
– Exécuter des commandes sur le système.
– Compromettre le système.

15
 1. Injection de code
• Principes d’injection SQL:
– Techniques de détection: découvrir comment l’application
interagit avec le serveur BD
• Souvent ajouter une simple quotte (') ou un point-virgule
(;) au champ ou paramètre à tester
• Les délimiteurs de commentaires (-- ou /* */, etc) et
d'autres mots clefs SQL comme 'AND' et 'OR‘.
• Analyser les erreurs retournées par l’application
– Exemple :
SELECT id FROM users WHERE username =‘test123’ and password =‘xxxxxxx’

SELECT id FROM users WHERE username =‘test123’ or 1=1-- and password =‘xxxxxxx’

16
 1. Injection de code
• Principes :
– Techniques d’exploitation: différentes techniques
• Par union: L'opérateur UNION est utilisé dans les injections SQL
pour joindre une requête.
• Booléenne: les opérateurs AND et OR.
• Basée sur les erreurs : forcer la BD à générer des erreurs
• Out-of-band: La technique consiste à utiliser des fonctions du
SGBD pour ouvrir une connexion séparée
• Par délai: mesurer les délai de la réponse du SGBD.
• Injection de procédure stockée
• Exploitation automatisée: SQLMap par exemple
– [Link]
(OTG-INPVAL-005)

17
 1. Injection de code
• Solutions:
– Validation des toutes les entrées : utiliser « white list » qui
accepte les bonnes valeurs. Taille, type,..
– Utilisation des API saines évitant toute utilisation de
l’interpréteur.
– Sinon, rejet des entrées contenant des données binaires, des
séquences de caractères d'échappement et des caractères de
commentaire.
– Utilisation des procédures stockées pour valider les entrées.
– Paramétrer les messages d’erreurs.
– Appliquer le moindre privilège de connexion à la BD.
– ….
18
 2. Violation de Gestion
d’Authentification et de Session

Les fonctions applicatives relatives à l'authentification et la

gestion de session ne sont souvent pas mises en œuvre
correctement, permettant 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.

19
 2. Violation de Gestion
d’Authentification et de Session
• Description:
– Faiblesse des fonctions de gestion de compte (ex: création de
compte, changement de mot de passe, récupération de mot de
passe, IDs de session faibles) permettant de deviner ou
d’écraser les credentials.
– Exposition des IDs de session dans l'URL. (Session hijacking)
– Vulnérabilité des IDs de session à l’attaque par fixation.
– Pas de timeout des IDs de session ou mauvaise désactivation
des sessions ou jetons d’authentification
– Non rotation des IDs de session après connexion réussie
– Les mots de passe, IDs de session et autres credentials
transitent par des canaux non chiffrés
20
 2. Violation de Gestion
d’Authentification et de Session
• Solutions
– Mécanismes pour sécuriser les mots de passe
• choisir des mots de passe forts et complexes.
• Protection et stockage des mots de passe : chiffrement
• En cas de changement des mots de passe: ils doivent saisir l’ancien
et le nouveau, validation par e-mail,..
– Mécanismes sécurisés pour la gestion des IDs de session:
• Combiner l’@IP soure avec l’ID de session
• Chaque login génère un nouvel unique ID de session.
• Forcer la ré-authentification termine le session hijacking
• Terminer la session après un time out d’inactivité.
• L’ID de session doit être long ,compliqué, aléatoire,..
• L’ID de session doit être protéger par SSL

21
 3. Cross-Site Scripting (XSS)

Les failles XSS se produisent chaque fois qu'une application

accepte des données non fiables et les envoie à un browser 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.

22
 3. Cross-Site Scripting (XSS)

• Implications
– Vol des cookies du domaine navigué
– Modifie complètement le contenu de n’importe quelle page
que vous voyez dans le domaine
– Redirige l’accès vers un site de phishing
– Exploite les vulnérabilités du browser pour prendre le
contrôle de la machine de la victime.

23
 3. Cross-Site Scripting (XSS)

24
 3. Cross-Site Scripting (XSS)

• Solutions
– L’option à privilégier est d’échapper toute donnée non fiable
selon le contexte HTML dans lequel elle sera insérée.
– 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.
– Considérez Content Security Policy (CSP) pour se protéger
des attaques XSS sur l’ensemble de votre site
– [Link]
evention_Cheat_Sheet

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

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.

26
 4. Références directes non
sécurisées à un objet
• Implications
– Une partie du ou tous les noms de ressources (fichiers, table, …) contrôlées
par l’entrée utilisateur.
– Changer un ID dans l’URL pour accéder à un autre compte.
• Solutions
– Eviter d’exposer les références aux objets (clés primaires, nom
de fichiers,…)
– Valider toutes les références aux objets.
– Vérifier toujours l’autorisation aux objets référencés.
– Utiliser le modèle de sécurité positives pour accepter
uniquement les bonnes références aux objets.

27
 5. Mauvaise configuration de
Sécurité

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

28
 5. Mauvaise configuration de
Sécurité
• Implications:
– Mise à jour des logiciels ? OS, Web/App Serveur, l’ensemble des librairies de
code,…
– Des fonctions inutiles activées (ex:ports, services, pages, comptes, privilèges,..
– Des mots de passe par défauts.
– La configuration des frameworks de développement (Spring, [Link], …) ne
sont pas configurés aves des valeurs sécurisées.
– Le Listage des répertoires est activés.
• Solutions
– Utiliser des scans et les audits pour détecter les mauvaises
configuration.
– Déployer les nouvelles versions et des correctifs de sécurité.
– Ne pas afficher les messages d’erreurs et les exceptions dans un
environnement de production
29
6. Exposition de données sensibles

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.

30
 6. Exposition de données sensibles
• Implications :
– Données stockées/archivées en clair
– Données circulent en clair.
– Algorithmes cryptographiques et clés faibles et non robuste, la gestion
des clés.
– Composants de l’application web identifiés accessibles via HTTP et HTTPS.
• Solutions
– 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.
– Ne pas conserver que les données sensibles cryptés avec des
algorithmes forts bycrypt, PBKDF2, scrypt.

31
 7. Manque de contrôle d’accès au
niveau fonctionnel

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.

32
 7. Manque de contrôle d’accès au
niveau fonctionnel
• Implications :
– L’interface utilisateur permet de naviguer vers des focntionnalités accès
restreint.
– Certaines vérifications côté serveur (authentification et autorisation) sont
manquantes.
• Solutions
– Faites en sorte que la gestion des droits soit facile à mettre à jour
et à auditer.
– La gestion des droits doit par défaut interdire tout accès . Ceci
impose l’autorisation explicite de certains rôles pour chacune des
fonctionnalités proposées.
– Si la fonctionnalité fait partie d’un Workflow, vérifier que les
conditions requises pour accéder cet état sont réunies.
33
8. Falsification de requête intersite
(CSRF)

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.

34
 8. Falsification de requête intersite
(CSRF)
• Implications :
– CSRF exploite le fait que la plupart des applications web permettent aux
attaquants de prévoir les détails de certaines actions.
– L’attaquant conçoit des pages web malicieuses, qui génèrent des requêtes
spécialement forgées, qui paraissent ainsi légitimes.
– L’attaquant force la victime à réaliser n’importe quelle opération.
• Solutions
– S’assurer que l’utilisateur est l’auteur de la requête, soit par la ré-
authentification, soit par la vérification que la demande n’est pas
automatisée.
– La meilleure option est d’inclure un jeton unique dans un champ caché.
Ce jeton, envoyé dans le corps de la requête HTTP, et non inséré à 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.
35
 8. Falsification de requête intersite
(CSRF)
1)

36
 8. Falsification de requête intersite
(CSRF)
2)

37
 9. Utilisation de composants avec
des vulnérabilités connues

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.

38
 9. Utilisation de composants avec
des vulnérabilités connues
• Implications :
– L’attaquant utilise des outils manuels ou des scanners afin d’identifier
des composants vulnérables.
• Solutions
– Identifier tous les composants et les versions utilisées, ainsi que les
dépendances (ex: le plugin des versions).
– 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.
39
 10. Redirections et renvois non
validés

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.

40
 10. Redirections et renvois non
validés
• Implications :
– Un attaquant utilise des redirections non validées afin d’inciter
l’utilisateur à cliquer sur un lien.
– Certaines redirections essayent d’encourager les victimes à installer des
logiciels malicieux ou à fournir des informations sensibles
• Solutions
– 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.
– 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. Les applications peuvent utiliser ESAPI afin de
bénéficier de la fonction sendRedirect() permettant de s’assurer
que les redirections soient sûre
41