cyber:owasp4:activite_2 [SIO Wiki]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Brèche dans la configuration SSL ======
===== Objectif =====
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 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 :
    * le serveur mutillidae ;
    * la machine attaquante (celle qui contient le logiciel BurpSuite) ;
    * la machine victime.
    * 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 ====
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 ?

{{ :cyber:owasp4:documentaireactivite2.pdf |Dossier documentaire}}