SESSION, AUTHENTIFICATION ET CONTRÔLE D ACCÈS

Transcription

1 SESSION, AUTHENTIFICATION ET CONTRÔLE D ACCÈS Développer des applications Web

2 1 Gestion de sessions

3 Session 2 En informatique, le terme «session» désigne un temps durant lequel un programme est en interaction avec un utilisateur (humain ou non). À moins que l interaction ne se limite à l échange d un seul message, une session implique l existence d une mémoire capable de conserver l état de la conversation. Dans le contexte du web, le terme se réfère à deux choses souvent liées, mais distinctes : La session du navigateur. La session du serveur.

4 Session du navigateur 3 Une session du navigateur commence au démarrage du navigateur et se termine qu on le ferme. Tous les onglets partagent la même session. La mémoire associée à la session permet de conserver l état des authentifications HTTP et les cookies de session. Le terme «cookies de session» fait référence à la session du navigateur lorsqu il désigne un cookie non persistant automatiquement supprimé à la fermeture du navigateur. Le cookie utilisé pour stocker l identifiant de session du serveur en PHP également appelé cookie de session est souvent un cookie de session au sens décrit ci-dessus.

5 Session du serveur et cookie 4 Durant une session, une application web passe généralement par différents états transitoires déterminés par les actions de l utilisateur qui sont autant de requêtes. Cependant, on sait qu un serveur HTTP ne mémorise rien entre deux requêtes (HTTP est un protocole sans état). Il ne peut donc pas conserver l état des sessions des clients. Avec les cookies (HTTP State Management Mechanism), L IETF propose une solution qui consiste à utiliser la mémoire du client pour conserver l état de la session.

6 Cookie et données de session 5 Un serveur HTTP émet un cookie pour demander au client (navigateur) de conserver des données et de les renvoyer avec toutes les requêtes qui lui sont destinées. Du fait qu il se trouve sous le contrôle du client, le contenu d un cookie est particulièrement vulnérable. C est pourquoi on doit éviter d y placer des informations sensibles dont la durée de vie excède quelques heures. Un cookie ne contient donc le plus souvent qu un identifiant (une clé) qui permet de retrouver les données de session stockées dans un ficher ou une base de données.

7 Initialisation d une session 6 Cookie DB Client Serveur ( Lit les cookie de (vide) Enregistre les cookie de (SID=123456) GET /page HTTP/1.1 Host: HTTP/ OK Content-Type: text/html [ ] Set-Cookie: SID= [ ] Génère un nouvel identifiant de session et enregistre les données Lit les cookie de (SID=123456) GET /page HTTP/1.1 Host: Cookie: SID= Charge les données de session correspondant à l identifiant

8 Identifiant de session 7 Un identifiant de session est une donnée sensible qui peut être utilisée pour usurper l identité et les permissions d un utilisateur. Pour limiter les risques, on doit prendre un certain nombre de précautions dont voici quatre des plus importantes : Le nombre d identifiants valides doit être très petit en regard du nombre d identifiants possibles (identifiants d au moins 128 bits). La valeur d un identifiant doit être aussi aléatoire que possible pour ne pas être prédictible (PRNG cryptographique) La durée de validité d un identifiant doit être limitée (pas plus de quelques dizaines de minutes d inactivité). L identifiant doit changer après chaque changement d état ou, au minimum, après chaque authentification.

9 Gestion de sessions 8 Si une ressource nécessite une session, le serveur commence par vérifier que la requête contient un cookie de session. Si le cookie est absent ou l identifiant non valide : Le serveur initialise une session, envoie la réponse, enregistre la date et l heure dans les données de session et stocke ces dernières dans un fichier ou une base de données. Si l identifiant de session est valide : Le serveur utilise les données de session pour calculer le temps écoulé depuis la dernière requête. Si ce temps dépasse une certaine valeur, il réinitialise la session. Enfin, le serveur envoie la réponse, enregistre la date et l heure dans les données de session et stocke ces dernières dans un fichier ou une base de données.

10 Gestion de sessions en PHP 9 Les fonctions et variables nécessaires à la gestion de sessions en PHP sont les suivantes : session_name() renvoie le nom du cookie de session et permet de tester l existence d un cookie de session dans la requête. session_start() charge les données de la session si elle trouve un cookie de session valide, sinon initialise une nouvelle session. $_SESSION est un tableau qui contient les données de session. Le contenu est sauvegardé automatiquement à la fin du script. session_id() renvoie l identifiant de la session en cours. session_regenerate_id() permet de générer un nouvel identifiant de session pour la session en cours.

11 Paramètres de session en PHP 10 Le fichier php.ini permet de configurer le système de gestion de sessions. Dans ce fichier, il est important de vérifier la valeur des paramètre suivants : session.use_strict_mode doit être activé pour éviter l adoption de session. session.use_cookies et session.use_only_cookies doivent être activés pour interdire les identifiants de session dans les URL. session.cookie_httponly doivent être activé pour interdire l accès à l identifiant de session par les scripts dans un navigateur. session.cookie_secure doit être activé pour un site qui utilise HTTPS (cela devrait toujours être le cas en production).

12 11 Authentification

13 Authentification 12 Quand une personne se présente au guichet d un bâtiment sécurisé, la conversation avec l agent de sécurité comprend nécessairement les éléments suivants : La personne donne son nom et présente une pièce d identité reconnue par l agent. L agent vérifie que le nom de la personne apparaît sur le registre et vérifie ses papiers. L authentification repose sur le fait que la personne présente une pièce d identité officielle qu elle est la seule à posséder et dont l agent de sécurité peut vérifier l authenticité.

14 Authentification (informatique) 13 Dans un système informatique, une personne décline son identité à l aide de son nom d utilisateur et la prouve le plus souvent à l aide d un mot de passe. Dans ce cas, l authentification repose sur le fait que la personne est la seule à connaître son mot de passe.

15 Facteurs d authentification 14 Un facteur d authentification est un moyen utilisé pour prouver ou vérifier l identité d une personne. En informatique, on se base le plus souvent sur un ou deux des facteurs d authentification suivants : Quelque chose que la personne sait (un mot de passe). Quelque chose que la personne possède (une boîte de courriel, un téléphone portable ou un OTP token). Quelque chose qui caractérise la personne (donnée biométrique).

16 Authentification HTTP 15 L authentification HTTP est basé sur l en-tête Authorization et sur le code de statut 401 (Unauthorized) associé à l entête WWW-Authenticate. Lorsque le client est un navigateur, on évite généralement ce mode d authentification pour au moins trois raisons : L interface utilisateur dépend du navigateur et ne peut pas être adaptée aux besoins de l application. Pour terminer la session, l utilisateur doit fermer tous les onglets du navigateur (pas de menu ou de bouton «Déconnexion»). L authentification dite basique (basic authentication) implique la transmission du nom de l utilisateur et de son mot de passe avec chaque requête.

17 Authentification par formulaire 16 La méthode d authentification la plus fréquemment utilisée dans le web est l authentification par formulaire. Elle met en œuvre les éléments suivants : Une session du serveur valide. Un formulaire HTML pour obtenir les informations de connexion. Une base de données d utilisateurs (souvent une table dans la base de de données l application) L authentification par formulaire repose sur l existence d un cookie de session valide.

18 Exemple d implémentation 17 Lorsque l utilisateur accède à une ressource protégée : Le serveur utilise les données de session pour savoir si l utilisateur est authentifié et, si c est le cas, envoie une réponse avec le code de statut 200. Dans le cas contraire, il sauvegarde l URL de la ressource dans les données de session et redirige l utilisateur vers le formulaire de connexion avec le code 302. Lorsque l utilisateur renvoie le formulaire, le serveur vérifie que le nom et le mot de passe fournis correspondent à un nom et un mot de passe stocké dans la base de données. Si c est le cas, le serveur indique dans les données de session que l utilisateur est authentifié, génère un nouvel identifiant de session et répond avec un 303 vers la ressource sauvegardée.

19 Stockage des mots de passe 18 Pour assurer la confidentialité d un mot de passe dans les applications web, on doit respecter les principes suivants : Un mot de passe ne peut exister en texte clair que dans la mémoire du client (navigateur) ou du serveur et uniquement pour de courtes durées (quelques secondes au plus). S il est stocké, il doit être crypté avec un algorithme de hachage cryptographique spécialisé (bcrypt) pour que personne ne puisse le décrypter, pas même son détenteur. S il est volé sous forme cryptée, sa découverte doit être aussi coûteuse que possible (quelle que soit la méthode). Le respect de ces principes impliquent également l utilisation de HTTPS et l application d une politique des mots de passe.

20 Cryptage de mots de passe en PHP 19 En matière de sécurité, mieux vaut éviter d être original et utiliser ce que le langage ou le framework vous propose. password_hash() prend comme paramètres le mot de passe en texte clair et l algorithme et renvoie une chaîne contenant l empreinte du mot de passe, le sel et l algorithme utilisé. password_verify() prend comme paramètres le mot de passe crypté et le mot de passe reçu de l utilisateur, et renvoie un booléen qui indique si les deux mots de passe correspondent ou non.

21 Algorithme de cryptage en PHP 20 En utilisant l algorithme par défaut, vous permettez à PHP d utiliser le meilleur algorithme disponible pour crypter le mot de passe au moment où celui-ci est stocké. La fonction de vérification ne dépend pas de l algorithme par défaut, elle utilise l algorithme spécifié dans l empreinte du mot de passe. Bcrypt, est l algorithme par défaut PHP 5.5. Il ne peut crypter que des mots de passe de moins de 73 caractères. Les mots de passe plus longs sont tronqués.

22 Connexion persistante (Remember me) 21 Par défaut, le cookie de session de PHP est non persistant. Il est tentant de le rendre persistant pour permettre à un utilisateur de rester connecté. Ne le faites pas! Il s agit d authentification, pas de gestion de session. C est un moyen d authentification alternatif qui utilise un cookie persistant pour stocker des information de connexion et là encore, mieux vaut utiliser une bibliothèque existante. Dans tous les cas, les points suivants doivent être observés : Jamais de nom d utilisateur et mot de passe dans un cookie. Limiter la validité des données du cookie (quelques jours au plus). Exiger une authentification avant une opération importante.

23 Recouvrement de mot de passe 22 Le recouvrement de mot de passe (password recovery) en libre-service est une opération risquée. Cette fonctionnalité doit être implémentée en toute connaissance de cause et uniquement si elle est nécessaire. L OWASP (Open Web Application Security Project) propose un modèle qu il est recommandé de suivre.

24 23 Contrôle d accès

25 Contrôle d accès 24 Dans le bâtiment sécurisé, après l authentification de la personne, l agent doit vérifier qu elle possède l autorisation d accès aux locaux dans lesquels elle souhaite se rendre. De la même manière, dans un système informatique, après l authentification de l utilisateur, le système doit vérifier qu il possède l autorisation d accès aux données qu il veut consulter ou aux ressources qu il souhaite utiliser. La gestion de session, l authentification et le contrôle d accès sont des opérations liées et indissociables, mais distinctes.

26 Contrôle d accès basé sur les rôles 25 Un moyen de contrôle d accès souvent utilisé dans le web consiste à accorder les permissions en fonction du rôle de l utilisateur dans l organisation. C est ce qu on appelle le contrôle d accès basé sur les rôles. Par exemple, les rôles d un journal en ligne pourraient être : Administrateur Rédacteur Lecteur Invité

27 Exemple d implémentation 26 Le contrôle d accès présuppose une session valide et un utilisateur authentifié. Un contrôle d accès basé sur les rôles peut être implémenté de la manière suivante : Le serveur utilise les données de session pour connaître le rôle de l utilisateur authentifié et vérifie qu il se trouve dans la liste des rôles associés à la ressource. Si le c est le cas, l utilisateur possède l autorisation d accès à la ressource et le serveur répond avec un code de statut 200. Dans le cas contraire, le serveur peut informer l utilisateur qu il n a pas l autorisation d accès à la ressource avec le code de statut 403 (Forbidden) ou cacher l existence de la ressource avec le code de statut 404 (Not Found).