TP2:

Module: Sécurité et développement

Réalisé par : Encadré par

EL KARI Imane Mme. Lamrani Alaoui Rokia

Niveau :
2ème année CCN

Année scolaire : 2024/2025

A-Injection
a. Sql Injection
1-Configurer le niveau de sécurité de dvwa sur low.

2-Cliquer sur lien SQL injection

3-Analyser pourquoi l’application est vulnérable à l’attaque SQL injection
La principale raison de la vulnérabilité est que l'application utilise directement l'entrée de l'utilisateur
(ici la variable $_REQUEST['id']) dans la requête SQL sans aucune validation ou échappement des
caractères spéciaux :

$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

Ce code insère directement la valeur de $_REQUEST['id'] dans la requête SQL. Si un attaquant modifie
la valeur de id dans la requête HTTP, il peut injecter du code SQL malveillant

4-Essayer d’exploiter la vulnérabilité manuellement (sans utiliser les outils de

pentesting) :
 La requête renvoie des informations sensibles, cela signifie que l’entrée utilisateur n’est pas
filtrée avant d’être exécutée par la base de données.

Lorsqu’on fait entrer 1’ OR ‘1’=’1

Lorsque on fait un test de union :

‘UNION SELECT user , password FROM users#

5- Tourner le niveau de sécurité de dvwa à medium et ensuite à high et répondre
aux questions 3-4.
Medium :
L’application commence à utiliser les requêtes préparées ou à filtrer les caractères spéciaux.

A l’aide de la fonction mysqli_real_escape_string() , nous permet d’échapper les caractères spéciaux

d’une chaine de caractère avant de l’utiliser dans une requête sql , permet d’échapper que des
caractère spéciaux comme ‘ et ‘’ mais les requêtes numérisés ne peuvent pas être échappée

On fait inspecter puis on modifie sur la page HTML :

voici le résultat ::
Height :
La vulnérabilité :
Dans le code, l'ID de l'utilisateur est récupéré directement à partir de la session ($_SESSION['id']) et
est inséré directement dans la requête SQL sans aucune validation ou protection appropriée.

$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id' LIMIT 1;";

L’affichage de la requêtes va être en utilisant une autre page au lieu e faire un GET

Exploitation Manuelle :
‘1 UNION SELECT user, password FROM users#
6- Tourner le niveau de sécurité de dvwa à impossible, quel est le contrôle de
sécurité qui a été utilisé pour corriger cette vulnérabilité
 Lorsque la sécurité est réglée sur "Impossible", l’application est totalement protégée.

 Les mesures typiques utilisées incluent :

-Requêtes préparées (Prepared Statements) pour empêcher l’injection SQL.

-Validation stricte des entrées (contrôle de type).

-Limitation des résultats de la requête en une ligne par LIMIT 1 :

 b. Blind SQL injection :
1-configurer le niveau e sécurité de dvwa en low :

2-cliquer sur le lien SQL injection (Blind)

3-essayer de trouver pourquoi l’application est vulnérable à blind SQL
injection :
Absence de validation et d'échappement de l'entrée utilisateur :
L'ID est directement inséré dans la requête SQL sans aucune validation ou échappement :
$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";
Un attaquant peut manipuler cette variable ($id) pour injecter du code SQL malveillant.

Exécution de requêtes SQL avec un paramètre utilisateur non sécurisé :

Le fait que l'ID soit directement inséré dans la requête SQL permet à un attaquant de
passer un payload SQL, comme par exemple :
1 OR 1=1

4- essayer d’exploiter la vulnérabilité manuellement :

5-On tourne le niveau de sécurité en medium
Medium :
La vulnérabilité :

Le code utilise directement la variable $id (provenant de $_POST['id']) dans la

requête SQL sans appliquer une validation suffisante. La ligne suivante est
particulièrement problématique :

$query = "SELECT first_name, last_name FROM users WHERE user_id = $id;";

Même si la fonction mysqli_real_escape_string est utilisée pour échapper la

valeur de l'entrée $id, cela ne protège pas complètement contre les attaques
d'injection SQL.
Pourquoi cette solution est insuffisante (vulnérabilité) ?

Bien que mysqli_real_escape_string soit une méthode pour empêcher certaines

attaques de type injection SQL en échappant les caractères spéciaux, elle ne
suffit pas à elle seule à protéger contre toutes les formes d'injections SQL. Cela
est particulièrement vrai lorsque la donnée utilisateur est directement insérée
dans une requête SQL sans être correctement paramétrée.

Heigh :
La vulnerabilite :

Le code utilise la valeur $_COOKIE['id'] pour interroger la base de données

et vérifier si un utilisateur existe dans la table users en fonction de son
user_id. Cependant, il insère directement cette valeur dans la requête SQL
sans aucune protection, ce qui permet à un attaquant d'exploiter cette
entrée et de manipuler la requête SQL.

$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id'

LIMIT 1;";
6. Tourner le niveau de sécurité de dvwa à impossible, quel est le contrôle de
sécurité qui a été utilisé pour corriger cette vulnérabilité.

1. Validation de l'entrée utilisateur : Vérifie si `id` est un nombre valide avec

`is_numeric()` et le convertit en entier avec `intval()`.

- Où : Juste après l'obtention de la valeur `$_GET['id']`.

```php
if(is_numeric($id)) {
$id = intval($id); // Convertit l'ID en entier
}

```

2. Utilisation de requêtes préparées avec des paramètres liés: Utilisation de requêtes

préparées avec des paramètres liés (PDO pour MySQL, SQLite3 pour SQLite), ce qui
empêche l'injection de code SQL malveillant.
- Où : Lors de l'exécution de la requête SQL pour MySQL et SQLite.

```php
$data = $db->prepare('SELECT first_name, last_name FROM users WHERE user_id =
(:id) LIMIT 1;');

$data->bindParam(':id', $id, PDO::PARAM_INT);

 $data->execute();
```

3. Vérification de l'existence de l'utilisateur : Vérifie si un utilisateur existe en utilisant

`rowCount()` pour MySQL et un compteur de lignes pour SQLite, empêchant ainsi
l'exposition de données sensibles.
- Où: Après l'exécution de la requête.
```php
$exists = $data->rowCount(); // Vérifie le nombre de lignes retournées
```

4. Retour d'une réponse 404 en cas d'utilisateur inexistant : Envoie une erreur 404
pour ne pas divulguer si un utilisateur existe dans la base de données.
- Où : Si l'utilisateur n'existe pas.
```php
header($_SERVER['SERVER_PROTOCOL'] . ' 404 Not Found');
```

Ces corrections empêchent l'injection SQL en validant les entrées et en utilisant des
requêtes préparées avec des paramètres liés. Cela protège contre les attaques SQL
Injection aveugles.

c. l’attaque XSS(REFLECTED) :
1-configurer le niveau e sécurité de dvwa en low :
2-Cliquer sur le lien XSS(REFLECTED)
3-Essayer de trouver pourquoi lapplication est vulnerable a l’attaque XSS
(reflected)

 Désactivation de la protection contre XSS :

header ("X-XSS-Protection: 0");
Cette ligne désactive la protection contre les attaques XSS que
certains navigateurs modernes offrent. Cela rend le site plus
vulnérable aux attaques XSS.
 Lecture du paramètre "name" :
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL )
{
 Le code vérifie si un paramètre name est passé dans l'URL (exemple
: [Link] Si le paramètre existe et qu'il
n'est pas vide, il continue.
 Affichage du paramètre sans validation ni échappement :
echo '<pre>Hello ' . $_GET[ 'name' ] . '</pre>';
Le code affiche directement la valeur de $_GET['name'] dans la page
HTML. Si un utilisateur fournit un code JavaScript malveillant dans ce
paramètre, ce script sera exécuté dans le navigateur de la victime.
Conclusion :
- L'attaque *Reflected XSS* se produit lorsque le site prend un paramètre envoyé par
l'utilisateur (comme name dans ce cas) et l'affiche directement sans le nettoyer ou
l'échapper.
- Un attaquant pourrait alors manipuler l'URL pour inclure du code JavaScript malveillant
dans le paramètre name, comme ceci :

4-essayer d’exploiter manuellement l’attaque :

On écrit un script javascript :
<script>alert(‘’your are hacked’’)
<script>alert([Link])</script>

5-on change le niveau de sécurité :

Niveau medium :
On a écrit cette commande :
<Script>alert(‘’your are hacked’’)</Script>
  Remplacement de <script> :
$name = str_replace( '<script>', '', $_GET[ 'name' ] );

Cette ligne essaie de supprimer uniquement les balises <script> dans l'entrée
de l'utilisateur. Cependant, il ne supprime pas toutes les balises de script
possibles ni d'autres vecteurs d'attaque potentiels. Par exemple, le code ne
prend pas en compte les balises <script> en majuscules (<SCRIPT>, <ScRiPt>,
etc.)

Niveau height :
On essaye de trouver pourquoi l’appli est vulnérable :

Filtrage insuffisant des balises <script> :

Problème : L'expression régulière utilisée ici essaie de supprimer les balises
<script> dans le paramètre name. Cependant, elle a corrige une faiblesse et a
laisse une autre :
 Elle gère toutes les variations possibles de la balise <script> : Par
exemple, <SCRIPT>, <ScRiPt>, ou encore les variations de casse comme
<ScRiPt> seront supprimées grâce au modificateur i , pour qu’il ne soit
pas sensible a la casse .
  Elle ne protège pas contre d'autres types d'injection JavaScript :
L'attaque XSS peut être réalisée en injectant du code JavaScript dans des
événements HTML dans des balises comme <img>, <a>, ou <div>.

-On exploite la vulnérabilité :

On fait entrer ce code :
<img src=x onerror=alert(“flacon”)>

6-Tourner le niveau de sécurité de dvwa à impossible, quel est le contrôle de

sécurité qui a été utilisé pour corriger cette vulnérabilité.
1. Contrôle de sécurité Anti-CSRF (Cross-Site Request Forgery)
Code ajouté :
checkToken($_REQUEST['user_token'], $_SESSION['session_token'], '[Link]');

- But : Cette ligne ajoute un mécanisme de vérification de token CSRF pour s'assurer que la
requête provient bien d'un utilisateur authentique et non d'un attaquant. Elle vérifie que le
token CSRF (associé à l'utilisateur) envoyé dans la requête ($_REQUEST['user_token'])
correspond au token de session stocké dans $_SESSION['session_token']. Si ce token ne
correspond pas, l'attaque CSRF est rejetée et l'utilisateur est redirigé vers la page spécifiée
(ici, '[Link]').

2. Protection contre XSS avec htmlspecialchars():

- Code ajouté:
$name = htmlspecialchars($_GET['name']);
Le code applique htmlspecialchars() à la variable $_GET['name'] avant de l'afficher. Cette
fonction échappe les caractères spéciaux (<, >, &, ", ') en leurs entités HTML
correspondantes, ce qui empêche l'exécution de tout code JavaScript ou HTML malveillant
qui pourrait être injecté par un attaquant.
 d. Attaque XSS (Stored) :
1-on configure le niveau de sécurité LOW

2-On clique sur XSS(Stored) :

3-on essaye de trouver pourquoi l’application est vulnérable à l’attaque :

Absence d'échappement des données lors de l'affichage : Les données de l'utilisateur
($_POST['mtxMessage'] et $_POST['txtName']) sont insérées dans la base de données sans
être échappées pour empêcher l'exécution de code HTML ou JavaScript. Lors de l'affichage
de ces données, si elles contiennent des scripts malveillants, ces derniers seront exécutés
dans le navigateur de l'utilisateur, entraînant une vulnérabilité XSS (Cross-Site Scripting)
stockée

4-On exploite manuellement :

5- niveau medium :
La vulnérabilité :

1.Échappement incomplet des données : Le code utilise htmlspecialchars() pour

nettoyer l'entrée utilisateur, mais cette fonction ne protège pas entièrement
contre les attaques XSS. Elle empêche l'exécution de certaines balises HTML,
mais elle peut être contournée dans certains contextes (par exemple, dans des
attributs HTML ou du JavaScript). Donc, un attaquant pourrait insérer un script
malveillant qui sera exécuté lorsque la page est affichée.

[Link] de validation stricte des données : Le code se contente de nettoyer

les entrées avec htmlspecialchars() et mysqli_real_escape_string(), mais il ne
vérifie pas réellement si les données contiennent des éléments dangereux
comme des balises <script> ou des événements JavaScript (par exemple
onmouseover="...").

L’exploitation manuelle :
Lorsqu’on configure medium et en retourne a la page XSS(Stored) voici ce que s’affiche :
Le niveau height :
La vulnérabilité :

Le code utilise une requête SQL non préparée avec des valeurs directement
insérées dans la chaîne de la requête :
$query = "INSERT INTO guestbook ( comment, name ) VALUES ( '$message',
'$name' );";
Bien que mysqli_real_escape_string() soit utilisé pour échapper certaines
entrées, cela ne protège pas complètement contre les attaques d'injection SQL.
Si l'attaquant parvient à injecter des caractères malveillants dans les variables
$message ou $name, la requête pourrait être manipulée de manière
malveillante (par exemple, en fermant la chaîne de la requête et en ajoutant du
code SQL supplémentaire).

6. Quel est la corrections de cette vulnérabilité dans la partie

impossible pour la sécurité :

Protection contre les attaques XSS (Cross-Site Scripting) :

- Échappement de l'entrée utilisateur avec htmlspecialchars():
php
$message = htmlspecialchars( $message );
$name = htmlspecialchars( $name );

Le code utilise htmlspecialchars() pour échapper certains

caractères spéciaux dans les champs message et name. Cela permet
de prévenir l'injection de balises HTML ou de JavaScript dans la page,
car cette fonction convertit les caractères comme <, >, " et ' en leurs
entités HTML respectives, empêchant l'exécution de code malveillant
côté client.
3. Échappement de l'entrée pour la base de données avec
mysqli_real_escape_string() :
- Prévention de l'injection SQL :
php
$message =
mysqli_real_escape_string($GLOBALS["___mysqli_ston"], $message);
$name = mysqli_real_escape_string($GLOBALS["___mysqli_ston"],
$name);

Bien que cette mesure soit principalement pour éviter l'injection

SQL, elle aide indirectement à sécuriser l'entrée des utilisateurs en
échappant les caractères spéciaux susceptibles de perturber une
requête SQL, comme les guillemets, les apostrophes, et d'autres
caractères pouvant être utilisés pour manipuler la syntaxe SQL.

4. Utilisation des requêtes préparées avec PDO:

- Requête préparée pour éviter l'injection SQL :
php
$data = $db->prepare( 'INSERT INTO guestbook ( comment, name )
VALUES ( :message, :name );' );
$data->bindParam( ':message', $message, PDO::PARAM_STR );
$data->bindParam( ':name', $name, PDO::PARAM_STR );
$data->execute();
L'utilisation de requêtes préparées avec paramètres liés est un
contrôle de sécurité important pour se protéger contre les attaques
d'injection SQL. Les données sont automatiquement échappées et
traitées en toute sécurité par la base de données, ce qui garantit que
les valeurs envoyées par l'utilisateur ne peuvent pas interférer avec la
structure de la requête SQL.

e. Attaque XSS(DOM) :
Introduction :
Le DOM XSS (Document Object Model Cross-Site Scripting) est une vulnérabilité de sécurité
web où des attaquants peuvent injecter du code malveillant (généralement du JavaScript)
directement dans le DOM (Document Object Model) d'une page web. Contrairement aux
attaques XSS classiques qui exploitent des failles côté serveur, le DOM XSS se produit côté
client, dans le navigateur de l'utilisateur.
Dans une attaque DOM XSS, un attaquant profite de l'interaction entre l'utilisateur et la page
web. Par exemple, l'attaquant peut manipuler les paramètres d'URL ou les entrées d'un
formulaire pour injecter du code malveillant dans le DOM, sans que le serveur n'en soit
forcément responsable. Ce code malveillant peut ensuite être exécuté par le navigateur,
compromettant la sécurité de l'utilisateur (vol de données, redirection vers des sites
malveillants, etc.).

Le DOM XSS survient principalement lorsqu'un site web utilise mal des fonctions JavaScript
qui manipulent le DOM (comme innerHTML, [Link], ou eval). Ces fonctions
peuvent être vulnérables si elles ne filtrent pas correctement les données fournies par
l'utilisateur.

3. Essayer de trouver pourquoi l’application est vulnérable à l’attaque d’injection

de commande
1. Absence de validation des entrées :
o Le paramètre default dans l'URL est pris directement par
l'application sans être validé. Cela signifie qu'il peut
contenir n'importe quelle donnée, y compris des scripts
JavaScript.
2. Absence d'encodage des données :
o Il n'y a aucune indication que l'application échappe ou
encode les caractères spéciaux (comme <, >, &, etc.) qui
pourraient être interprétés comme du code HTML ou
JavaScript. Ces caractères doivent être échappés pour
empêcher l'injection de code malveillant.
3. Insertion directe de données dans le DOM :
o L'application semble insérer les données entrantes
directement dans le DOM (dans la page HTML ou le
JavaScript côté client). Le DOM interprète ce contenu
comme du HTML ou du JavaScript, et le code malveillant
s'exécute dans le navigateur de l'utilisateur.
4. Manque de protection contre les scripts externes :
o Si l'application autorise l'injection de données sans les
valider, elle devient vulnérable aux attaques de type XSS.
Dans une application sécurisée, les entrées utilisateur
doivent être correctement filtrées ou échappées avant
d'être utilisées dans des contextes sensibles comme le
DOM ou JavaScript.

4. Essayer d’exploiter la vulnérabilité manuellement (sans utiliser les outils

de pentesting)
 Ici on a exploité la vulnérabilité avec un code javascript

5. Tourner le niveau de sécurité de dvwa à medium et ensuite high et répondre

aux questions 3-4.
Medium :

Explication du code
Le code vérifie si un paramètre default existe dans l'URL via
$_GET['default']. Si le paramètre est présent et non nul, il est stocké
dans la variable $default. Ensuite, le code tente d'empêcher
l'exécution de JavaScript en vérifiant si la chaîne contient le mot
"<script" (indiquant une tentative d'injection de balise <script>). Si
cette chaîne est trouvée, l'utilisateur est redirigé vers une version
sécurisée avec le paramètre default=English.
Pourquoi la solution est insuffisante
La tentative de filtrage en utilisant stripos($default, "<script") !==
false pour interdire les balises <script> est insuffisante pour plusieurs
raisons :
1. Filtrage incomplet : Le filtrage ne supprime que la chaîne exacte
<script>, mais un attaquant peut contourner cette restriction en
utilisant différentes variations d'injection JavaScript qui ne
contiennent pas directement les balises <script>. Par exemple,
des techniques comme l'évasion de la balise ou l'utilisation
d'autres attributs d'événements HTML peuvent permettre
d'exécuter du code JavaScript.
2. Injections via d'autres balises HTML : L'attaquant peut injecter
un autre type d'élément HTML qui contient un événement
JavaScript. Par exemple, l'injection d'une balise <img> avec un
attribut onerror permet d'exécuter du code JavaScript lorsque
l'image échoue à se charger (comme dans l'exemple fourni dans
le spoiler).
Exploitation manuelle (dans l’URL) :
Ici on a exploité la vulnérabilité avec un code html
Height :

Pourquoi la vulnérabilité XSS DOM existe-t-elle malgré le niveau de

sécurité élevé ?
1. Filtrage côté serveur insuffisant : Le code met en place une liste
blanche des langues (French, English, German, Spanish), ce qui
signifie que seules ces valeurs sont autorisées dans le paramètre
default. Cependant, la sécurité est uniquement effectuée côté
serveur.
2. Le fragment d'URL (tout ce qui suit le #) n'est pas envoyé au
serveur : La vulnérabilité vient du fait que le fragment d'URL,
tout ce qui suit le # (par exemple #<script>alert(1)</script>),
n'est pas envoyé au serveur. Cela signifie que même si le
serveur bloque certaines entrées dans le paramètre default, ce
qu'un utilisateur ajoute après le # dans l'URL ne sera pas
contrôlé par le serveur.
3. Utilisation du fragment d'URL dans le JavaScript côté client : Le
code JavaScript (qui n'est pas montré dans l'exemple, mais qui
est probablement présent dans l'application) lit probablement
le contenu du fragment d'URL (le texte après le #) et l'affiche ou
l'utilise d'une manière ou d'une autre pour générer
dynamiquement la page. Par exemple, il peut utiliser
[Link] ou un équivalent pour obtenir ce contenu
et l'injecter dans le DOM sans effectuer de validation ou
d'échappement correct.

Exploitation manuel :
Ici on a fait un # avant le code javascript
 6. Tourner le niveau de sécurité de dvwa à impossible, quel est le contrôle de
sécurité qui a été utilisé pour corriger cette vulnérabilité.

Mécanisme de Sécurité Utilisé : Encodage Automatique par le

Navigateur
L'indication suggère que les navigateurs modernes protègent contre
l'exécution de scripts malveillants en encodant les contenus de l'URL
par défaut. Cela signifie que, lorsque le navigateur traite les données
provenant de l'URL (comme les paramètres de requête), il encode les
caractères spéciaux (tels que <, >, &, etc.) pour éviter que des balises
HTML ou des scripts ne soient interprétés comme du code
exécutable.
Explication du Comportement du Navigateur
Les navigateurs modernes utilisent un comportement de protection
par défaut qui consiste à encoder certains caractères spéciaux dans
l'URL, ce qui empêche l'exécution de JavaScript malveillant lorsqu'il
est injecté via des paramètres d'URL ou des fragments d'URL. Par
exemple :
 Les symboles < et > sont encodés respectivement en %3C et
%3E.
 Les guillemets (") et autres caractères spéciaux sont également
encodés pour empêcher qu'ils ne soient interprétés comme des
balises HTML ou des attributs JavaScript.
Ce mécanisme est automatique et fait partie des mesures de sécurité
des navigateurs modernes pour se protéger contre les attaques XSS.
f. Remote code execution :
3. Essayer de trouver pourquoi l’application est vulnérable à une RCE

1. Utilisation de shell_exec avec une entrée utilisateur non validée : Le code utilise la
fonction PHP shell_exec() pour exécuter des commandes système (dans ce cas, ping)
en fonction de l'entrée de l'utilisateur ($_REQUEST['ip']). La valeur de cette entrée est
directement incluse dans la commande exécutée sans aucune validation ou
assainissement préalable.
Cela signifie qu'un attaquant peut manipuler cette entrée pour injecter des commandes
arbitraires et les exécuter sur le serveur.
2. Absence de validation des entrées utilisateur : Le code ne valide pas correctement
ou n'assainit pas l'entrée utilisateur. Par exemple, un attaquant pourrait soumettre
une adresse IP comme [Link] && dir, ce qui permettrait d'exécuter la commande
dir (sous Windows) après la commande ping, ou toute autre commande que
l'attaquant choisit.
3. Commande injectée via && : Le mécanisme permettant d'enchaîner plusieurs
commandes dans les systèmes UNIX et Windows avec && ou ; est exploité dans
l'attaque. Par exemple :
o Sur un système Windows : [Link] && dir
Cela permet à un attaquant d'exécuter une commande supplémentaire après la commande
ping

[Link] d’exploiter la vulnérabilité manuellement (sans utiliser les outils de pentesting)

PING [Link] ([Link]) 56(84) bytes of data :

Cela montre que le ping est effectué sur l'adresse [Link], qui est l'adresse de loopback
(localhost). La taille du paquet envoyé est de 56 octets, mais le paquet total (avec l'en-tête) fait 84
octets.

64 bytes from [Link]: icmp_seq=1 ttl=64 time=0.037 ms :

Cette ligne indique que le premier paquet envoyé (icmp_seq=1) a été reçu avec succès depuis
l'adresse [Link].

ttl=64 signifie le "Time To Live" (TTL) du paquet, qui est une valeur indiquant le nombre maximal de
sauts (routeurs) qu'un paquet peut faire avant d'être rejeté. Un TTL de 64 est courant sur de
nombreuses machines.

time=0.037 ms indique que le temps de réponse du paquet est de 0,037 millisecondes (très rapide,
ce qui est attendu pour une adresse locale).

Les lignes suivantes montrent les mêmes informations pour les paquets 2, 3 et 4 :
 Les paquets suivants sont également envoyés et reçus avec des temps de réponse similaires,
variant légèrement entre 0.034 ms et 0.060 ms, ce qui est normal.

5. Tourner le niveau de sécurité de dvwa à medium et ensuite à high et répondre

aux questions 3-4.

Niveau medium :

Le code prend un paramètre utilisateur $_REQUEST['ip'] qui est utilisé dans une commande
ping pour tester la connectivité d'une adresse IP. La sécurité tente d'éliminer certains
caractères comme && et ; dans l'entrée utilisateur, afin d'empêcher la possibilité d'exécuter
des commandes supplémentaires. Cependant, ces mesures sont insuffisantes pour prévenir
une injection de commande.
Pourquoi cette application est vulnérable ?
 1. Filtrage insuffisant : Le code tente de filtrer les caractères && et ;, qui sont souvent
utilisés pour enchaîner des commandes dans un terminal (par exemple, && permet
d'exécuter une autre commande si la précédente réussit, et ; permet de séparer les
commandes). Mais, il existe de nombreuses autres façons de contourner cette
filtration, ce qui laisse des failles.
Par exemple :
o Le caractère | (pipe) peut être utilisé pour rediriger la sortie d'une commande
vers une autre commande.
o Le caractère backtick (`) peut être utilisé pour exécuter des commandes.
o Des techniques comme le & seul ou d'autres caractères spéciaux spécifiques
au système peuvent aussi contourner les protections.
2. Utilisation de shell_exec() : L'appel à shell_exec() permet d'exécuter des commandes
du système d'exploitation, et il est directement vulnérable à des injections de
commande, en particulier si les entrées utilisateur ne sont pas entièrement filtrées ou
validées. Bien que le code tente de limiter certaines commandes, il ne prend pas en
compte d'autres vecteurs d'attaque.
3. Systèmes d'exploitation différents : Le code vérifie l'OS de la machine
(php_uname('s')) et adapte la commande ping pour Windows ou Unix. Cela crée une
situation où une exploitation spécifique à un système d'exploitation peut se produire
si les filtres ne couvrent pas tous les cas d'usage.
4. Utilisation de ping : L'attaquant pourrait potentiellement utiliser la commande ping
pour exécuter une commande système en arrière-plan. Par exemple :
o Sur les systèmes Unix, la commande ping permet à un attaquant d'exécuter
des commandes supplémentaires avec un caractère de redirection comme &.
Par exemple, si l'attaquant passe une entrée comme [Link] && ls, cela
pourrait exécuter la commande ls après la commande ping.

Exploitation manuelle :
On utilise une seul &
-Injecter une pipe pour rediriger la sortie de la commande ping vers une autre
commande :
Niveau height :
Pourquoi l'application est vulnérable ?
1. Filtrage Incomplet (Blacklisting) : Bien que le développeur ait mis en place une liste
noire de certains caractères dangereux (||, &, ;, etc.), cette méthode reste
insuffisante. En effet, une liste noire est généralement une méthode inefficace de
sécurisation, car les attaquants peuvent trouver des moyens de contourner ces filtres
avec des caractères non spécifiés dans la liste.
Par exemple, la commande ping peut encore être manipulée à travers des techniques
comme :
o L'utilisation de backticks (`), qui exécutent des commandes arbitraires.
o L'utilisation de redirections (>, 2>&1, etc.) qui peuvent être ignorées par le
filtre.
2. Le problème avec trim() : Le trim() est utilisé pour supprimer les espaces de début et
de fin de la variable $target. Cependant, cela ne supprime pas les espaces internes et
 ne protège pas contre l'injection de commandes. Les espaces internes dans l'adresse
IP sont conservés, ce qui pourrait permettre des attaques en utilisant des espaces
pour séparer les commandes.
Par exemple, un attaquant pourrait envoyer un input comme [Link] && ls, où les espaces
ne sont pas supprimés par trim(), mais le filtrage ne supprime pas la commande &&. Bien
que l'espacement semble être un détail mineur, il pourrait permettre à l'attaquant d'exécuter
des commandes supplémentaires.
3. Échec de la gestion des caractères de contrôle : Bien que les caractères comme &, ;,
et | soient supprimés, il reste des caractères et des syntaxes qui peuvent être utilisés
pour contourner les restrictions, comme le backtick (`) pour l'injection de
commandes dans un sous-processus.
4. Shell execution (shell_exec) : L'utilisation de la fonction shell_exec() pour exécuter la
commande système ping constitue une vulnérabilité potentielle sérieuse. Même avec
les filtres appliqués, la fonction shell_exec() permet toujours l'exécution de
commandes arbitraires si l'input n'est pas correctement validé. Il existe plusieurs
techniques qui permettent de contourner le filtrage partiel.
Exploitation Manuelle de la Vulnérabilité :

Solutions pour sécuriser l'application :

 Utiliser des fonctions sécurisées pour valider l'entrée (par exemple, une validation
stricte pour s'assurer que $_REQUEST['ip'] contient uniquement des adresses IP
valides et pas d'autres caractères).
 Remplacer shell_exec() par des fonctions sécurisées comme fsockopen() ou d'autres
outils PHP pour interroger des services réseau.
 Revoir et étendre le filtrage des caractères pour bloquer tous les caractères
potentiellement dangereux, pas seulement ceux mentionnés dans la liste noire.
 Implémenter une gestion stricte des entrées avec des expressions régulières et un
nettoyage des données avant toute exécution.

On tourne le niveau de securite en impossible , quel est le contrôle de securite qui a été
utilise pour corriger cette vulnerabilite ;
6. Tourner le niveau de sécurité de dvwa à impossible, quel est le contrôle de
sécurité qui a été utilisé pour corriger cette vulnérabilité.

le contrôle de sécurité qui a été utilisé pour corriger cette vulnérabilité :

Explication du "White Listing" (Liste Blanche) :
Le niveau impossible utilise un principe de liste blanche (ou whitelisting), qui est une
approche beaucoup plus stricte que la liste noire. Dans une approche de liste blanche, on
spécifie exactement quels types de valeurs sont autorisées, et toute autre entrée est rejetée.
Cela contraste avec la liste noire, où l'on tente de filtrer certains caractères ou patterns (ce
qui peut laisser des failles).
Les contrôles de sécurité utilisés dans ce niveau :
1. Validation de l'IP via "White Listing" :
o Séparation de l'IP en 4 octets : Le code utilise explode(".", $target) pour
diviser l'IP en 4 parties.
o Vérification que chaque octet est un nombre entier valide :
 is_numeric($octet[0]), is_numeric($octet[1]), etc., garantissent que
chaque partie de l'adresse est numérique.
 La validation vérifie également que l'IP contient exactement quatre
octets (sizeof($octet) == 4).
  Cette validation garantit que l'IP est bien une adresse IPv4 standard.
Toute tentative d'entrer des valeurs non numériques ou mal formatées
(par exemple [Link].1 ou 127.0.1) échouera.
Résultat de la validation :
o Si l'adresse IP fournie ne respecte pas strictement ce format, elle sera rejetée,
empêchant ainsi toute tentative d'injection de commande via l'entrée de
l'utilisateur. Ce contrôle est très strict et permet de n'accepter que des
adresses IPv4 classiques, tout en rejetant les entrées malveillantes ou mal
formatées.
2. Exécution sécurisée de la commande ping :
o Une fois l'IP validée (en tant qu'adresse IPv4), la commande ping est exécutée.
o Le contrôle de sécurité ici repose sur le fait que seule une adresse IP valide et
correctement formatée pourra être utilisée dans la commande. Ainsi, des
tentatives d'injection comme [Link] && ls ou [Link]; cat /etc/passwd
échouent, car ces caractères et commandes ne peuvent pas être contenus
dans une adresse IPv4 valide.
3. L'usage de stripslashes() :
o Bien que ce ne soit pas la mesure principale ici, stripslashes() est utilisé pour
enlever les antislashes (\) de l'entrée, ce qui peut aider à se protéger contre
certaines formes d'injection liées à des caractères échappés. Cependant, ce
contrôle est secondaire par rapport à la validation stricte de l'IP.

g. Remote /Local File Inclusion (LFI/RFI);

Low

Ce code est vulnérable à une attaque de Local File Inclusion (LFI) car il permet à un utilisateur de
spécifier un fichier via le paramètre page sans aucune validation. Un attaquant peut exploiter cette faille
pour accéder à des fichiers sensibles du serveur, comme /etc/passwd, en manipulant l’URL

4. Essayer d’exploiter la vulnérabilité manuellement (sans utiliser les outils de

pentesting)
5. Tourner le niveau de sécurité de dvwa à medium et ensuite à high et répondre
aux questions 3-4.
 Medium

Ce code récupère un fichier via le paramètre page, puis tente de filtrer certaines valeurs pour empêcher
l’inclusion de fichiers externes ([Link] [Link] et la navigation vers des répertoires parents (../, ..\).
Cependant, il reste vulnérable à une attaque de Local File Inclusion (LFI) car la validation est
insuffisante. Un attaquant peut contourner le filtre en utilisant des encodages alternatifs (....// au lieu de
../) ou en exploitant des fichiers accessibles dans le répertoire cible. De plus, l’absence d’une liste
blanche permet toujours d’inclure des fichiers internes sensibles du serveur, exposant ainsi des données
critiques.

 High

Ce code est vulnérable à Local File Inclusion (LFI) car il permet d’inclure des fichiers sans validation
stricte du chemin. L’attaque est possible car l’attaquant peut manipuler $_GET['page'] pour inclure des
fichiers du serveur, tant qu’ils commencent par "file" ou sont nommés [Link]
Remarque : Le préfixe file:// est une URL qui permet d'accéder à des fichiers locaux sur le système où
le serveur est exécuté.

6. Tourner le niveau de sécurité de dvwa à impossible, quel est le contrôle de

sécurité qui a été utilisé pour corriger cette vulnérabilité.

Ce code n'est pas vulnérable car il utilise un tableau de fichiers autorisés ($configFileNames) et vérifie
si le fichier demandé est dans cette liste. Cela empêche l'inclusion de fichiers non spécifiés ou externes.
Ainsi, même si un attaquant tente d'inclure un fichier malveillant via LFI, il sera rejeté.

7. Si un attaquant exploite la vulnérabilité RFI, est-ce qu'il pourra exécuter n'importe quelle
commande sur le serveur ? Pourquoi ?

Réponse :
Si un attaquant exploite une vulnérabilité RFI (Remote File Inclusion), il peut inclure un
fichier malveillant distant dans l'application, ce qui peut potentiellement lui permettre
d'exécuter du code PHP malveillant sur le serveur cible. Cependant, cela dépend de plusieurs
facteurs :
 Exécution du code distant : Si le serveur permet l'inclusion de fichiers distants et si la
configuration PHP autorise l'exécution de fichiers PHP distants (allow_url_include
activé), l'attaquant peut effectivement exécuter des commandes via le fichier
malveillant qu'il inclut. Le fichier malveillant pourrait contenir des commandes PHP
ou des scripts qui seront exécutés sur le serveur.
  Limitation : Si la configuration du serveur interdit l'exécution de fichiers distants (par
exemple, si allow_url_include est désactivé), l'attaquant ne pourra pas exécuter de
commandes arbitraires, mais pourrait peut-être quand même exploiter d'autres
vulnérabilités, comme la désérialisation ou l'injection de code.
En résumé, l'attaquant peut exécuter des commandes si le serveur est mal configuré pour
autoriser l'inclusion de fichiers distants et si ces fichiers contiennent du code exécutable.
8. Si un attaquant exploite la vulnérabilité LFI, est-ce qu'il pourra afficher le contenu du
fichier /etc/shadow par exemple ? Pourquoi ?
Si un attaquant exploite une vulnérabilité LFI (Local File Inclusion), il peut inclure des fichiers
locaux du serveur, comme des fichiers de configuration ou des fichiers système sensibles.
Concernant le fichier /etc/shadow, l'attaquant pourrait théoriquement l'afficher si le serveur
est mal configuré.cqr:

 Accès aux fichiers locaux : LFI permet à l'attaquant d'inclure des fichiers locaux en
manipulant les paramètres d'entrée (par exemple, en envoyant une URL comme
?page=../../../../etc/shadow). Si le serveur n'a pas de protections adéquates (comme
une validation stricte des entrées), l'attaquant peut inclure des fichiers sensibles
comme /etc/shadow.
 Contenu du fichier /etc/shadow : Le fichier /etc/shadow contient des informations
sensibles telles que les mots de passe chiffrés des utilisateurs. Si l'attaquant parvient
à inclure ce fichier via LFI, il pourrait afficher son contenu, ce qui lui permettrait de
tenter de casser les mots de passe des utilisateurs.
 Conditions : L'accès à des fichiers sensibles comme /etc/shadow dépend aussi des
permissions du serveur et des configurations de sécurité. Par exemple, si le serveur
est configuré pour restreindre l'accès à ces fichiers ou si le processus web s'exécute
avec des privilèges limités, l'attaquant pourrait ne pas être en mesure de lire ces
fichiers.
En résumé, l'attaquant pourrait afficher le contenu du fichier /etc/shadow si le serveur
permet l'accès à ce fichier via LFI et si les protections ne sont pas adéquates.

B- Broken Access Control (contrôle d’accès défaillant) Identifiez des

éléments qui montrent que l’application DVWA ne gère pas
correctement les contrôles d’accès:
- Est ce que vous pouvez accéder à des pages sans être connecté ?
 Non on peut pas accéder à des pages si on se connecte pas

- Est ce que vous pouvez vous connecter à l’application avec un identifiant de session volé
(sans saisir le login et mdp) :

On fait coller ce code ans la même place après le log out et l’ouverture d’une autre anglet :

On copie la valeur du premier PHPSESSID dans la valeur de deuxieme et on remarque qu’on ne peut
pas accéder au site
- Est ce que c’est possible de manipuler des paramètres dans les URL et accéder à des
informations d’un autre utilisateur (IDOR)
Par défaut, l'interface de DVWA ne montre pas explicitement une vulnérabilité de type IDOR, car
aucune page contenant un paramètre 'id' facilement manipulable n'est directement visible ou
accessible.

C- Security Misconfiguration (mauvaise configuration de sécurité)

Identifiez des éléments qui montrent qu’il y a des failles dans la
configuration de sécurité de l’application DVWA:
- Consulter les fichiers de configuration de apache et PHP, et identifier les
paramètres/directives de sécurité qui sont absents.
On fait nano /var/www/hrtml/DVWA/[Link]

Les directives de sécurité absentes ou mal configurées sont la désactivation de allow_url_fopen et

allow_url_include, qui devraient être désactivées pour éviter l'inclusion de fichiers distants. De plus,
magic_quotes_gpc est obsolète et n'assure pas une protection efficace contre les injections.

- Est ce que l’application permet l’affichage d’erreur détaillé sur le navigateur

On fait : nano /var/log/apache2/[Link]

- Est ce que l’application utilise des comptes par défaut

Oui
Nom d'utilisateur : admin
Mot de passe : password
D- Identification and authentication Failures Mauvaise gestion de
session:
1. Configurer le niveau de sécurité de dvwa sur low.
2. Cliquer sur lien weak session ID

3. Essayer de trouver pourquoi l’application ne gère pas correctement les sessions

Analyse du code low :

Problème :
 L’ID de session est simplement un entier incrémenté.
 Cela le rend entièrement prévisible.

 Un attaquant peut essayer successivement les valeurs 1, 2, 3, etc., pour hijacker les
sessions

4. Essayer d’exploiter la vulnérabilité manuellement (sans utiliser les outils de pentesting)

[Link] le niveau de sécurité de dvwa à medium et ensuite high et répondre aux questions
3-4.
Medium :

 Le cookie utilise la valeur de time(), donc une timestamp en secondes.

 L’ID semble aléatoire mais si un attaquant connaît l’heure de connexion, il peut

brute-forcer dans une plage temporelle de quelques secondes.

Prévisible dans un petit intervalle de temps.

Exploitation : Tenter des timestamps proches de l’heure actuelle
Height :

 Le cookie est un MD5 d’un entier.

 Bien que le hash paraisse aléatoire, si vous connaissez le schéma, vous pouvez :
o Générer les MD5 de 1, 2, 3, etc.
o Essayer ces valeurs comme cookies.
Prévisible si on connaît la logique (md5 d’un nombre incrémenté).

Exploitation : Générer les MD5 localement :

echo md5(1); // c4ca4238a0b923820dcc509a6f75849b
Et tester les cookies avec ces valeurs
[Link] le niveau de sécurité de dvwa à impossible, quel est le contrôle de sécurité qui a
été utilisé pour corriger cette vulnérabilité.

Améliorations de sécurité :

 L’ID est généré à partir de mt_rand() + time() + string → valeur hautement imprévisible.

 Le cookie est :

o Secure (HTTPS seulement)

o HttpOnly (inaccessible via JavaScript)

o Scope limité au chemin /vulnerabilities/weak_id/

Contrôle de sécurité :

 Utilisation d’une valeur imprévisible (random + timestamp)

 Ajout de flags de sécurité du cookie (Secure, HttpOnly)

 Restriction par path et domaine

7. Est ce que le logout de l’application supprime les identifiants de session du navigateur ?Est
ce que ça représente un problème de sécurité ?
 En général, dans DVWA, le logout détruit la session côté serveur, mais le cookie reste
parfois côté client (non supprimé).
 Si le cookie n’est pas supprimé du navigateur, alors :

Oui, c’est un problème de sécurité :

 Cela permet à un attaquant ayant accès au navigateur de réutiliser l’ID.
 Cela augmente le risque de session fixation.
Bonne pratique : toujours invalider la session côté serveur ET supprimer le cookie côté
client au logout.

Brute Force:
1. Configurer le niveau de sécurité de dvwa sur low.
2. Cliquer sur lien brute force
3. Essayer de trouver pourquoi l’application est vulnérable à des attaques par brute force
Analyse du code low :

Lorsque DVWA est configurée au niveau "Low", aucune mesure de protection n’est mise en
place contre les attaques par force brute. Le code source montre clairement qu’il n’y a ni
limitation du nombre de tentatives, ni délai, ni verrouillage de compte, ni vérification de
token CSRF. Par exemple, le script exécute directement une requête SQL telle que :
$query = "SELECT * FROM `users` WHERE user = '$user' AND password = '$pass';";
Cela signifie qu’un attaquant peut soumettre un nombre illimité de tentatives, à l’aide
d’outils automatisés comme Burp Suite, Hydra ou même curl, sans rencontrer d’obstacle

4. Tourner le niveau de sécurité de dvwa à medium et ensuite high et répondre à la question

Analyse du code medium :
Au niveau Medium, une légère protection est introduite sous forme d’un délai fixe de deux
secondes ajouté après chaque tentative échouée, via la fonction sleep(2);. Cette mesure
ralentit légèrement l’attaque, mais ne l’empêche pas. Un script automatisé peut toujours
tester un grand nombre de combinaisons, simplement avec un rythme plus lent. Il n’y a
toujours aucune limitation sur le nombre de tentatives, ce qui rend l’application encore
vulnérable, même si l’exploitation prend un peu plus de temps.

Analyse du code height :

Pour le niveau High, la sécurité est renforcée avec deux mécanismes : l’ajout d’un token CSRF
qui est vérifié à chaque soumission de formulaire, et l’introduction d’un délai aléatoire
compris entre 0 et 3 secondes grâce à sleep(rand(0, 3));. Ces éléments rendent
l'automatisation un peu plus complexe, notamment à cause de l'imprévisibilité du timing et
de la nécessité de gérer dynamiquement les tokens. Toutefois, ces protections restent
insuffisantes, car un attaquant bien organisé peut toujours automatiser les requêtes avec les
bons tokens. De plus, il n’y a toujours ni verrouillage de compte, ni restriction sur le nombre
de tentatives, ce qui laisse la porte ouverte aux attaques.

5. Tourner le niveau de sécurité de dvwa à impossible, quel est le contrôle de sécurité qui a
été utilisé pour corriger cette vulnérabilité.
Analyse du code impossible :
Lorsque le niveau de sécurité est réglé sur Impossible, DVWA implémente de véritables
mécanismes de défense. Le code introduit un verrouillage de compte après cinq tentatives
échouées dans une fenêtre de quinze minutes. Ce comportement est contrôlé via la
vérification suivante dans le code source :
if( $row[ 'failed_login' ] >= $total_failed_login )
En plus du verrouillage, l’application enregistre un horodatage (timestamp) de la dernière
tentative de connexion afin de déterminer si le délai de déverrouillage est expiré. Un token
CSRF est également utilisé, et les messages d'erreur sont génériques pour éviter
l’énumération d’utilisateurs. Si un compte est verrouillé, même une tentative avec un mot de
passe correct échouera. Cela rend les attaques par force brute (et même les attaques
d’énumération) inefficaces.