Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
cyber:owasp4:activite_2 [2025/01/26 15:29] – dthevenot | cyber:owasp4:activite_2 [2025/01/26 15:37] (Version actuelle) – [À vous de jouer] dthevenot | ||
---|---|---|---|
Ligne 4: | Ligne 4: | ||
===== À vous de jouer ===== | ===== À vous de jouer ===== | ||
- | Les questions suivantes se traitent en suivant les étapes décrites dans le dossier documentaire | + | Les questions suivantes se traitent en suivant les étapes décrites dans le dossier documentaire |
==== Travail à faire 1 - Mise en place de l’attaque ==== | ==== 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. | 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 : | + | |
* le serveur mutillidae ; | * le serveur mutillidae ; | ||
* la machine attaquante (celle qui contient le logiciel BurpSuite) ; | * la machine attaquante (celle qui contient le logiciel BurpSuite) ; | ||
Ligne 14: | Ligne 14: | ||
* 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 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 2 - 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. | 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é : === | === 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é : === | === 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 ? | + | |
+ | {{ : |