09 Attaque Web

AKHAM Omar
IT Talents School
Les attaques WEB
Formation PIRATAGE ETHIQUE 2

Le protocole HTTP
• Le protocole HTTP (ou HTTPS) est le standard permettant
de véhiculer les pages web par un mécanisme de requêtes
et de réponses.
• Utilisé essentiellement pour transporter des pages web
informationnelles (pages web statiques), le web est
rapidement devenu un support interactif permettant de
fournir des services en ligne.
• Devenu le support d'un certain nombre de technologies
(SOAP, Javascript, XML RPC, etc.), le protocole HTTP
possède désormais un rôle stratégique certain dans la
sécurité des systèmes d'information.

Architecture d’un serveur Web

Vulnérabilités des serveurs web
• Mal configuration et vulnérabilités du Serveur Web, du Système
d’exploitation et du réseau.
• Installation du serveur avec les options par défaut.
• Ne pas appliquer les correctifs logiciels et les mises à jour
disponibles au niveau du Serveur Web, du Système
d’exploitation et des applications.
• Les fichiers et les scripts de démonstration et de backup par
défaut.
• Permissions inappropriées des fichiers et des répertoires.
• Services inutiles comme le debugging et le module
d'administration à distance dont les attaquants peuvent se
servir pour compromettre un système
• Utilisation des comptes et des mots de passe par défaut.
• Mal configuration de SSL et utilisation des certificats auto-signés
par défaut.

Vulnérabilité des applications web
• Les premières attaques réseau exploitaient des vulnérabilités
liées à l'implémentation des protocoles de la suite TCP/IP.
• Avec la correction progressive de ces vulnérabilités les attaques
se sont décalées vers les couches applicatives et en particulier
les serveurs web, dans la mesure où la plupart des entreprises
ouvrent leur système pare-feu pour le trafic destiné au web.
• Dans la mesure où les serveurs web sont de plus en plus
sécurisés, les attaques se sont progressivement décalées vers
l'exploitation des failles des applications web.
• Ainsi, la sécurité des services web doit être un élément pris en
compte dès leur conception et leur développement.

Attaques WEB: Démarche générale
• Comme pour la plupart des attaques…
- Recherche d’informations sur la cible
• Version HTTP? Serveur utilisé (Apache, IIS
…)? Serveur applicatif utilisé?
• Base de données utilisée (Oracle, DB2, SQL Server,
PostgreSQL ..)?
• Langages utilisés côté client comme côté serveur?
• En résumé : établir une liste de toutes les technologies
utilisées mises en œuvre pour attaquer à la fois côté client et
côté serveur.

Attaques WEB: Démarche générale (Suite)
– Recherche de vulnérabilités
- Manuelle
- Automatique
– Outils
- Proxies locaux pour le navigateur (Tamper Data,
WebScarab…): modification des paramètres
- Différents types de navigateurs (Firefox, IE,
Opera…)
- Clients spécifiques (pour les Web Services…)
- Scanners de vulnérabilités (Nessus, WebInspect,
…)
– Attaques avec seulement un navigateur
• Depuis n’importe quel poste (poste en
démonstration…)
• Au travers de proxies anonymes (international)
• Proxy au sein d’une Formation
entreprise (imputabilité?)
PIRATAGE ETHIQUE 8
Vecteurs des attaques WEB
• Les vecteurs actuels de ces attaques sont :
- Les vulnérabilités des technologies Web
- Javascript, PHP/ASP, Perl, Java, CGI, ActiveX...
- Les vulnérabilités du code source de l'application
- Relativement indépendant du langage utilisé
- Vient de la logique de développement
- Les vulnérabilités dues aux configurations systèmes et
applicatives :
- BDD (MySQL, Oracle, MS-SQL Server, Sybase...)
- Serveurs Web (Websphere, Tomcat...)
- OS (Windows, Linux, UNIX...)

Impact des attaques sur les serveurs web
• Les attaques des applications web sont toujours nuisibles car
elles donnent une mauvaise image de l'entreprise.
• Les conséquences d'une attaque réussie peuvent notamment
être une des suivantes:
– Défiguration de site web
– Exécution à distance d’application
– Elévation de privilège
– Divulgation et Vol d’information
– Denial-of-Service
– Modification de données, notamment modification de données
personnelles d'utilisateurs
– Intrusion au niveau de la machine du serveur web.
– Attaques d’autres machines

Les pare-feux IP et le Web
• Un firewall IP n’offre aucune protection contre les attaques visant
les applications Web, dans la mesure où celles-ci ont lieu au niveau
applicatif: elles utilisent le protocole HTTP sur le port 80, au même
titre que le trafic Web ordinaire.
• Pourtant, de SOAP aux applets Java en passant par les scripts
ActiveX, un grand nombre de menaces peuvent être véhiculées par
ce canal apparemment inoffensif et qui est laissé ouvert sur la
plupart des firewalls d’entreprise.
• La figure illustre bien la problématique
des protocoles pouvant contenir des
scripts malveillants, passant par le
port HTTP.

Attaques sur les
Serveurs WEB

Le piratage d’un serveur web
• Les serveurs web (surtout les serveurs IIS) sont très populaires dans
les entreprises.
• Il y a plus de quelques dizaines de millions d’installations dans le
monde. Malheureusement, cela signifie aussi qu’ils constituent les
cibles préférées des hackers.
• De ce fait, de nouveaux exploits émergent régulièrement et mettent
en danger l’intégrité et la stabilité de votre serveur web.
• Pour beaucoup d’administrateurs, il est difficile de toujours avoir les
derniers patches de sécurisation du serveur web et ainsi être
protégé contre les nouveaux exploits qui facilitent l’accès aux
vulnérabilités du serveur web pour les utilisateurs malicieux.
• Prendre avantage d’un exploit n’est pas difficile pour quiconque
possède les bons outils.

Erreur de configuration du serveur Web
• Il n’est pas trivial de configurer correctement un serveur
Web.
• Il se peut donc que certaines fonctionnalités activées
par
défaut restent en fonction lors de l’exploitation du
serveur.
• De plus, il faut que celui-ci soit tenu à jour à l’aide des
différents patch fourni par les concepteurs de l’application
serveur.
• Il se pourrait donc que certaines failles subsistent.
• Il est aussi très important de toujours retirer les fichiers
d’exemples du serveur, puisque les éventuels pirates
auront aussi le code à leur disposition et pourront
l’étudier afin de découvrir d’éventuels failles exploitables14
Formation PIRATAGE ETHIQUE
par ceux-ci.
Erreur de configuration du serveur Web
• Exemples:

Défiguration de site web
• La défiguration consiste à endommager l’apparence d’un
site internet, par exemple en modifiant, ajoutant ou
supprimant la page d’accueil ou une autre page.
• Cette action est aussi appelée barbouillage (defacement).
• Ce que l’on risque au premier abord, c’est l’atteinte à
l’image de marque.

Faites-vous entendre
• Le 17 avril 2012, des hackers ont piraté quinze sites
officiels libanais pour réclamer une amélioration des
conditions de vie et la fin des coupures d'eau et
d'électricité.
• "Nous ne cesserons pas tant que les conditions de vie
n'auront pas atteint le niveau qu'elles méritent au Liban",
dit un message posté sur le site du ministère de la Justice
par ce groupe baptisé "Raise Your Voice" ("Faites-vous
entendre").
• Les sites de la présidence, du ministère de l'Energie, des
Affaires étrangères, et de l'Agence de presse nationale ont
notamment été visés par les pirates.
Faites-vous entendre (Suite)
• Le texte était accompagné d'une caricature montrant un
homme obèse en costume, symbolisant le gouvernement,
nourri par un homme émacié vêtu d'un pagne blanc,
représentant le peuple libanais.

Outil de Défiguration de site web
PoizonB0x, un groupe bien connu qui s’est autoproclamé « cyber-
terroristes » et « guerriers du Net », a créé iisautoexp.pl, un utilitaire
automatisé qui s’occupe de toutes les tâches nécessaires pour obtenir
l’accès et performer des opérations de modifications.
Tout ce que les utilisateurs malicieux doivent faire est de donner le
nom du site au script et de le lancer. Si le site est sensible aux attaques
(c’est-à-dire, s’il ne possède pas les patches appropriés), la page de
garde (index.htm, default.asp ou variations) devient « PoizonB0x
Ownz YA ».

Déni de services (Attaque DoS)
• Ne jamais terminer une requête HTTP pour consommer le
plus longtemps possible une ressource côté serveur.
– L’idée consiste à envoyer une requête HTTP GET ou POST puis à
intervalle de temps régulier un entête quelconque sans terminer
la requête (pas de double retour chariot).
• Les serveurs Web utilisant un mécanisme de processus
dédié (thread) pour traiter chaque requête vont alors
consommer une ressource tant que la connexion sera
active.
– Un déni de service est alors possible quand le nombre de
processus maximum fixé par le serveur est atteint.

Déni de services (Attaque DoS)
• Son exploitation ne nécessite pas de bande passante
importante.
• A noter que les clients légitimes ayant des connexions
établis avec le serveur Web attaquée ne seront pas
impactées par l’attaque.
• Slowloris est un exemple d’outil permettant de
réaliser des
dénis de service (DoS) orientés Web.
– Cette attaque n’a rien de révolutionnaire,
– elle implémente simplement astucieusement des concepts
permettant de repousser le délai d’attente maximum afin de
mobiliser les ressources du serveur Web attaqué.

Techniques de dissimulation
(Website Cloaking)
• Le "cloaking" ( « dissimulation ») est une technique qui
consiste à présenter aux internautes des URL ou un contenu
différents de ceux destinés aux moteurs de recherche.

(Website Cloaking)
• Exemples de "cloaking" :
– Une page de texte HTML est présentée aux moteurs de
recherche, mais c'est une page d'images ou de contenu Flash qui
s'affiche pour les internautes.
– Du texte ou des mots clés sont insérés dans une page, seulement
si le user-agent ou l’adresse IP qui demande la page est un
moteur de recherche, et non un internaute.

(Website Cloaking)
• Le cloaking est utilisé par les pirates (black hat) pour
optimiser leur positionnement (upranking) dans les
moteurs de recherche.

(Website Cloaking)
Le "cloaking" peut aussi être
utilisé pour tromper les
utilisateurs de moteur de
recherche en les amenant à
visiter une page ou un site grâce
à la description fournie par le
dit moteur de recherche, alors
que la page finalement visible
par l'utilisateur a un contenu
sensiblement différent et/ou
sans rapport.

(Website Cloaking)
• Les moteurs de recherche principaux considèrent que cette

technique est une violation de leur directives, et ils suppriment les
sites incriminés lorsqu'un cloaking est détecté comme étant
frauduleux.
Attaques sur les
Applications WEB

Applications Web
• Applications accédées en réseau au moyen d’un
client léger (Simple navigateur Web)
• Pour tout type de structure
– PME, Grandes entreprises, service public ...
• Avantages
– pas d’installation préalable (client léger), ni
maintenance
– accès depuis partout, via Internet (applications
externes)
– Web-isation de « vieilles » applications (Web
Services)

Applications Web
• Service fourni
- Externe
- Commerce en ligne
- Catalogue de produits
- Banque en ligne (Virements, consultation…)
- Webmail
- …
- Interne : Accès aux ressources internes de
l'entreprise
- Annuaire
- Référentiel de documents (commercial,
technique…)
- Plannings
- …
Applications Web
• Technologies utilisées
– Langages: HTML, Javascript, PHP/ASP/CGI, Perl, Java,
ActiveX…
– Base de Données : MySQL, Oracle, MS-SQL Server,
Sybase…
– Serveurs d'applications: Tomcat, Websphere…
– Serveurs Web: IIS, Apache…
– Systèmes d’exploitation: Windows, Linux, UNIX...

Applications Web à architecture 3-tière
• Composants:

Données véhiculées par une requête HTTP
• Le protocole HTTP, support de la communication sur le
web, permet de véhiculer des paramètres sous formes de
requêtes de plusieurs façons:
– En-têtes HTTP;
– Champs de formulaires;
– Champs cachés;
– URL;
– Cookies.

Entêtes HTTP

Outils pour Analyse des Entêtes HTTP
• Live HTTP headers (Mozilla Firefox addon)
• Wappalyzer (Mozilla Firefox addon)
• Wireshark

Entête HTTP et Champs de formulaire:
Exemple

Champs cachés

URL
• Une URL possède la structure suivante:
• L'URL peut permettre de transmettre des

paramètres au serveur en faisant suivre le nom de
fichier par un point d'interrogation, puis de
données au format ASCII.
• Une URL est ainsi une chaîne de caractères selon le
format suivant : http://www.usj.edu/forum/index.php3
?cat=1&page=2
Les cookies
• Les cookies sont des petits fichiers textes
contenant des informations envoyées par le
serveur au client et étant stockés par le client.
• En 1990, Montulli de Netscape, créa le cookie pour
qu’il puisse assurer une certaine persistance dans
la communication sur le web (comme les
transactions).

Entêtes des cookies
• L’en-tête Set-Cookie:
– il est inséré dans l’en-tête d’une réponse envoyée par
un serveur à un client dans le but de le positionner
chez le client.
– Syntaxe:
Set-cookie: NOM=VALEUR; expires=DATE;
domain=DOMAINE; path=CHEMIN; secure
• L’en-tête Cookie:
– permet d’inclure la valeur d’un ou plusieurs cookie(s)
dans une requête HTTP à l’intention d’un serveur.
– Syntaxe :
Cookie: Nom1=Valeur1; Nom2=Valeur2;…

Entêtes des cookies
NOM=VALEUR Nom du cookie et sa valeur (champ obligatoire)
expires=DATE Date d’expiration du cookie (champ optionnel)
domain=DOMAINE Permet de spécifier le domaine pouvant avoir accès au

cookie (champ optionnel).
Si ce champ n’est pas spécifié, seul le serveur ayant créé
(ou généré) le cookie peut y avoir accès.
path=CHEMIN Permet de spécifier le préfixe des URL où le cookie est
utilisé et appliqué (champ optionnel)
secure Champ qui, s’il est mis, envoie le cookie et sa valeur

seulement lors de connexions chiffrées à l’aide de SSL.

Comment les serveurs accèdent aux
cookies?
• Lorsque vous visitez un site qui a placé un cookie sur votre
système, votre navigateur va vérifier s’il a un cookie appartenant
au site qu’il visite en comparant le nom du site et la liste de cookie
qu’il a.
• Si la réponse est affirmative, il compare l’URL de la requête HTTP
du site demandant le cookie et le champ path du cookie ; s’il y a
coïncidence entre ces 2 arguments, et que la date d’expiration
n’est pas atteinte alors le cookie est envoyé au serveur.
• Si plusieurs cookies ont passé tous les test de validités précédents,
ils seront tous envoyés au site grâce à l’en-tête Cookie.
• Si la date de validité du cookie est atteint, alors le cookie est
supprimé directement.

Le Top 10
• Liste les 10 vulnérabilités des applications Web les plus
rencontrées
• Mis à jour régulière par l’OWASP (Open Web
Application Security Project):
– v.2017 en cours
– http://www.owasp.org
• Indépendant des fournisseurs et des gouvernements.
• Objectif principal : produire des outils, documents et
standards dédiés à la sécurité des applications Web.

Le Top 10: Classement 2017

Le Top 10: Classements 2010 & 2013

Les composants d’une application Web
et leurs vulnérabilités

Failles d’injection
• Les failles d’injection, en particulier l’injection SQL, sont
courantes dans les applications web.
• Il existe différents types d’injection de données:
SQL, LDAP, HTML, XML, XPath, XSLT, commandes
systèmes, et beaucoup d’autres.

Failles d’injection
• L’injection se produit lorsqu’une donnée fournie par
l’utilisateur est envoyée à un interpréteur dans le cadre
d’une commande ou d’une requête.
• Les attaquants dupent l'interpréteur en lui faisant
exécuter des commandes imprévues via la soumission de
données spécialement formées.
• Les failles d’injection, permettent aux attaquants de créer,
lire, modifier ou effacer toute donnée arbitraire de
l’application.
• Dans le pire des scénarii, ces failles permettent à un
attaquant de compromettre complètement l’application et
le système sous-jacent même en contournant les
environnements de filtrage sérieusement structurés.

Rappel: Langage SQL
• Langage permettant d'interroger une base de données.
– Normalisé, la plupart des BD sont compatibles (MySQL,
Posgresql, MS SQL, Access, ...)
– Les applications webs interrogent en général leur Base de
Données via des commandes SQL.
• Accès en lecture
– select champ from table where conditions.
• select * from utilisateurs where user=root and
passwd=MD5('toto')
• Ajout d'un élément dans une table
– insert into table (champ1,champ2) VALUES (v1,v2)
• insert into utilisateurs (login, passwd) VALUES ('admin','toto')
• Mise à jour d'un élément
– update (...)
Langages SQL: Quelques différences
• Exemples:
• MySQL: SELECT * from table WHERE id = 1 union select 1,2,3
• PostgreSQL: SELECT * from table WHERE id = 1; select 1,2,3
• Oracle: SELECT * from table WHERE id = 1 union select null, null,null from sys.dual
Injection SQL: Définition
• Une injection SQL est l'exploitation du mauvais contrôle
des données de l’utilisateur par une application Web
interagissant avec une base de données, en injectant une
requête SQL non prévue par le système pour obtenir un
résultat qui n’était pas prévu, au début, par le
programmeur et pouvant compromettre sa sécurité.

Cas d’une Requête SQL Normale
• A partir de son navigateur, l’internaute envoie une
demande d’informations ou d’inscriptions à un serveur.
• Cette demande s’effectue sous la forme d’une requête
très
structurée.
• Cette requête est analysée par le Serveur de Base de
Données (SBD) et si, elle est compréhensible, le SBD traite
la requête et renvoie les informations au serveur de
l’internaute qui les affiche conformément à la
programmation de sa page internet via un langage comme
ASP, JSP, PHP, etc…


Exemple:

Injection SQL: Principe
• L'attaquant envoie au site via différents champs
(formulaire GET, POST, Cookies, User-Agent, ...) une
requête SQL, compréhensible par le serveur, mais qui
permet d’obtenir des résultats voulus par le pirate et non
par le programmeur du site.

Détection d’une faille Injection SQL
• Envoyer des caractères spéciaux dans les champs des
formulaires et voir si des erreurs sont générées.
– caractères à essayer: ' (quote), '' (double quote), (, ), #, --, ;
– Exemple d'erreur pouvant apparaître:

Types d’Injection SQL

Injection SQL Simple: tautologie
Accès non autorisé

Injection SQL Simple : Utilisation de l’Union
• La commande Union permet de chaîner les SELECT
• Par exemple :
SELECT * FROM News WHERE Nom=’Dupont’
UNION SELECT * FROM News WHERE Nom=‘Durant’
– Ici on affiche les informations sur Dupont et sur Durant.
• Il faut, à gauche et à droite du UNION, avoir le même
nombre de champs.

Exemple: Vol des données sensibles
Code vulnérable:

Exemple: Vol des données sensibles:
Analyse de l’attaque:

Injection SQL Simple: Error Based
Utile pour extraire le Nom de la Base de Donnée, des
tables, des colonnes et des champs:

Injection SQL Simple: Utilisation de limit
Exemple de code vulnérable:

Injection SQL Simple: Utilisation de limit
• Si le pirate saisit la valeur 'or 1=1# dans le champ:
txtUser.Text:
– La requête SQL va renvoyer des résultats et donc le
test
suivant va aboutir:
if(intRecs > 0) (ou intRecs != 0)
– Le pirate est authentifié!
• Que faire si le test avait été
if(intRecs == 1)
– Le pirate peut utiliser la commande SQL limit:
• limit indice,nombre d'éléments
select * from user where user = '' or 1=1 limit 0,1
-> renvoie le premier élément (indice 0) de la table.
Injection SQL Simple:
Nom des tables et champs
• Il existe des meta-tables dans les bases de données
contenant une partie de ces informations
• Dans MS SQL et MySQL (à partir de la version 5.0)
– Table information_schema.tables contient les champs
intéressants suivants:
• table_schema: nom des databases
• table_name: nom des tables
• TABLE_COMMENT: commentaire sur la table
• Exemple:
/index.php?Id=3 UNION Select TOP 1
table_name FROM information_schema.tables

Injections SQL à Simple:
La Table information_ schema.tables:
mysql> select table_schema, table_name, table_comment From

information_schema.tables;
+--------------+------------+--------------
+
| table_schema | table_name |
table_comment|
| web | id | |
+--------------+------------+--------------
| web | user | |
+
+--------------+------------+--------------
Injections SQL Simple:
• Pour le nom des champs:
– Dans MS SQL:
SELECT TOP 1 COLUMN_NAME FROM
INFORMATION_SCHEMA.COLUMNS
1) WHERE TABLE_NAME='admin_login‘ -- return: login_id
2) WHERE COLUMN_NAME NOT IN ('login_id') -- return: login_name
– Dans MySQL (< 5.0) ou autres BD, il va falloir essayer de deviner.
• Si on a de la chance on peut faire un * à la place du nom des champs :
select id from text union select * from utilisateurs
• Dans cet exemple, la table utilisateurs ne doit contenir qu'une colonne.

Injection SQL: Injections SQL à l'aveuglette
• Les Blind SQL Injections font partie des techniques avancées
d'injections SQL.
• On les utilise dans le cas de scripts à réponse binaire, c'est à dire qui
retournent une réponse du type soit vrai, soit faux. C'est le cas par
exemple des formulaires d'authentification.
• Ce type de script n'affiche pas le résultat d'une injection mais
indique simplement s'il y a erreur ou succès, d'où la difficulté
apparente d'exploitation.
• C'est pourquoi il faut dans la plupart des cas utiliser la méthode de
la force brute, mais de manière relativement intelligente,
permettant de gagner un temps énorme.
• Il est possible de récupérer des informations très importantes pour
un attaquant potentiel, tels que le nombre de champs d'une table,
leur type, leur nom, le nom des tables, la version du serveur etc.

Injection SQL à l'aveuglette:
Version du SDB
• Il y a des fonctions qui ne sont implémentées dans le SDB qu’à partir
d’une certaine version, c’est le cas par exemple de la commande
UNION.
• De plus, la connaissance de la version et, encore mieux du type de
SDB, est un plus pour un hacker car cela lui permet d’adapter sa
stratégie d’attaque.
• Pour cela on utilise la fonction @@version via une injection.
• Par exemple:
admin’ AND @@version > 3
• Si la version est <=3 donc échec. Sinon, on essaye avec 4. Puis avec
5. Quand on a échec, on déduit la version.
• On peut aussi obtenir des informations sur l’indice avec:
admin’ AND SUBSTRING(@@version,1,3) = 5.1
Même principe, en fonction de l’erreur on a
l’information. Formation PIRATAGE ETHIQUE 69
Utilisation de la commande ORDER BY
• Une des difficultés pour accéder à une base de données
est de définir le nombre de colonne dans une table.
• Pour cela, on utilise la commande ORDER BY.
• Supposons que nous ayons une URL sous la forme
/index.php?Id=4.
• On effectue une injection sous la forme:
/index.php?Id=4 ORDER BY 1

Utilisation de la commande ORDER BY
• Normalement, la table possède au moins une colonne. Il
n’y aura donc pas d’erreur.
• On continue avec :
Etc…
• Jusqu’à obtenir une
erreur par exemple en 5.
Il y a donc 4
colonnes.
• Il existe d’autres Formation PIRATAGE ETHIQUE 71
Utilisation de la commande LIKE
• On ne connait pas toujours la terminologie exacte de ce
que l’on recherche.
• Supposons que, dans la base de News, nous cherchions un
article contenant quelque chose comme «prod», nous
utiliserons la requête LIKE
SELECT Article FROM News WHERE Nom LIKE ‘%prod%’
Le SBD va chercher tous les articles contenant «prod».
• Si on écrit:
SELECT Article FROM News WHERE Nom LIKE ‘prod%’
Il affichera tous ceux commençant par “prod”
• Et si on écrit:
SELECT Article FROM News WHERE Nom LIKE ‘%prod’
Tous ceux finissant par “prod”
Trouver un Utilisateur
• Pour exploiter la faille, on va passer une première requête
conforme :
• Et on va rajouter une requête pour obtenir les
informations que l’on souhaite :
UNION SELECT Id, Login, Password FROM Users
WHERE Login LIKE ‘a%’
• On lui demande d’afficher tous les champs où le login
commence par « a » ce qui donne comme requête finale :
WHERE Login LIKE ‘a%’

Craquage des mots de passe
• Avec un peu de patience, on finit par trouver le login,
reste à faire la même chose pour le mot de passe.
• Quand on a trouvé un login (Dupont) et afin de ne pas
tourner en rond, on peut trouver la longueur du mot de
passe, en faisant une requête du style:
WHERE Login = ‘Dupont’ AND LENGTH(Password) = 6
• Si la longueur du mot de passe est de 6, on se retrouve
dans le compte de Dupont sinon on a un message d’erreur.
• Une fois la taille du mot de passe trouvée, on utilise de
nouveau LIKE pour craquer le mot de passe.

Injections SQL à l'aveuglette:
Deviner le nom des tables et champs

Injections SQL à l'aveuglette: Message
d’erreur unique
Il y a des cas où le message retourné est le même, si l’attaque réussit
ou non.

Utilisation de WaitFor Delay
waitfor delay bloque l’exécution du lot d’instructions et va nous
permettre d’utiliser le temps de réponse du serveur comme valeur de
retour dans le cas d’une exploitation « à l’aveugle ».

Exemple1: Nom des champs:
Cas 1: Retour immédiat, donc le nom du champ est incorrect:
admin’;select username from users waitfor delay '00:00:10‘
Cas 2: Retour après 10 s, donc le nom du champ est correct:

admin’; select username from users waitfor delay '00:00:010'

Exemple2: Extraction des utilisateurs: Recherche par dichotomie:
Nous avons besoin de 56 requêtes pour trouver un nom de 8 lettres.
Cas où le premier caractère est t:
--Retour immédiat, donc le premier caractère est incorrect:
if ((select top 1 Substring(Lower(username),1,1) from users) like '[a-m]')
waitfor delay '00:00:10‘
--Retour après 10 s, donc le premier caractère est correct:
if ((select top 1 Substring(Lower(username),1,1) from users) like '[n-t]')
--Retour immédiat, donc le premier caractère est incorrect:
if ((select top 1 Substring(Lower(username),1,1) from users) like '[n-q]')
--Retour après 10 s, donc le premier caractère est correct:
if ((select top 1 Substring(Lower(username),1,1) from users) like '[r-t]')
--Retour immédiat, donc le premier caractère n’est ni r ni s, donc c’est t:
if ((select top 1 Substring(Lower(username),1,1) from users) like '[rs]')

Exemple2: Extraction des utilisateurs: Recherche par dichotomie (Suite):
-- On passe au caractère suivant:

if ((select top 1 Substring(Lower(username),2,1) from users) like ‘[a-m‘])
…
-- Pour trouver, par exemple, le premier caractère du troisième utilisateur: if
((select top 1 username from users
where username not in (select top 2 username from users)) like
'[n-t]%') waitfor delay '00:00:10‘

Utilisation de la commande UPDATE
• Supposons que nous ayons eu connaissance du login d’un
internaute mais nous ne connaissons pas son mot de passe.
• On peut alors essayer d’utiliser la commande UPDATE pour
mettre son environnement à jour avec nos informations.
• Prenons l’exemple, où nous savons que Dupont a un
compte. On peut injecter:
admin’ UNION UPDATE Admin SET
Password=’Hacker’ WHERE Nom=’Dupont’
• Connaissant le login Dupont et le Password Hacker on peut
faire un login.

Utilisation de la commande UPDATE
Mise à jour d’une table:

Utilisation de la commande INSERT
• Il n’est pas toujours possible de s’enregistrer dans une
base de données car il n’y a pas forcément une page de «
registration ».
• Il faut envoyer une demande au webmaster qui fait une
ouverture de compte et donne les informations d’accès.
• Il existe pourtant une possibilité de passer outre.
• Pour cela, on utilise la commande INSERT.

Utilisation de la commande INSERT
Ajout d’un nouveau enregistrement:

Utilisation de la commande Drop Table
Suppression d’une table:

Interaction avec le OS

Exécution d’une commande shell
• On peut exécuter des commandes shell sur le serveur Web
en utilisant des « Stored Procedures » comme par
exemple master..xp_cmdshell dans le cas de SQL Server
• Exemple de Syntaxe:
toto’ ; exec master..xp_cmdshell "commande shell" --
• ping: toto’ ; exec master..xp_cmdshell "ping 10.10.10.1" --
• lister un répertoire:
toto’ ; exec master..xp_cmdshell "dir c:\*.* /s" --
• Créer un fichier: toto’ ; exec master..xp_cmdshell
"echo ‘Un Hacker est passé par là’>c:\Hello.txt" –
• Modification d’une page Web:
toto’ ; exec master..xp_cmdshell
"echo ‘You are Hacked’>c:\inetpub\wwwroot\
index.htm" -- Formation PIRATAGE ETHIQUE 87
Injection SQL: Contre-mesures
• Validation des données d’entrée (sanitize user input):
– utilisez un mécanisme standard de validation des entrées pour
valider toutes les données d'entrée pour la longueur, le type, le
format, la syntaxe et les règles métiers avant d’accepter
l’affichage ou le stockage de donnée.
– Utilisez une stratégie d’« acceptation des bonnes valeurs ».
– Rejetez toute entrée non valide plutôt qu'essayer d‘assainir les
données potentiellement hostiles.
Validator.ValidationExpression =
"\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*";

• Utilisez des APIs de requêtes fortement typées avec des
marqueurs de substitution dédiés, même lors d’appels de
procédures stockées
• Respectez le principe du moindre privilège lorsque vous
vous connectez à des bases de données ou tout autre
système de back-office
• Evitez les messages d’erreurs détaillées, utiles aux
attaquants
• Utilisez des procédures SQL stockées car elles sont
généralement non vulnérables à l’injection SQL. Faites
toutefois attention qu’elle ne le devienne (via l’utilisation
de fonctions de type exec() ou par la concaténation
d’arguments dans la procédure stockée)
• N’utilisez pas d’interfaces de requêtes dynamiques (tel
que mysql_query() ou similaire)
• N’utilisez pas les fonctions d’échappements simples,
comme la fonction PHP addslashes() ou les fonctions de
remplacement de caractères comme str_replace("’", "’’").
Elles sont faillibles et ont déjà été utilisées avec succès par
des attaquants. Pour PHP, utilisez
mysql_real_escape_string() si vous utilisez MySQL, ou
utilisez plutôt PDO qui ne nécessite pas d’échappement
• Attention aux erreurs canoniques. Les données en entrée
doivent être décodées et normalisées à la représentation
interne courante de l'application avant d'être validée.
Assurez-vous que votre application ne décode pas la
même entrée deux fois. De telles erreurs pourraient être
utilisées pour contourner les schémas de whitelist en
présentant des entrées dangereuses après qu'elles aient
été vérifiées
Injection des commandes
• Ce type d’injection permet à un pirate de gagner l’accès à
un shell ou exécuter une commande sur la machine
distante.

Injection LDAP
• L'injection LDAP fonctionne de la même manière que
l'injection SQL. Elle permet d’injecter dans un champ de
formulaire par exemple, un filtre LDAP qui permet
d’obtenir des résultats voulus par le hacker et non par le
programmeur du site à partir d’un annuaire LDAP.

Injection de fichiers malicieux
• L’exécution de fichiers malicieux existe dans beaucoup
d’applications.
• Les développeurs utilisent souvent la possibilité de
concaténer des données d’entrée dans des fonctions de
gestion de fichiers ou de flux, ou font confiance à des
fichiers donnés en entrée.
• Sur beaucoup de plateformes, les Framework autorisent
l’utilisation d’objets externes, comme des URLs ou des
références au système de fichier. Lorsque les données ne
sont pas correctement vérifiées, cela peut conduire à
l’exécution de code distant ou à l’affichage de contenu
non voulu lors de l’exécution par le serveur Web.

• Cela permet à un attaquant :
• D’exécuter du code à distance
• D’installer des rootkits et compromettre un système.
• Cette attaque est particulièrement répandue sur PHP, et
un soin extrême doit être pris avec tout flux ou toute
fonction de fichier afin de s'assurer que l'entrée fournie
par l'utilisateur n'influe pas les noms de fichiers.


Cross-Site Scripting (XSS): Principe
• Le Cross Site Scripting (XSS) est un sous-ensemble de
l'injection HTML.
• Les failles XSS se produisent à chaque fois qu'une
application prend des données écrites par l'utilisateur et
les envoie à un browser web sans en avoir au préalable
validé ou codé le contenu.
• Pour cela, l’attaquant provoque l’envoi à la victime, par le
site Web légitime, d’une page hostile contenant du code
malveillant.
• Cette page est exécutée sur le poste de la victime, dans le
contexte du site Web d’origine (zone Internet, sites de
confiance, …), et dans le contexte de sécurité de
l’utilisateur courant.
XSS: Objectifs
• Insérer des balises <script>, <object>, <applet>, <form> et
<embed>
• Exécuter un script malveillant dans le navigateur Web de
la victime
• Voler des informations de session Web
et des cookies d'authentification pour
détourner des sessions utilisateur
• Défigurer des sites web
• Effectuer des attaques par phishing
• Accéder à l'ordinateur client

XSS: Types
• Trois méthodes pour injecter le code:
– L’attaque XSS par réflexion (Reflected XSS) qualifié de
«faille non permanente»
– L’attaque XSS par stockage (Stored XSS) qualifié de
«faille persistante»
– L’attaque XSS basée sur DOM (DOM-Based XSS) ou local
XSS

XSS: XSS par réflexion
• Aussi qualifié comme faille non permanente
• Utilisation d'une page paramétrée
– Exemple
http://www.serveur.com/erreur.jsp?msg= <h3>TEXTE</h3>
– Affichage de la variable msg par le serveur
• Envoi de l'URL via un Email ou un serveur de type
tinyurl.com ou minilien.com

XSS: XSS par réflexion
• Exemple: Attaque par email

XSS: XSS par Stockage
• Aussi appelé faille permanente
• L'attaquant envoie le code au serveur (exemple, dans un forum
Web)
• Le serveur le stocke
• Et l'envoie tel quel au client lors de la génération et la
visualisation de la page ...
• Principe:
(1) Injection du script dans le serveur vulnérable.
(2) l’utilisateur se rend sur le serveur vulnérable:
• Suite à un SPAM
• Sur un forum
(3) Récupération des données de façon malicieuse.

• Exemple: Utilisation du champ commentaire d’un Forum:
Affichage d’un popup Window.

• Autre Exemple: Vol des Cookies des utilisateurs:

Scénario:
Vol des Cookies des utilisateurs
VIRTUALFORGE

JavaScript: Objet DOM
• Que peut faire le langage ?
– Composer la page (document.write)
– Récupérer des informations sur le document (document.cookie,
document.location, ..)
– Charger une autre page (document.location = ...)
– Popups, ...
• Mécanismes de sécurité
– Les propriétés du document ne sont pas visibles par d'autres
serveurs.
– Exemple: une frame chargée depuis le serveur A ne peut pas lire
les propriétés d'une autre chargée depuis le serveur B
– Le code JavaScript ne peut pas lire, modifier les préférences ou le
disque de l'utilisateur.
– Extensions Microsoft "Active Scripting": zones de sécurité
XSS: XSS basé sur DOM
• Contrairement aux deux types précédents, dans une
attaque XSS basée sur DOM le script malicieux est généré
par le navigateur sur la machine victime et pas au niveau
du serveur.
– Vulnérabilité exploitée dans le code client.
– Le serveur n’effectue ni une réflexion ni un stockage du code
malicieux.
• Dans ce cas la page HTML contient un code JavaScript avec
des objets de traitement de DOM (Document Object
Model).
• L’objet DOM le plus vulnérable est l’objet document et
surtout ses propriétés location, URL et referrer
(document.location,…).

• Exemple, soit la page HTML suivante (
http://www.vulnerable.site/welcome.html)
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL. length));
</SCRIPT>
<BR>
Welcome to our system…
</HTML>

• Exemple si on tape le URL suivant:
http://www.vulnerable.site/welcome.html?name=Joe
On obtient:
Hi Joe
Welcome to our system…
• Tandis que la requête suivante:
http://www.vulnerable.site/welcome.html
?name=<script>alert(document.cookie)</script>
permet d’afficher la cookie.

• Autre exemple,
http://www.vulnerable.site/welcome.html#name=
<script>alert(document.cookie)<script>
• Le # indique au navigateur que tout ce qui le suit est
considéré comme fragment et donc n’appartient pas à la
requête.
Alors le serveur va voir seulement
www.vulnerable.site/welcome.html
• Dans ce cas, le code malicieux n’est pas transmis à travers
le réseau. Ceci empêche le filtrage dans le cas où le
serveur est protégé par un IDS (En supposant que le lien
provient d’un endroit sûr).
XSS: Les protections
• Effectuer une validation en profondeur :
– Des headers,
– Des cookies,
– Des chaînes de requêtes,
– Des champs de formulaires,
– Et aussi des champs cachés,
• .NET: Utilisez la bibliothèque Microsoft Anti-XSS 1.5
disponible gratuitement sur MSDN :
http://www.microsoft.com/downloads/details.aspx?Fa
milyID=efb9c819-53ff-4f82-bfaf-
e11625130c25&DisplayLang=en
• Utiliser le projet des filtres OWASP(Java/PHP) :
http://www.owasp.org/index.php/Category:
OWASP_Filters_Project
Attaque CSRF: Principe
• Le Cross-Site Request Forgery (CSRF ou parfois XSRF qui se prononce
"Sea Surf" ) abuse de la confiance qu'a un site, dans ses utilisateurs.
Cette attaque force un utilisateur à exécuter des requêtes vers un
site victime, mais totalement à leur insu. Généralement ces
utilisateurs ont des droits élevés sur le site victime, pour un
maximum de dégât:
– Il suffit d'insérer un script dans une page web ou de le camoufler dans un e-
mail.
– En suivant le lien contrefait, le navigateur de la victime va exécuter une
requête vers un site sur lequel la victime est authentifiée.
– Cela implique que le navigateur de la victime va effectuer une action sur un
site vulnérable à la place de la victime.
• Elle est d'autant plus difficile à détecter qu'elle parait tout à fait
légitime.

Attaque CSRF: Principe

Attaque CSRF: Exemple

Attaque CSRF: Explication
• Les balises IMG représentent l'un des vecteurs d'attaques
les plus répandus.
• Le code suivant est une page web html qui affiche à la
suite du mot "XMCO PARTNERS", une image.
• Le navigateur qui affiche cette page va aller télécharger

l'image "access.gif" sur le serveur qui héberge le site
"xmcopartners.com" sans que l'utilisateur ne s'en
aperçoive. L'opération est transparente pour l'utilisateur...

• La même requête avec un nom d'image erroné donne
alors le résultat suivant :
• Dans ce cas, la requête:

" GET /images/acceszzzzz.gif"
n'a pas aboutie mais a bien été interprétée par le serveur
qui a renvoyé une erreur " 404 not found".

• Le navigateur ne fait aucune différence entre une requête
GET d'une page web ou d'une image.
• On voit ici quel impact pourrait avoir une requête
particulièrement travaillée et envoyée à l'insu de la
victime.
• En injectant le code suivant, on peut imaginer les
conséquences si l'utilisateur est préalablement logué sur
le site en question. On force ici l'utilisateur à acheter 100
télévisions...

Attaque CSRF: scénario
Scénario:
Enchère
VIRTUALFORGE

Attaque CSRF: Conditions requises
• Plusieurs conditions doivent être réunies pour permettre une
éventuelle attaque.
• Les sites qui implémentent des requêtes "POST" sont moins
exposés. En effet, les requêtes "GET" sont facilement prédictibles.
Les informations transitent dans l'URL, il suffit donc de forger une
URL afin d'envoyer une requête valable au serveur web.
• Par ailleurs, le pirate doit être certain que la victime est authentifiée
sur le site et qu'elle possède un cookie.
• Le site web cible ne doit pas implémenter une seconde étape lors de
la validation des actions et les paramètres envoyés doivent rester
statiques.
• Si plusieurs pages de formulaires sont utilisées, le pirate devra
construire un script bien plus évolué qu'une simple URL.
L'application sera donc moins exposée.

Attaque CSRF: Conséquences
• La plupart des services fournis par une application web
peuvent ainsi être exploité par cette attaque:
– changement de mot de passe, post de message sur un forum,
achat en ligne, achat d'action sur un site boursier, envoi d'une
carte de vœux virtuelle, envoi d' e-mails... Ce genre d'attaques
est souvent perpétré à l'encontre des forums. Il utilise des balises
images pour dissimuler le code.
• Une victime, connectée à son site en ligne visite un site
pirate qui envoie une requête HTTP destinée à créditer
son compte sans que cette dernière n'ait spécifiquement
choisi d'effectuer cette action.
• Un pirate pourra également forcer la victime à poster un
ver sur un forum, ou à relayer une requête lourde vers un
site choisi pour causer un déni de service.
Attaque CSRF: Comparaison avec XSS
• Ces deux attaques sont diamétralement opposées.
• Le XSS est une attaque construite dans le temps, menée
étape par étape (vol de cookie puis réutilisation), qui a
pour but d'injecter du code dans un document HTML afin
d'abuser le navigateur client. L'attaque cible un site précis
qui possède un problème de validation de certaines
entrées utilisateur.
• Le CSRF est une attaque instantanée. Elle ne repose pas
sur l'exécution d'un script dans un navigateur. Son but est
d'exécuter une action non désirée par le client sur un site
où la victime possède un accès privilégié.

Attaque CSRF: Comparaison avec XSS
• Concrètement, le XSS est réalisé pour voler un cookie de
session alors que le CSRF va utiliser le cookie de session
(sans que le pirate ne connaisse sa valeur) et la confiance
établie entre le site web et le client afin d'exécuter une
requête légitime mais toujours à l'insu de l'utilisateur
abusé.
• La portée de cette attaque est donc plus étendue. Un site
peut se protéger du XSS en utilisant un filtre sur les
entrées utilisateur alors que la requête exécutée avec le
CSRF paraîtra totalement légitime. Le CSRF se base sur la
confiance attribuée aux utilisateurs par l'application.

Attaque CSRF: Contre-mesures
• Éviter d'utiliser des requêtes HTTP GET pour effectuer des actions
– Cette technique va naturellement éliminer des attaques simples basées sur
les images, mais laissera passer les attaques fondées sur Javascript, lesquelles
sont capables de lancer des requêtes HTTP POST.
• Demander des confirmations à l'utilisateur pour les actions
critiques
– Au risque d'alourdir l'enchaînement des formulaires.
• Vérifier l'adresse url du script appelant (referrer)
– Au risque d'alourdir le développement des formulaires.
• Utiliser des jetons de validité dans les formulaires
– Faire en sorte qu'un formulaire posté ne soit accepté que s'il a été produit
quelques minutes auparavant : le jeton de validité en sera la preuve. Le jeton
de validité doit être transmis en paramètre et vérifié côté serveur.

Fuite d’information et traitement
d’erreur incorrect
• Les applications génèrent fréquemment des messages
d'erreurs et les affichent aux utilisateurs.
• Ces messages d'erreurs sont souvent très utiles pour les
attaquants car ils peuvent dévoiler d'importants détails
sur l’implémentation ou des informations utiles pour
exploiter des vulnérabilités.

d’erreur incorrect

d’erreur incorrect: Contre-mesures
• Assurez-vous que toute l'équipe de développement partage
la même approche relative au traitement d'exceptions
• Désactivez ou limiter le traitement d'erreur détaillé. En
particulier, ne pas afficher les informations de débogage
aux utilisateurs, l'état de la pile ou des informations
relatives aux chemins
• Assurez que les « path » sécurisés qui ont des résultats
multiples retournent des messages d'erreur similaires ou
identiques approximativement dans le même temps. Si ce
n'est pas possible, envisager d'imposer un temps de
réponse aléatoire pour toutes les transactions pour cacher
cette information à l'attaquant

• Différentes couches peuvent retourner des erreurs
fatales ou une exception, telle la couche base de
données, le serveur web sous-jacent (IIS, Apache, etc.).
Il est crucial que les erreurs venant de chaque couche
soient dûment vérifiées et configurées pour empêcher
les messages d'erreur d'être exploités par des intrus.
• Modifier le traitement d'erreurs par défaut pour qu'il
retourne tout le temps une erreur « 200 » (OK).
• réduit la possibilité qu'un outil automatisé aurait de
déterminer si une erreur sérieuse s'est produite.

• Outil de sécurité IIS: CustomError
– Permet aux développeurs et aux administrateurs de
personnaliser des pages d’erreur (code 404 et autres)

Manipulation d'URL
• Cause
– Conception de l’application
• Conséquences
– Accès à des fichiers/répertoire en dehors de l’application
– Accès à des ressources et fonctionnalités d’administration
– Accès à des ressources d’autres utilisateurs
• Périmètre
– Potentiellement toute application
• Exemple
– Lecture de fichiers du système:
http://www.xxxxxxxxxxx.fr/print.php?PAGE=L2V0Yy9wYXNzd2Q=
avec ‘L2V0Yy9wYXNzd2Q=‘ = /etc/passwd encodé en base64

Manipulation d'URL
• En manipulant certaines parties d'une URL, un pirate peut
amener un serveur web à délivrer des pages web
auxquelles il n'est pas censé avoir accès.
• En effet, sur les sites web dynamiques les paramètres sont
la plupart passés au travers de l'URL de la manière
suivante :
http://cible/forum/index.php3?cat=2
• Les données présentes dans l'URL sont créées
automatiquement par le site et lors d'une navigation
normale un utilisateur ne fait que cliquer sur les liens
proposés par le site web.

Manipulation d'URL
• Si un utilisateur modifie manuellement le paramètre, il
peut essayer différentes valeurs, par exemple :
http://cible/forum/index.php3?cat=6
• Si le concepteur n'a pas anticipé cette éventualité, le
pirate peut éventuellement obtenir un accès à un espace
normalement protégé.

Manipulation d'URL
• Par exemple, dans une application de banque en ligne, il
est fréquent d’utiliser le numéro de compte comme clef
primaire.
• Il est alors très tentant d’utiliser le numéro de compte
directement dans l’interface Web.
• Même si le développeur a pris soin de prévenir les
injections SQL, si il n’y pas de contrôle d’autorisation en
place pour vérifier que le possesseur d’un compte peut le
lire, un attaquant peut modifier le paramètre de numéro
de compte pour changer ou lire tous les comptes.

Manipulation d'URL:
Tâtonnement à l'aveugle
• Un pirate peut éventuellement tester des répertoires et
des extensions de fichier à l'aveugle, afin de trouver des
informations importantes.
• Voici quelques exemples classiques :
– Recherche de répertoires permettant d'administrer le site
: http://cible/admin/
http://cible/admin.cgi
– Recherche de script permettant de révéler des informations sur
le système distant : http://cible/phpinfo.php3
– Recherche de copies de sauvegardes.
L'extension .bak est généralement utilisée et elle n'est pas
interprétée par défaut par les serveurs, ce qui peut aboutir au
téléchargement d'un script :
http://cible/index.php3.bak
Manipulation d'URL:
Traversement de répertoires
• Les attaques dites «de traversement de répertoires»
(directory traversal ou path traversal) consistent à
modifier le chemin de l'arborescence dans l'URL afin de
forcer le serveur à accéder à des sections du site non
autorisées.

Manipulation d'URL:
http://www.xyz.com/scripts/..%5C../winnt/system32/cmd.exe?/c+dir+c:\
• Le Hacker peut:
– Naviguer sur le disque logique où est installé IIS
– Exécuter du code présent sur le serveur
Manipulation d'URL:
• Sur les serveurs vulnérables, il suffit de remonter le
chemin avec plusieurs chaînes du type « ../ » :
http://cible/../../../../repertoire/fichier
• Des attaques plus évoluées consistent à encoder certains
caractères :
– soit sous la forme d'encodage d'URL :
http://cible/..%2F..%2F..%2Frepertoire/fichier
– soit avec une notation Unicode: Mauvaise prise en charge de
l’Unicode dans IIS 5 (bug IIS Unicode)
On peut envoyer une requête avec le \ codé en Unicode
http://cible/..%u2216..%u2216repertoire/fichier

Manipulation d'URL:
• De nombreux sites dynamiques passent le nom des pages
à afficher en paramètre sous une forme proche de la
suivante :
http://cible/cgi-bin/script.cgi?url=index.htm
• Pour peu qu'aucun contrôle ne soit réalisé, il est possible
pour un pirate de modifier l'URL manuellement afin de
demander l'accès à une ressource du site auquel il n'a pas
accès directement, par exemple :
http://cible/cgi-bin/script.cgi?url=script.cgi

Manipulation d'URL:
• Récupération de fichiers supposés inaccessibles :
• Requête du type :
www.inria.fr/annuaire.php?nom="../../etc/passwd"
www.inria.fr/annuaire.php?nom="../../../etc/passwd"
www.inria.fr/annuaire.php?nom="../../../…/../etc/passwd"

Manipulation d'URL: Contre-mesures
• Afin de sécuriser un serveur web contre les attaques par
manipulation d'URL, il est nécessaire d'effectuer une veille
sur les vulnérabilités et d'appliquer régulièrement les
correctifs fournis par l'éditeur du serveur web.
• Par ailleurs, une configuration minutieuse du serveur web
permet d'éviter à un utilisateur de naviguer sur des pages
auxquelles il n'est pas censé avoir accès.

Manipulation d'URL: Contre-mesures
• Le serveur web doit ainsi être configuré en suivant les
consignes suivantes :
– Empêcher le parcours des pages situées en dessus 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 ;
– Supprimer les options de configuration superflues;
– S'assurer que le serveur interprète correctement les pages
dynamiques, y compris les fichiers de sauvegarde (.bak) ;
– Empêcher la consultation en mode HTTP des pages accessibles
en HTTPS.

RÉFÉRENCE DIRECTE NON SÉCURISÉE À
UN OBJET
• Une référence directe existe lorsqu’un développeur
affiche une référence vers l’implémentation interne d’un
objet, comme un fichier, un répertoire, un enregistrement
de base de données, une clef comme un paramètre d’un
formulaire ou d’une URL.
• Un attaquant peut alors manipuler directement la
référence à l’objet pour accéder à d’autres objets sans
autorisation, même avec des vérifications de contrôle
d’accès en place.

UN OBJET
• Par exemple, dans une application de banque en ligne, il
est fréquent d’utiliser le numéro de compte comme clef
primaire.
• Il est alors très tentant d’utiliser le numéro de compte
directement dans l’interface Web.
• Même si le développeur a pris soin de prévenir les
injections SQL, si il n’y pas de contrôle d’autorisation en
place pour vérifier que le possesseur d’un compte peut le
lire, un attaquant peut modifier le paramètre de numéro
de compte pour changer ou lire tous les comptes.

• Cause
UN OBJET
– Conception de l’application
• Conséquences
– Accès à des fichiers/répertoire en dehors de l’application
– Accès à des ressources et fonctionnalités d’administration
– Accès à des ressources d’autres utilisateurs
• Périmètre
– Potentiellement toute application
• Exemple
– Accès (lecture/écriture) à des données personnelles concernant des élèves :
javascript:visu(‘1234')  javascript:visu(‘1235')
– Lecture de fichiers du système :
http://www.xxxxxxxxxxx.fr/print.php?PAGE=L2V0Yy9wYXNzd2Q=
avec ‘L2V0Yy9wYXNzd2Q=‘ : /etc/passwd encodé en base64

UN OBJET
• Exemple
– Accès à l’ensemble du système de fichier d’un serveur
– Variable ‘PathToExpand’ : ../../../../../../../../../../

UN OBJET: Protection
• La mise en place d’une méthode de référence aux objets
d'application est importante
– Evitez d'exposer des références d'objet privé aux utilisateurs,
chaque fois que possible, tels les clés primaires ou noms de
fichiers
– Validez sans retenue toutes les références aux objets privés, via
la méthode d'acceptation des bonnes valeurs
– Vérifiez l'autorisation à tous les objets référencés
– Utilisez une valeur d’index ou d’une référence permettant de
prévenir la manipulation du paramètre:
http://www.example.com/application?file=1

Les attaques de vols de session
• L'enjeu des sessions lors d'une connexion à un site web
est de garder en mémoire des informations relatives à
l'utilisateur connecté.
• Si un attaquant réussit à intercepter ou à forger un jeton
de session valide, celui-ci sera en mesure de voler la
session d'un utilisateur légitime.
• Les applications web les plus exposées sont celles qui
utilisent des jetons de session dans l'URL (sans
expiration).
• Pour attaquer de telles applications web, il suffit
simplement d'ouvrir l'historique du navigateur et de
cliquer sur l'URL de l'application
Les attaques de vols de session:
Session Authentication Attacks
• Une des erreurs les plus communes consiste à ne pas contrôler
suffisamment l'authentification avant d'exécuter une fonction
restreinte ou d'accéder à des données confidentielles.
• Un exemple réel particulièrement désastreux fut le cas du site de
l'Australian Taxation Office's GST, site au sein duquel la plupart des
entreprises australiennes déclarent leurs impôts. Le site de l'ATO
utilise un certificat numérique client pour authentifier ses
utilisateurs. Malheureusement, le site utilisait le numéro ABN (un
identifiant unique pour chaque entreprise, une sorte de numéro de
sécurité sociale) dans l'URL.
• Ces numéros ABN ne sont ni secrets ni aléatoires ; chacun peut
librement connaître le numéro ABN d'une entreprise.
• Un utilisateur, ayant remarqué ce numéro ABN dans l'URL, a, tout
simplement, changé ce dernier par celui d'une autre entreprise. A sa
grande surprise, cela a fonctionné. Il a pu lire les informations de
l'autre société.
Attaques par prédiction de session
• En utilisant des jetons de session non robustes, le pirate peut voler la
session d'un autre utilisateur en devinant le cookie de session de sa
victime.
• Celui-ci exploitera les propriétés de votre application pour prédire un
numéro de session valide, ou déjà utilisé, dans le but de contourner
les contrôles d'accès.
• Vous pouvez tester ce point en entrant le session-ID n'importe où, en
dehors d'un cookie de session non persistant. Par exemple, si vous
utilisez PHP, copier un session-ID valide depuis le cookie et insérez le
via l'URL (ou un paramètre POST) de la manière suivante :
http://www.example.com/foo.php?PHPSESSIONID=xxxxxxx
• Si ce rejeu fonctionne, votre application est vulnérable. En particulier
si le session ID reste valide après l'expiration ou la déconnexion de la
session.
La prédiction des numéros de séquence

Les attaques par force brute (bruteforce)
• Certains sites de e-Commerce emploient des numéros de session
consécutifs et facilement prédictibles. Sur ces sites, il est aisé de
modifier son numéro de session pour voler la session d'un autre
utilisateur.
• Dans un tel scénario, toutes les fonctions qui étaient disponibles
pour l'utilisateur piraté, le devienne pour l'attaquant et laissent
libre cours aux tentatives de fraudes et au vol d'informations.
• Vous pouvez vérifier la solidité de vos jetons de session en tentant
une attaque de brute force. Pour cela, ouvrez une session valide
dans un navigateur et utilisez un outil de brute force de session
comme Brutus.
• Si ce dernier est capable de reprendre, plutôt que de " voler ", la
session, votre plateforme de développement nécessite un degré
d'entropie plus élevé pour la génération des jetons de session.
Fixation du numéro de session
• Le pirate consulte le site Web et récupère le numéro de
session qui lui est attribué.
• Il devra ensuite forcer sa victime à s’identifier sur ce même
site Web en utilisant le numéro de session qu’il a reçu (par
Cross Site Request Forgery par exemple).
• Une fois sa victime identifiée, le pirate l’est aussi, puisqu’il a
le même numéro de session.

Le rejeu des jetons de session (replay) : XSS
• Les attaques par rejeu de session sont relativement
simples si l'attaquant a la possibilité de voler le cookie
de session. Ceci se réalise à l’aide d’une attaque « XSS »
ou attaque de Cross Site Scripting.
• L'attaque consiste à trouver un paramètre non filtré
(c'est-à-dire non contrôlé par le serveur web) afin
d'injecter un code Javascript. Une URL sera
spécialement conçue par l'attaquant puis envoyée à la
victime pour que ce dernier suive le lien malveillant.

Le rejeu des jetons de session (replay): XSS
• Une fois que l’attaquant possède le numéro de session
de sa victime, et que la session est encore active sur le
serveur (c’est souvent le cas), il n’a plus qu’à remplacer
son numéro de session par celui de sa victime dans les
requêtes HTTP qu’il envoie au serveur.
• Il est ainsi identifié comme étant l’utilisateur dont il a
volé la session.

Contre-mesures
• Utiliser uniquement des mécanismes de gestion de
sessions intégrés. N’utiliser sous aucun prétexte des
mécanismes secondaires ou faits maison
• N'acceptez pas des identifiants de sessions, nouveaux,
préréglés ou invalides à partir de l’URL ou dans la requête
(« Session Fixation »).
• Limitez ou supprimez de votre code les cookies
personnalisés relatifs à l'authentification ou la gestion de
session
• Utilisez un mécanisme d'authentification unique avec un
niveau de sécurité et un nombre de facteurs appropriés.
Assurez-vous que ce mécanisme n'est pas facilement sujet
au « Spoofing » ou aux attaques par rejeux (Replay
Attacks).
Contre-mesures
• N'autorisez pas le démarrage du processus d'authentification à
partir d'une page non chiffrée. Commencez toujours le processus
d'ouverture de session à partir d'une seconde page chiffrée avec
un nouveau jeton de session afin d'empêcher le vol de session ou
d'informations, les attaques par Phishing ou les attaques de type «
Session Fixation »
• Envisagez de générer un nouveau jeton de session (Token) à
chaque changement d'authentification ou de niveau de privilège
• Assurez-vous que toutes les pages disposent d’un lien de
déconnexion. La déconnexion doit totalement détruire tout état de
session côté serveur et cookies côté client. Considérez aussi le
facteur humain: ne demandez pas confirmation car les utilisateurs
fermeront juste l'onglet ou la fenêtre plutôt que se déconnecter
proprement
• Utiliser une période de timeout qui déconnecte automatiquement
tout utilisateur après une période d'inactivité

Stockage non sécurisé des données
cryptographiques
• La prévention des failles cryptographiques demande une
planification soigneuse. Les problèmes les plus courants
sont :
– Pas de chiffrement des données sensibles
– Utilisation d’algorithmes de chiffrement « maison »
– Utilisation incorrecte d’algorithmes robustes
– Utilisation récurrente d’algorithmes connus pour leurs faiblesses
(MD5, RC3, RC4, etc.)
– Stockage de clés dans des zones non protégées
• Ces vulnérabilités peuvent mener à une divulgation de
données sensibles et à des violations de conformité.

• Exemples:
cryptographiques
- Stockage de mots de passe de comptes applicatifs en clair
- Dans une BDD avec interface Web d’administration
- Login/password de la BDD en clair dans un script !
- Egalement comptes de domaine Windows

- Egalement comptes de messagerie
cryptographiques: Contre-mesures
• Ne pas créer d’algorithmes de chiffrement. Utiliser seulement des
algorithmes reconnus publiquement tels qu’AES, cryptographie à
clé publique RSA, et SHA-256 ou mieux pour la fonction de
hachage
• Ne pas utiliser d’algorithmes faibles, tels MD5 / SHA1. Favoriser
des alternatives plus sûres, comme SHA-256 ou mieux
• Générer les clés hors-ligne et stocker les clés privées avec une
extrême précaution. Ne jamais communiquer les clés privées à
travers des canaux peu sûrs.
• Assurez-vous que l’infrastructure d’accréditations comme les
bases de données d’identités sont correctement sécurisés (via des
permissions et des contrôles renforcés sur le système de fichiers)
• Assurez-vous que les données chiffrées sur disque ne sont pas
faciles à décrypter. Par exemple, le chiffrement de base de
données est inutile si le pool de connexion à la base fournit un
accès non chiffré.
Communications non sécurisées
• Principe
– Accès à des informations sensibles transitant entre deux entités
– Données d’authentification et Données nominatives, de santé,
bancaires…
– Front End, Back End
• Cause
– Pas de chiffrement des (de toutes les) communications
(sniffing)
– Utilisation de mécanismes de chiffrements faibles
(SSLv2)
– Mauvaise utilisation de mécanismes de chiffrement
forts
– Débrayage des fonctions de chiffrements (volontairement ou
non) Formation PIRATAGE ETHIQUE 163
Communications non sécurisées
• Conséquences
– Fuite d’informations sensibles (authentification, données
métiers)
– Non respect des règles de conformité (CNIL, PCI DSS…)
• Exemples
– SSLv2 autorisé
– Authentification en HTTP, login/password en clair
 URL contient : url=%2Findex.php%2Fmod._INDICE
%2Fmem.i%2Ferror.1%2F
chk.24efab3d4c81a36f28f62c738d3de53c.html&user=XXXX
&pass=XXXX

Attaques Web: Protection
• La sécurité au niveau applicatif est indispensable, en plus
de la sécurité au niveau réseau et OS
• La sécurité doit être conçue et implémentée tout au long
du développement de l’application Web
• Un suivi de la sécurité tout au long de la vie de
l’application Web est indispensable (mise en ligne de
nouvelles versions, …)

Contre mesure pour IIS: Server Mask
• Server Mask permet de changer ou enlever tout
entête dans les réponses HTTP
• Ceci permet de changer l’identité de votre serveur
IIS

Contre mesure pour IIS: Server Mask

09 Attaque Web

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

09 Attaque Web

Transféré par

Droits d'auteur :

Formats disponibles

AKHAM Omar

Formation PIRATAGE ETHIQUE 2

Formation PIRATAGE ETHIQUE 3

Formation PIRATAGE ETHIQUE 4

Formation PIRATAGE ETHIQUE 5

Formation PIRATAGE ETHIQUE 6

Formation PIRATAGE ETHIQUE 7

Formation PIRATAGE ETHIQUE 9

Formation PIRATAGE ETHIQUE 10

Formation PIRATAGE ETHIQUE 11

Formation PIRATAGE ETHIQUE 12

Formation PIRATAGE ETHIQUE 13

Formation PIRATAGE ETHIQUE 15

Formation PIRATAGE ETHIQUE 16

Formation PIRATAGE ETHIQUE 18

Formation PIRATAGE ETHIQUE 19

Formation PIRATAGE ETHIQUE 20

Formation PIRATAGE ETHIQUE 21

Formation PIRATAGE ETHIQUE 22

Formation PIRATAGE ETHIQUE 23

Formation PIRATAGE ETHIQUE 24

Formation PIRATAGE ETHIQUE 25

• Les moteurs de recherche principaux considèrent que cette

Formation PIRATAGE ETHIQUE 27

Formation PIRATAGE ETHIQUE 28

Formation PIRATAGE ETHIQUE 30

Formation PIRATAGE ETHIQUE 31

Formation PIRATAGE ETHIQUE 32

Formation PIRATAGE ETHIQUE 33

Formation PIRATAGE ETHIQUE 34

Formation PIRATAGE ETHIQUE 35

Formation PIRATAGE ETHIQUE 36

• L'URL peut permettre de transmettre des

Formation PIRATAGE ETHIQUE 38

Formation PIRATAGE ETHIQUE 39

expires=DATE Date d’expiration du cookie (champ optionnel)

domain=DOMAINE Permet de spécifier le domaine pouvant avoir accès au

secure Champ qui, s’il est mis, envoie le cookie et sa valeur

Formation PIRATAGE ETHIQUE 40

Formation PIRATAGE ETHIQUE 41

Formation PIRATAGE ETHIQUE 42

Formation PIRATAGE ETHIQUE 43

Formation PIRATAGE ETHIQUE 44

Formation PIRATAGE ETHIQUE 45

Formation PIRATAGE ETHIQUE 46

Formation PIRATAGE ETHIQUE 47

Formation PIRATAGE ETHIQUE 50

Formation PIRATAGE ETHIQUE 51

Formation PIRATAGE ETHIQUE 52

Formation PIRATAGE ETHIQUE 53

Formation PIRATAGE ETHIQUE 54

Formation PIRATAGE ETHIQUE 55

Formation PIRATAGE ETHIQUE 56

Formation PIRATAGE ETHIQUE 57

Formation PIRATAGE ETHIQUE 58

Formation PIRATAGE ETHIQUE 59

Formation PIRATAGE ETHIQUE 60

Formation PIRATAGE ETHIQUE 61

Formation PIRATAGE ETHIQUE 63

Formation PIRATAGE ETHIQUE 65

mysql> select table_schema, table_name, table_comment From

Formation PIRATAGE ETHIQUE 67

Formation PIRATAGE ETHIQUE 68