Différences

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

--- cyber:owasp4:activite_2 [2025/01/26 15:24] – créée dthevenot
+++ cyber:owasp4:activite_2 [2025/01/26 15:37] (Version actuelle) – [À vous de jouer] dthevenot
@@ Ligne 1: / Ligne 1: @@
-Brèche dans la configuration SSL
+====== Brèche dans la configuration SSL ======
- 	Objectif
+===== Objectif =====
-Ce second défi a pour objectif de transformer une redirection HTTPS en connexion non chiffrée HTTP afin de capturer les identifiants de la page de connexion.
+Cette seconde activité a pour objectif de transformer une redirection HTTPS en connexion non chiffrée HTTP afin de capturer les identifiants de la page de connexion.
- 	À vous de jouer
-Les questions suivantes se traitent en suivant les étapes décrites dans le dossier documentaire
-Travail à faire 3	Mise en place de l’attaque
+=====  À vous de jouer =====
+Les questions suivantes se traitent en suivant les étapes décrites dans le dossier documentaire en bas de page.
+==== Travail à faire 1 - Mise en place de l’attaque ====
 Dans un premier temps, l’objectif est de réaliser une attaque visant à rediriger une connexion HTTPS en HTTP afin de capturer des identifiants de connexion.
-Q1.	Commencer par préparer votre environnement de travail en démarrant les trois machines suivantes :
+  * **Q1**.	Commencer par préparer votre environnement de travail en démarrant les trois machines suivantes :
-•	le serveur mutillidae ;
+    * le serveur mutillidae ;
-•	la machine attaquante (celle qui contient le logiciel BurpSuite) ;
+    * la machine attaquante (celle qui contient le logiciel BurpSuite) ;
-•	la machine victime.
+    * la machine victime.
-	Vérifier que ces trois machines communiquent puis positionner le niveau de sécurité de Mutillidae à 0.
+    * Vérifier que ces trois machines communiquent puis positionner le niveau de sécurité de Mutillidae à 0.
-Q2.	À l’aide du dossier documentaire n°2, réaliser le deuxième défi permettant de compromettre les identifiants de connexions de la victime via une brèche dans la configuration SSL (redirection HTTP). Vous prendrez soin de réaliser vos propres captures d’écrans dans votre compte rendu de TP. Pour vous aider à comprendre ce défi, vous pouvez consulter la page suivante sur Mutillidae : A3=> Sensitive Data Exposure > SSL Misconfiguration.
+  * **Q2**.	À l’aide du dossier documentaire ci-dessous, réaliser le deuxième défi permettant de compromettre les identifiants de connexions de la victime via une brèche dans la configuration SSL (redirection HTTP). Vous prendrez soin de réaliser vos propres captures d’écrans dans votre compte rendu de TP. Pour vous aider à comprendre ce défi, vous pouvez consulter la page suivante sur Mutillidae : A3=> Sensitive Data Exposure > SSL Misconfiguration.
-Travail à faire 4	Codage sécurisé et analyse du code source
+==== Travail à faire 2 - 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.
+=== Test du niveau 1 de sécurité : ===
+  * **Q1**.	Est-ce que le niveau de sécurité 1 permet d’empêcher cette attaque ?
+  * **Q2**.	Est-ce que le niveau de sécurité 1 permet d’empêcher les conséquences de cette attaque ? Où se situe la faille ?
+  * **Q3**.	Expliquer le code source mis en œuvre avec ce niveau de sécurité en analysant la page index.php.
+=== Test du niveau 5 de sécurité : ===
+  * **Q4**.	Est-ce que le niveau de sécurité 5 permet d’empêcher l’attaque ?
+  * **Q5**.	Est-ce que le niveau de sécurité 5 permet d’empêcher les conséquences de l’attaque ?
+  * **Q6**.	Expliquer le code mis en œuvre avec ce niveau de sécurité en analysant la page index.php. Vers quelles page est-on redirigé en cas d’attaque ? En déduire la bonne pratique à mettre en œuvre en cas de besoin de confidentialité sur les applications Web ?
-Test du niveau 1 de sécurité :
+{{ :cyber:owasp4:documentaireactivite2.pdf |Dossier documentaire}}
-Q1.	Est-ce que le niveau de sécurité 1 permet d’empêcher cette attaque ?
-Q2.	Est-ce que le niveau de sécurité 1 permet d’empêcher les conséquences de cette attaque ? Où se situe la faille ?
-Q3.	Expliquer le code source mis en œuvre avec ce niveau de sécurité en analysant la page index.php.
-Test du niveau 5 de sécurité :
-Q4.	Est-ce que le niveau de sécurité 5 permet d’empêcher l’attaque ?
-Q5.	Est-ce que le niveau de sécurité 5 permet d’empêcher les conséquences de l’attaque ?
-Q6.	Expliquer le code mis en œuvre avec ce niveau de sécurité en analysant la page index.php. Vers quelles page est-on redirigé en cas d’attaque ? En déduire la bonne pratique à mettre en œuvre en cas de besoin de confidentialité sur les applications Web ?