Exercices
Questions à choix multiple
Sessions

Leçon N° 13 : Autentification : mot de passe, sécurité

Théorie
Organigramme
Application standard
Application minimum
 Notes de page

Les bases de la sécurité

Dans des projets réels de développement, le contrôle d'accès comporte typiquement le code d'écriture pour manipuler les événements suivants:
  1. Vérification d'utilisateur et crétion d'une session (ouverture): La première fois qu'un utilisateur entre sur un site Web, une application doit être capable de demander les qualifications de l'utilisateur (habituellement une combinaison unique d'utilisateur/mot de passe), et de permettre ou de refuser l'accès basé sur ces informations. Cette étape comporte également la création d'une "session", qui stocke des variables d'utilisateur à travers des transactions multiples de HTTP.
  2. Maintien des données de la session et re-vérification des qualifications d'utilisateur: Une fois qu'un utilisateur est entré avec succès, l'application doit pouvoir re-vérifier les qualifications de l'utilisateur, page par page, et permettre ou refuser l'accès les pages spécifiques basés sur ces données d'utilisateur (la session créée à la première étape). Pour le moins, l'application doit vérifier pour assurer l'existence d'une session valide d'utilisateur; des applications plus complexes peuvent en plus exécuter des contrôles secondaires pour s'assurer que l'utilisateur a des permissions ou des privilèges appropriés de sécurité d'exécuter le script ou de regarder la page.
  3. Destruction de session (sortie du système): L'application doit être capable de se rendre compte qu'un utilisateur est sorti du site, et de détruire de ce fait toutes les variables utilisateur-spécifiques de session créées pendant la première étape. Bien que ce soit la dernière étape dans le processus, son importance ne peut pas être sous-estimée; l'omettre peut avoir des répercussions sérieuses sur la sécurité de votre application.
    Nb:En France la loi informatique et liberté stipule qu'en aucun cas ces données ne doivent être conservées plus d'un an.
    Dans la pratique :
    La version Appache de PHP contient une fonctionnalité spécifique qui n'existe pas dans la version CGI (windows), elle permet, à l'aide d'entêtes HTTP (401), de faire apparaitre une boite de dialogue de demande de mot de passe les noms d'utilisateur et mots de passe allant dans des variables serveur $_SERVER[PHP_AUT_USER] et $_SERVER[PHP_AUT_PW] Nous ne verrons pas en détail ces fonctionnalités, décrites à l'adresse :
    www.php.net/manual/en/features.http-auth.php


Application pratique standard

    Les différentes tâches à effectuer vont être les suivantes :
  1. Création d'une table des mots de passe : cela n'est necessaire que lorsque plusieurs personnes doivent avoir accès aux informations protégées. Si un seul mot de passe est necessaire, il pourra étre "en dur" (pas forcement en clair) dans le code, mais attention, le jour où il faudra le changer, il faudra aller dans le code, aussi il est fortement conseillé de mémoriser le ou les mots de passe dans un fichier séparé; en général la base mySQL est mieux protégée que le restant du site, un mot de passe supplémentaire est necessaire pour y accéder. Cette opération ne nessessite pas de connaissance supplémentaires que celles apportées au chapitre MySQL première partie, si ce n'est que les mots de passe pourront être cryptés pour plus de sécurité : Pour le cryptage, on pourra utiliser, pour des besoins "standards", la fonction "crypt" (attention, il n'existe pas de fonction decrypt, donc impossible de récupérer un mot de passe perdu !). Encodage du mot de passe :
    <?
    $password = crypt($password,$user_name) ;//à la fois lors du chargement dans la base et à la vérification
    ?>
    2. Création d'une table des mots de passe
    Nom du fichier : exercises_13/lesson_13_a1_create_password_table.php
    Ajout d'utilisateurs à la table des mots de passe
    Nom du fichier : exercises_13/lesson_13_a2_create_password_table.php
    Lire la table des mots de passe
    Nom du fichier : exercises_13/lesson_13_a3_create_password_table.php
  2. Lorsque l'utilisateur a été correctement autentifié, il faut ensuite écrire une variable de session pour ne pas avoir à redemander le mot de passe à chaque page. Le système http nécessite que cette opération soit effectuée avant tout envoi au serveur http, la page devra donc commencer de la façon suivante :
    <?
    if ($password_OK) //la vérification du mot de passe s'est bien effectuée
    {
          empty($_SESSION)? session_start():print""; //initialisation de la session
          $_SESSION["session_user_name"] = $_POST['user_name'];// on met le nom d'utilisateur dans la variable de session
          header("Location: lesson_13_d_welcome.php?user_name=$session_user_name");//redirection
          exit();
    }
    else
    { // mot de passe incorrect
          echo "Vous n'avez pas fourni un mot de passe vous permettant d'entrer sur le site";
          . . . .
    }
    ?>
    3. (Voir au besoin d'autres exemples pratiques sur les variables de session au chapitre 14)
    Saisie user/mot de passe pour entrer sur le site
    Nom du fichier : exercises_13/lesson_13_b_login_form.php
  3. Il faut ensuite modifier toutes les pages protégées du site de façon à empêcher tout utilisateur non identifié d'entrer sur la page (on pourra rajouter ce code ou créer un fichier séparer et l'inclure avec un include() ):
    <?
    empty($_SESSION)? session_start():print"";
    if (!isSet($_SESSION['session_user_name']))//vérification variable de session
    {
    echo "Entrée interdite";
    exit();
    }
    . . . . //suite du code de la page, (html ou php)
    ?>
  4. Le problème qui peut survenir est le suivant : Aprés une vérification positive du mot de passe, on demande au système d'exploitation d'enregistrer une variable de session, puis on serait tenté de diriger directement l'utilisateur sur le site, mais le temps d'accès à une page du site peut être plus rapide que le temps, pour le système d'exploitation, d'ecrire la variable de session, auquel cas l'utilisateur se voit refuser l'accès à la page, bien que son mot de passe soit bon, d'où la mise en place d'une page de bienvenue, comme indiqué dans l'organigramme ci-dessus
    5. Economie risquée d'une page
    Nom du fichier : exercises_13/lesson_13_g1_risque.php
    Exercices supplémentaires :
    _Chercher dans le serveur où sont stockées les variables de session, en éditer une pour voir son contenu
    _Modifications à effectuer : rajouter le prénom à la fois dans la base et dans les variable de session de façon à pouvoir l'afficher en haut de chaque page visitée

    Application minimum

    L'application ci-après constitue un minimum pour le cas où l'on veut simplement protéger un ensemble de pages, avec un seul mot de passe fixe. (Sans la gestion d'un ensemble de noms d'utilisateurs + leurs mots de passe enregistrés dans une base mySQL)
      Cette mini-application va comprendre quatre fichiers
    1. Un formulaire de demande de mot de passe (Vous avez 3mn pour trouver le mot de passe!)
      Formulaire d'entée
      Nom du fichier : exercises_13/lesson_13_minimum_1.php
    2. Une page de validation avec enregistrement de la variable de session
    3. Une page de vérification de la variable de session à inclure dans chaque page du site (normalement invisible par l'utilisateur)
    4. Une page de site type
    5. Aller sur la page sans passer par le mot de passe Si l'on a déjà saisi le mot de passe, il va rester valide par l'intemédiaire des variables de session, tant que l'on n'aura pas fermé et réouvert le navigateur
      6. Tous droits réservés. 2005-2020