Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cyber:owasp6:activite2 [2025/01/31 14:37] – créée dthevenot
+++ cyber:owasp6:activite2 [2025/02/02 23:02] (Version actuelle) – [2À vous de jouer] dthevenot
@@ Ligne 12: / Ligne 12: @@
 Pour tester une injection distante, un mode opératoire est proposé sur l’application Mutillidae via la fourniture d’un script.
-  * Q1.	Positionner le niveau de sécurité à 0 puis démarrer le serveur web apache présent sur la machine kali via la commande service apache2 start.
+  * **Q1**.	Positionner le niveau de sécurité à 0 puis démarrer le serveur web apache présent sur la machine kali via la commande service apache2 start.
-  * Q2.	Tester l’injection d’un lien externe (google par exemple ou une autre ressource locale si votre maquette n’a pas d’accès à internet).
+  * **Q2**.	Tester l’injection d’un lien externe (google par exemple ou une autre ressource locale si votre maquette n’a pas d’accès à internet).
-  * Q3.	Créer le script proposé par Mutillidae sur la page suivante : Hints and Videos=> Remote File Inclusion
+  * **Q3**.	Créer le script proposé par Mutillidae sur la page suivante : Hints and Videos=> Remote File Inclusion
 	Nommer le script shell.php
 {{:cyber:owasp6:script.png?400|}}
 	Déplacer ce script sur le serveur web du pirate puis tester son fonctionnement local.
-Q4.	Tester l’injection distante de ce script depuis l’application Mutillidae via l’url suivant qu’il faut adapter : (http://mutillidae  et http://[ATTACKING SERVER IP ADDRESS])
+  * **Q4**.	Tester l’injection distante de ce script depuis l’application Mutillidae via l’url suivant qu’il faut adapter : (http://mutillidae  et http://ATTACKING_SERVER_IP_ADDRESS)
 	Qu’observe t-on ?
-Travail à faire 4	Codage sécurisé et analyse du code source
+=== Travail à faire 4	Codage sécurisé et analyse du code source ===
 Le but de cette deuxième partie est de tester à nouveau l’attaque après activation du codage sécurisé et de comprendre le codage mis en place pour sécuriser la page.
+  * **Q1**.	Tester les niveaux de sécurité 1 et 5 et confirmer le comportement observé lors de l’injection locale.
+  * **Q2**.	 Consulter le manuel PHP afin d’expliquer le rôle de la fonction preg_match présente dans le code sécurisé.
-Q1.	Tester les niveaux de sécurité 1 et 5 et confirmer le comportement observé lors de l’injection locale.
-Q2.	 Consulter le manuel PHP afin d’expliquer le rôle de la fonction preg_match présente dans le code sécurisé.
-Prolongement possible :
-Reprendre une application existante et mettre en place le niveau de sécurité 5.
-i	Contre-mesures
-Les injections locales ou distantes ont lieu lorsqu’une application inclut dans une page un flux ou un fichier qui est défini via une entrée utilisateur. Ce flux doit être vérifié avant d’être exécuté.
-Pour se prémunir des attaques par injection de fichiers, il n’y a pas d’autre manière que de filtrer et valider les entrées utilisateurs. Il ne faut jamais inclure ou exécuter directement une entrée utilisateur.
+{{ :cyber:owasp6:dossierdocumentaire2.pdf |}}
-Pour le cas des injections distantes, il est possible de désactiver les directives “allow_url_open” et “allow_url_include” à “Off” si leur utilisation n’est pas nécessaire.
-Un mécanisme de liste blanche ou de liste noire de caractères interdits ou autorisés peut être mis en place.
-Cette vulnérabilité est de moins en moins présente dans les applications récentes qui sont basées majoritairement sur des framework robustes.