Mise à jour du 10/11/2024.
Le service home de l'application de test est chargé de créer la page de saisie des données d'authentification de l'utilisateur. Ces données sont stockées au sein de la table t_user de la base de données PostgreSQL pastest. Un formulaire assure cette saisie et les données recueillies sont émises par un coprs de requête HTTP via une méthode POST.
L'appel du service se fait de façon explicite ou implicite.
L'appel implicite est celui qui consiste à invoquer le chemin de commutation vers l'application sans adjoindre à l'URL le paramètre srv. Cela se produit généralement au 1er appel alors qu'aucun identifiant de session n'a été fourni. Dans le cas d'un appel implicite, si l'identifiant de session existe déjà, le serveur considérera l'appel comme une tentative de rejeu. Le rejeu est un mécanisme courant d'attaque de type "homme du milieu" (MIT). Dans ce cas, pour protéger l'utilisateur, il supprimera la session courante et considérera l'appel comme une nouvelle tentative de connexion.
L'appel explicite consiste à fournir à l'URL le paramètre srv=home. Il est possible de lui adjoindre le paramètre facultatif user={identifiant de compte}. C'est en particulier ce que fait le service lorsque l'authentification échoue et que le service est rappelé. Lortsque ce paramètre facultatif est présent, le champ compte est alors pré-renseigné.
Ceci nous donne la table des appels du service home ({$commut} = chemin de commutation vers l'application).
| URL | Fonction |
|---|---|
| {$commut}/ | Appel implicite : création d'une nouvelle session avec suppression éventuelle d'une session existante. |
| {$commut}/srv=home | Appel explicite : création d'une nouvelle session avec suppression éventuelle d'une session existante. |
| {$commut}/srv=home&user={compte} | Appel explicite : création d'une nouvelle session avec suppression éventuelle d'une session existante. Le champ de saisie Compte est pré-renseigné avec la valeur du paramètre user. |
| {$commut}/srv=home&user={compte}&pwd={mot de passe} | Vérification des données d'authentification.
|
| {$commut}/{autre combinaison que celles ci-dessus même si uniquement enrichissement} | URL considéré comme frauduleux. Message texte avec statut 403. |
Le service home est chargé de présenter la page HTML contenant le formulaire de saisie des données. C'est un service ré-entrant dans la mesure où certaines situations l'amènent à produire de nouveau sa page. Il commence par vérifier que l'URL est conforme à un appel implicite ou explicite.
L'organigramme simplifié qui suit illustre ce fonctionnement :
Les données transmises sont sensibles car leur divulgation permettrait à quiconque d'usurper l'identité du véritable utilisateur. La confidentialité de ces données repose donc sur deux acteurs : L'utilisateur qui ne doit pas les divulguer et le système qui doit les protéger durant leur stockage et leur transfert. L'application ne prend aucun risque et supprime toute session existante avec le même identifiant que celui reçu éventuellement lors de l'appel du service home. En effet, dans la logique de cette application, l'authentification n'est réalisée qu'une seule fois. Pour ce qui est du système, cette confidentialité est assurée par le chiffrement TLS des transmissions par le réseau. De plus, on considère le serveur de données comme "sûr" et il n'est donc pas besoin de les protéger au sein du SGBDR. Ainsi, le serveur ne doit pas autoriser le protocole HTTP et imposer à la place le protocole HTTPS. Côté navigateur, là encore la sécurité repose entièrement sur la rigueur de l'utilisateur.
Rédaction par Jean-Marie Piatte (1983-2021)