FR 2965134 A1 20120323 FR 1057554 A 20100921 10 La présente invention a pour objet un procédé permettant de sécuriser, d'empêcher, de prévenir et/ou de détecter l'accès aux données échangées entre des entités informatiques distantes. Elle concerne notamment, mais non exclusivement, un procédé qui permet de prévenir et d'empêcher l'usurpation d'identité des personnes échangeant des données au moyen de 15 dispositifs de traitement et/ou de communication électroniques. La communication entre des dispositifs de traitement et/ou de communication électroniques, tels qu'un ordinateur personnel et un serveur distant figurant au sein d'un réseau, s'effectue généralement au moyen d'un navigateur qui 20 comprend une interface graphique permettant de procéder : - à une navigation « multifenêtres », ce qui consiste à ouvrir simultanément plusieurs instances du navigateur ; - à une navigation « multi - onglets », ce qui donne la possibilité d'ouvrir chaque page consultée dans un onglet spécifique d'une seule 25 instance du navigateur ; ce type de navigation permet avantageusement de se dispenser d'ouvrir un trop grand nombre de fenêtres à la fois. Toutefois, les utilisateurs qui ouvrent une session avec une entité distante, 30 telle qu'un serveur, soit oublient fréquemment de clôturer cette session, soit n'ont pas conscience que leur session peut rester ouverte à leur insu. 1 Ainsi, certains utilisateurs se contentent souvent de fermer l'onglet correspondant à ladite session, tout en laissant respectivement ouverts les autres onglets de la même fenêtre qui est restée ouverte. Or, il est établi que l'absence de clôture de session déclenchée soit par l'émission d'une requête spécifique de clôture, soit par la fermeture de l'instance du navigateur elle - même peut, dans un très grand nombre de cas, ouvrir une faille de sécurité, permettant à une personne mal intentionnée d'accéder à ladite session, et de charger et de visualiser les pages de cette dernière au moyen notamment des liens enregistrés dans les « signets de l'historique » et/ou des « signets favoris » du navigateur, et/ou encore d'autres liens, tels que ceux créés par les robots d'indexation à partir de ces pages. Cette faille de sécurité permet à une personne présente dans l'entourage d'un utilisateur licite, de procéder à une intrusion locale et à un accès illicite à une session que l'utilisateur licite pensait être clôturée. L'intrus peut de cette façon, usurpant ainsi l'identité de l'utilisateur licite, reprendre et poursuivre cette session de transactions et être en mesure de procéder à des traitements illicites et préjudiciables à l'utilisateur licite, à savoir par exemple - l'altération, la destruction de données, notamment personnelles ou confidentielles ; - le vol, la diffusion ou la communication de ces données ; - des transactions financières, commerciales, relationnelles, juridiques, etc. qui peuvent avoir des effets préjudiciables pour l'utilisateur licite. Par ailleurs, l'intrusion peut également résulter d'un défaut d'assiduité de l'utilisateur, ce dernier laissant libre d'accès la fenêtre ou l'onglet du navigateur qu'il utilisait, ce qui permet à toutes les personnes présentes à proximité de reprendre et poursuivre illicitement cette session de transaction qui n'a pas été clôturée. L'invention a donc plus particulièrement pour objectif de résoudre ce problème en proposant un procédé qui permet d'empêcher l'accès à des données échangées au cours d'une session informatique, en faisant obstacle aux tentatives d'intrusion locale reposant sur l'utilisation de liens tels que des signets de l'historique, des favoris du navigateur ou d'autres liens d'indexation. La mise en oeuvre de ce procédé s'effectue avantageusement pour les utilisateurs de façon automatique et transparente, et ne nécessite que des aménagements au niveau des pages des serveurs. A cet effet, l'invention propose un procédé permettant de sécuriser l'accès à des données échangées lors d'une communication entre des entités électroniques distantes, constitutive d'une session, caractérisé en ce qu'il comprend notamment la réalisation des étapes suivantes : - le calcul d'une clé de continuité de session (« Continuity Session Key » ou « CSK », CSK1) avant l'émission de chaque requête effectuée dans le cadre de la session ayant pour objet l'obtention d'un ensemble de données, cette clé CSK1 étant intégrée dans ladite requête ; le calcul de cette clé de continuité est effectué en mettant en oeuvre un premier processus spécifique exécuté au niveau de l'onglet actif (ou de la fenêtre) du navigateur ; - le calcul d'une clé de continuité de session (« CSK », CSK2) après la réception de la réponse à ladite requête ; le calcul de cette clé de continuité est effectué en mettant en oeuvre un second processus spécifique exécuté au niveau de l'onglet (ou de la fenêtre) du navigateur ; - la comparaison de la valeur de la clé de continuité obtenue en mettant en oeuvre le second processus spécifique avec celle obtenue avec le premier processus spécifique ; - l'exécution de l'objet de la requête au profit de l'entité l'ayant émise, dans le cas où ces deux valeurs sont égales ; - l'exécution automatique d'un plan d'action spécifique ayant pour objet la clôture de la session en cours dans le cas où ces deux valeurs ne sont pas égales ; et en ce que la clé de continuité de session est spécifique à ladite session en cours. De cette façon, les données échangées au cours d'une session, entre typiquement un ordinateur personnel et un serveur, ne peuvent être accessibles qu'en cas de concordance des valeurs de la clé de continuité de session calculées par deux processus distincts, respectivement à l'émission de la requête et à la réception de la réponse à cette dernière. La tentative d'accès auxdites données en utilisant des liens tels que les signets de l'historique, les favoris du navigateur ou d'autres liens d'indexation ne permet pas cette concordance et devient alors vaine en raison de la clôture de la session en cours provoquée par le plan d'action spécifique, exécuté automatiquement en cas d'absence de concordance des valeurs desdites clés. La clé de continuité de session est une fonction calculée de préférence par le 15 navigateur à partir des données suivantes : - un nombre aléatoire, qui identifie la session sur une première entité informatique ; - un identifiant de la page HTML (« Hypertext Markup Language ») émettant une requête depuis l'onglet (ou la fenêtre) du navigateur ; 20 - un identifiant de la page HTML fournie en réponse par le serveur. Selon une variante d'exécution préférentielle de l'invention, le procédé selon l'invention peut également provoquer la clôture automatique de la session en cours dans le cas où un défaut d'assiduité de l'utilisateur est détecté et 25 confirmé. Le procédé selon cette variante d'exécution de l'invention permet ainsi, de manière avantageuse, de limiter le temps pendant lequel l'accès intrusif à une session reste possible quand, par exemple, un utilisateur s'absente en oubliant de fermer l'onglet de la fenêtre de son navigateur correspondant à ladite session. 30 Définitions : a) "services en lignes et services de transaction" : Un service en ligne est un service ou une ressource accessible par l'intermédiaire du réseau Internet afin d'améliorer la communication entre, d'une part, les personnes physiques et les entreprises, et, d'autre part, les organismes publics ou privés et les entreprises (par exemple, des fournisseurs) qui délivrent les services en lignes tels que les services de transaction, qui permettent d'accéder et de procéder à tous les principaux types de transactions, comme les opérations financières (banques, assurances, bourse), les services de santé, le recrutement, la participation à des réseaux sociaux, l'inscription à des manifestations, la vente ou l'achat de produits et services (sites marchands), etc. Bien qu'il soit possible de naviguer sur la plupart des sites Internet sans donner aucune information personnelle, des données confidentielles à caractère personnel sont exigées par les fournisseurs de services en ligne - typiquement les sites de transaction en ligne - qui utilisent ces données personnelles pour authentifier l'identité des personnes avant qu'elles puissent effectuer des transactions et pour effectuer ensuite l'exécution des opérations correspondantes. b) «données à caractère personnel» : Les données à caractère personnel peuvent être définies comme toutes les information concernant une personne physique identifiée ou identifiable (personne concernée) ; est réputée identifiable une personne qui peut être identifiée, directement ou indirectement, notamment par référence à un numéro d'identification ou à un ou plusieurs éléments spécifiques et confidentiels, propres à son identité physique, physiologique, psychique, économique, culturelle ou sociale. c) «traitement de données à caractère personnel» (traitement) : Le traitement de données à caractère personnel peut être défini comme toute opération ou ensemble d'opérations effectuées ou non à l'aide de procédés automatisés et appliquées à des données à caractère personnel, telles que : la collecte, l'enregistrement, l'organisation, la conservation, l'adaptation ou la modification, l'extraction, la consultation, l'utilisation, la communication par transmission, diffusion ou toute autre forme de mise à disposition, le rapprochement ou l'interconnexion, ainsi que le verrouillage, l'effacement ou la destruction. d) «responsable du traitement» : Le responsable du traitement est la personne physique ou morale, l'autorité publique, le service ou tout autre organisme qui, seul ou conjointement avec d'autres, détermine les finalités et les moyens du traitement des données à caractère personnel. Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence aux dessins annexés dans lesquels : La figure 1.a est une représentation schématique des étapes du sous - procédé d'établissement et d'initialisation d'une session privée entre des entités informatiques distantes, du procédé selon l'invention. La figure 1.b est une représentation schématique des étapes dudit sous - procédé d'établissement et d'initialisation d'une session privée entre des entités informatiques distantes dans lequel figurent aussi des étapes du processus de contrôle local de l'assiduité de l'utilisateur du procédé selon l'invention. La figure 2.a est une représentation schématique des étapes du sous - procédé de réalisation d'une transaction, du procédé selon l'invention. La figure 2.b est une représentation schématique des étapes du sous - procédé de réalisation d'une transaction dans lequel figurent aussi des étapes du processus de contrôle local de l'assiduité de l'utilisateur du procédé selon l'invention.30 La figure 3 est une représentation schématique des étapes du processus de contrôle local de l'assiduité de l'utilisateur, du procédé selon l'invention. Tel que cela est représenté sur la figure 1.a, le procédé selon l'invention comprend un sous - procédé d'établissement d'une session entre des entités informatiques distantes, qui comporte notamment les étapes suivantes : - l'ouverture par un utilisateur d'un navigateur ou d'un onglet d'un navigateur compris dans une première entité informatique pouvant consister par exemple en un micro-ordinateur, un PDA (« Personal Digital Assistant »), un téléphone portable pouvant être du type ordiphone (« smartphone »), etc. ; - l'appel par l'utilisateur d'un prestataire représenté par une seconde entité informatique telle qu'un serveur informatique, en composant par exemple l'adresse URL (« Uniform Ressource Locator ») de ce serveur dans la ligne d'adresse du navigateur ; dans cet exemple, la première entité informatique est considérée être un micro-ordinateur et la seconde entité informatique un serveur ; - l'émission d'une première requête d'initialisation de session par le navigateur à destination du serveur, cette première requête satisfaisant de préférence à un protocole de transmission tel que HTTP (« Hypertext Transfer Protocol ») ; - la réception de cette requête par le serveur, suivie de l'ouverture par ce dernier d'une session avec l'ordinateur de l'utilisateur ; - la transmission par le serveur, à destination du navigateur : o d'une page d'accueil dont l'accès a été demandé dans la requête d'initialisation, cette page étant préférentiellement au format HTML ; o et d'au moins un témoin (« un cookie ») de session ; - l'enregistrement par le navigateur du (des) témoin(s) et l'affichage de la page d'accueil ; - la saisie par l'utilisateur de données d'identification, telles qu'un identifiant et d'un mot de passe dans des emplacements spécifiques figurant sur cette page d'accueil ; - la transmission à destination du serveur, par l'utilisateur, au moyen du navigateur, d'une demande d'authentification comprenant ces données d'identification ; - l'authentification par le serveur dudit utilisateur si les données d'identification sont correctes ; la préparation d'au moins un témoin (un cookie) comprenant le composant RND d'une clé de continuité de session constitué par un nombre aléatoire identifiant localement la session et pouvant être calculé par une fonction de nombres aléatoires standard ; la transmission par le serveur au navigateur de ce(s) témoin(s) ainsi que de la page initiale de l'espace privé de l'utilisateur, cette page étant préférentiellement au format HTML et cette réponse étant transmise en respectant préférentiellement le protocole sécurisé HTTPS (« Hypertext Transfer Protocol Secure ») ; - l'enregistrement par le navigateur de ce(s) témoin(s) comprenant le composant RND ; l'affichage par le navigateur de la page HTML initiale de l'espace privé sécurisé ; - l'accès par l'utilisateur à cette page HTML initiale de l'espace privé sécurisé. De cette manière, les échanges opérées lors de la mise en oeuvre de ce sous - procédé d'établissement d'une session permettent de procéder à une identification mutuelle de l'utilisateur et du serveur du prestataire de service. Cette première phase du procédé selon l'invention, qui se traduit par la mise en oeuvre de ce sous - procédé d'établissement d'une session, permet ainsi au serveur - prestataire d'ouvrir une session avec un utilisateur présumé légitime. Tel que cela est représenté sur la figure 2.a, le procédé selon l'invention comprend également un sous - procédé de réalisation d'une transaction entre des entités informatiques distantes, qui comporte notamment les étapes suivantes : - l'utilisateur choisit un des services Si disponibles dans un menu pour effectuer la transaction ; ce choix se traduit par la demande d'une nouvelle page préférentiellement au format HTML, désignée comme étant la page CIBLE ; - un processus spécifique baptisé « NewPage » prépare la requête ayant pour objet d'obtenir la page CIBLE associée au service demandé ; - le calcul par le processus spécifique NewPage du composant FROM qui est constitué par un identifiant ayant une correspondance avec la page actuelle, suivi de l'enregistrement par le navigateur d'un témoin comprenant ce composant FROM ; le calcul par le processus spécifique NewPage, du composant CIBLE qui est constitué par un identifiant ayant une correspondance avec la page CIBLE ; l'affectation par le navigateur de la clé de continuité de session CSK1 calculé et attendu à la propriété Name de l'objet Windows tel que défini dans le modèle de document DOM (« Document Object Mode! ») qui a fait l'objet d'une recommandation du W3C (« World Wide Web Consortium »), la propriété Name renvoyant à l'onglet ou à la fenêtre du navigateur ; - l'émission d'une requête par le navigateur, à destination du serveur, ayant pour objet l'accès à la page CIBLE, cette requête étant envoyée en appliquant préférentiellement le protocole HTTP ou HTTPS ; - le traitement de la demande par le serveur ; la transmission par le serveur, à destination du navigateur, de la page CIBLE demandée ; - la réception par le navigateur de la page CIBLE ; - la mise en oeuvre du processus baptisé « Charon » qui contrôle que la page reçue est celle attendue en comparant la nouvelle clé CSK2 reçue à celle attendue CSK1 et précédemment enregistrée dans la propriété Name par le processus NewPage, ce processus Charon procède à : o la lecture du témoin comprenant le composant RND ; o la lecture du témoin comprenant le composant FROM ; o la calcul du composant CIBLE de la page reçue ; o le calcul de la clé de continuité de session CSK2 de la page reçue ; - la comparaison par le navigateur de la valeur de la clé de continuité CSK2 obtenue en mettant en oeuvre le processus spécifique Charon avec celle CSK1 obtenue avec le premier processus spécifique NewPage ; plus précisément, la comparaison est opérée entre la valeur de la clé de continuité CSK2 obtenue en mettant en oeuvre le processus spécifique Charon avec ladite propriété Name ; - l'affichage de la page CIBLE par le navigateur et l'accès à l'ensemble des données demandé par l'utilisateur dans le cas où ces deux valeurs sont égales, l'utilisateur pouvant saisir les informations nécessaires à la poursuite du service S demandé ; d'autres échanges suivant les mêmes principes peuvent être éventuellement effectués entre l'utilisateur et le prestataire - serveur en mettant de nouveau en oeuvre ce sous - procédé de réalisation d'une transaction ; ou - l'exécution automatique d'un plan d'action spécifique anti-intrusion, ayant pour objet la clôture de la session en cours, dans le cas où ces deux valeurs ne sont pas égales. La comparaison des valeurs de la clé de continuité par deux processus distincts, respectivement à l'émission d'une requête et à la réception de la réponse à cette requête permet de détecter les tentatives d'usurpation. Cette clé de continuité de session CSK constitue une signature à laquelle les pages obtenues de manière régulière satisfont. Au contraire, l'obtention d'une clé de continuité portant sur des pages appelées d'une autre façon, par exemple en utilisant des liens tels que des signets de l'historique, des favoris du navigateur ou d'autres liens d'indexation, ne comprennent que le composant CIBLE qui ne peut constituer à lui seul une signature valide. La détection d'une telle tentative d'usurpation entraîne la mise en oeuvre d'un plan d'action spécifique anti-intrusion comportant notamment, tel que cela est représenté sur la figure 2.a, les étapes suivantes : - l'émission d'une requête par le navigateur à destination du serveur, cette requête ayant pour objet l'accès à la page « Plan d'action antiintrusion » correspondant au plan d'action, qui satisfait de préférence au format HTML ; - le traitement de la demande par le serveur suivi par la fermeture de la session et de la transmission à destination du navigateur, de la page correspondant au plan d'action ; - la réception par le navigateur de cette page « Plan d'action » ; l'exécution par le navigateur du (des) action(s) figurant dans ledit plan d'action ; la fermeture par le navigateur de la fenêtre ouverte, qui se traduit par la fermeture de la session en cours avec le serveur. De cette manière, la session du navigateur est automatiquement fermée à la suite de la détection d'une tentative d'intrusion. Selon une variante d'exécution préférentielle, le procédé selon l'invention peut également comprendre un processus permettant de provoquer la clôture automatique de la session en cours dans le cas où un défaut d'assiduité de l'utilisateur est détecté et confirmé. 25 Tel que cela est représenté sur la figure 3, ce processus de contrôle local de l'assiduité de l'utilisateur ACLS (« Assiduity Control Local System ») comporte notamment les étapes suivantes : - l'initialisation d'un compteur timer' tel qu'une horloge, par le 30 navigateur, à la suite de la réception et de l'affichage par ce dernier d'une page transmise par le serveur ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé dl qui a commencé à20 courir à compter de l'initialisation dudit compteur timer1 ; le signal d'assiduité peut consister notamment, mais non exclusivement, en une interaction homme - machine tel que le clic d'une souris ou un enfoncement d'une touche d'un clavier, etc. - dans l'hypothèse où à l'expiration dudit délai prédéterminé dl, aucun signal d'assiduité n'est détecté, le déclenchement d'une alarme Alarmel est provoqué par le navigateur, suivi de l'initialisation d'un compteur timer2 du type susdit ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé d2 qui a commencé à courir à compter de l'initialisation dudit compteur timer2 ; - dans l'hypothèse où à l'expiration dudit délai prédéterminé d2, aucun signal d'assiduité n'est détecté, le déclenchement d'une alarme Alarme2 est provoqué par le navigateur, suivi éventuellement de l'initialisation d'un compteur timer3 du type susdit ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé d3 qui a commencé à courir à compter de l'initialisation dudit compteur timer3 ; - dans l'hypothèse où à l'expiration dudit délai prédéterminé d3, aucun signal d'assiduité n'est détecté, le déclenchement d'une alarme Alarme3 est provoqué par le navigateur ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé qui a commencé à courir à compter du déclenchement de Alarme3 ; - dans l'hypothèse où à l'expiration dudit délai prédéterminé aucun signal d'assiduité n'est détecté, le déclenchement par le navigateur du processus local de clôture de la session qui peut consister en : o la fermeture de la fenêtre en cours ; et/ou o l'appel d'une page de clôture préférentiellement au format HTML ; - si le processus local de clôture consiste en la fermeture de la fenêtre en cours, le serveur, après avoir reçu la requête correspondante du navigateur, provoque la fermeture de la session qui se traduit par la fermeture de la fenêtre en cours ; - si le processus local de clôture consiste en un appel de la page HTML de clôture, le serveur, après avoir reçu la requête correspondante du navigateur, provoque la fermeture de la session et l'envoi de la page de clôture qui est affichée par le navigateur dès réception. De cette manière, un défaut d'assiduité de l'utilisateur détecté et confirmé se traduit par la fermeture automatique de la session en cours. Evidemment, ce processus ACLS peut comporter des étapes supplémentaires qui permettent par exemple, l'initialisation d'au moins un compteur supplémentaire, tel qu'un compteur timer4, faisant courir un délai d4. Ces étapes supplémentaires consistent à répéter n fois la séquence correspondant à l'initialisation d'un compteur, au contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé fixé par ledit compteur, au déclenchement d'une alarme par le navigateur dans l'hypothèse où aucun signal d'assiduité n'est détecté. Cette séquence se termine par la mise en oeuvre dudit processus local de clôture de la session. Dans l'hypothèse où un signal d'assiduité de l'utilisateur est détecté, le processus ACLS comprend alors, à la suite de l'étape de détection de ce signal d'assiduité, les étapes suivantes : - la réinitialisation de tous les compteurs préalablement initialisés ; - le retour à l'étape initiale et la relance du processus ACLS. Tel que cela est représenté sur la figure 1.b, lors de la mise en oeuvre du sous - procédé d'établissement d'une session, le serveur après avoir reçu la demande d'authentification de l'utilisateur, et identifié ce dernier, peut préparer un témoin de connexion comportant les paramètres desdits compteurs Limer" et l'inclure dans sa réponse au navigateur. Le navigateur enregistre ensuite ce témoin et initie le processus ACLS. Tel que cela est représenté sur la figure 2.b, lors de la mise en oeuvre d'un plan d'action spécifique anti-intrusion du type susdit, dans l'hypothèse où il existe une identité entre la valeur de la clé de continuité obtenue en mettant en oeuvre le processus spécifique Charon avec celle obtenue avec le premier processus spécifique NewPage, le navigateur peut afficher la page CIBLE demandée et lancer le processus ACLS. Les alarmes Alarme' peuvent être notamment visuelles et/ou sonores. En outre, de manière avantageuse pour l'utilisateur, les compteurs timer" peuvent être paramétrés par l'utilisateur et enregistrés par le serveur de façon à se voir affecter des valeurs de délai d' personnalisées plutôt que standards, l'utilisateur pouvant les ajuster, une fois la session ouverte, de manière à adapter ces délais d' à son rythme. Selon une variante d'exécution, le « Plan d'action anti-intrusion » mais également le processus de contrôle local de l'assiduité de l'utilisateur ACLS peuvent en plus de réaliser la fermeture de la session en cours, provoquer simultanément au moins l'une des actions suivantes : - l'envoi de messages, tels que par exemple des courriels, sur le réseau Internet ; - l'envoi de messages vocaux ou de SMS (« Short Message Service ») à une liste préétablie de contacts ; - la mise en oeuvre de processus multimédia, tels que le déclenchement 25 du fonctionnement d'une caméra ; - la fermeture à distance de portes. REVENDICATIONS1. Procédé permettant de sécuriser l'accès à des données, personnelles et confidentielles, échangées lors d'une communication entre des entités électroniques distantes, constitutive d'une session, caractérisé en ce qu'il comprend notamment la réalisation des étapes suivantes : - le calcul d'une clé de continuité de session CSK1 avant l'émission de chaque requête effectuée dans le cadre de la session ayant pour objet l'obtention d'un ensemble de données, cette clé CSK1 étant intégrée dans ladite requête ; le calcul de cette clé de continuité CSK1 est effectué en mettant en oeuvre un premier processus spécifique ; - le calcul d'une clé de continuité de session CSK2 après la réception de la réponse à ladite requête ; le calcul de cette clé de continuité CSK2 est effectué en mettant en oeuvre un second processus spécifique ; - la comparaison de la valeur de la clé de continuité obtenue CSK2 en mettant en oeuvre le second processus spécifique avec celle obtenue avec le premier processus spécifique CSK1 ; - l'exécution de l'objet de la requête au profit de l'entité l'ayant émise, dans le cas où ces deux valeurs sont égales ; - l'exécution automatique d'un plan d'action spécifique ayant pour objet la clôture de la session en cours dans le cas où ces deux valeurs ne sont pas égales ; et en ce que la clé de continuité de session est spécifique à la session en 25 cours. 2. Procédé selon la revendication 1, caractérisé en ce que la clé de continuité de session CSK comporte seul ou en combinaison, au moins l'un des composants suivants : 30 - un composant RND constitué par un nombre aléatoire qui identifie la session dans une première entité informatique telle qu'un micro-ordinateur ; 15- un composant FROM constitué par un identifiant ayant une correspondance avec la page à partir de laquelle une requête est émise ; - un composant CIBLE constitué par un identifiant ayant une correspondance avec la page cible fournie dans la réponse à ladite requête. 3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'il provoque également la clôture automatique de la session en cours dans le cas où un défaut d'assiduité de l'utilisateur est détecté. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend un sous - procédé d'établissement d'une 15 session entre des entités informatiques distantes, qui comporte notamment les étapes suivantes : - l'ouverture par un utilisateur d'un navigateur ou d'un onglet d'un navigateur compris dans une première entité informatique tel qu'un micro - ordinateur ; 20 - l'appel par l'utilisateur d'un prestataire représenté par une seconde entité informatique telle qu'un serveur informatique ; - l'émission d'une première requête d'initialisation de session par le navigateur à destination du serveur ; - la réception de cette requête par le serveur, suivie de l'ouverture par 25 ce dernier d'une session avec l'ordinateur de l'utilisateur ; - la transmission par le serveur, à destination du navigateur : o d'une page d'accueil dont l'accès a été demandé dans la requête d'initialisation ; o et d'au moins un témoin ; 30 - l'enregistrement par le navigateur du (des) témoin(s) et l'affichage de la page d'accueil ;- la saisie par l'utilisateur de données d'identification, telles qu'un identifiant et un mot de passe dans des emplacements spécifiques figurant sur cette page d'accueil ; - la transmission à destination du serveur, par l'utilisateur, au moyen du navigateur, d'une demande d'authentification comprenant ces données d'identification ; - l'authentification par le serveur dudit utilisateur si les données d'identification sont correctes ; la préparation d'au moins un témoin comprenant le composant RND d'une clé de continuité de session CSK1 qui est constitué par un nombre aléatoire identifiant localement la session ; la transmission par le serveur au navigateur de ce(s) témoin(s) ainsi que de la page initiale de l'espace privé de l'utilisateur ; - l'enregistrement par le navigateur de ce(s) témoin(s) comprenant le composant RND ; l'affichage par le navigateur de la page initiale de l'espace privé sécurisé ; - l'accès par l'utilisateur à cette page initiale de l'espace privé sécurisé. 5. Procédé selon la revendication 4, caractérisé en ce qu'il comprend également un sous - procédé de réalisation d'une transaction entre des entités informatiques distantes, qui comporte notamment les étapes suivantes : - le choix par l'utilisateur d'un des services Si disponibles dans un menu pour effectuer la transaction ; ce choix se traduit par la demande d'une nouvelle page, désignée comme étant la page CIBLE ; - un processus spécifique prépare la requête ayant pour objet d'obtenir la page CIBLE associée au service demandé ; - le calcul par le processus spécifique du composant FROM qui est constitué par un identifiant ayant une correspondance avec la page actuelle, suivi de l'enregistrement par le navigateur d'un témoin comprenant ce composant FROM ;le calcul par le processus spécifique, du composant CIBLE qui est constitué par un identifiant ayant une correspondance avec la page CIBLE ; l'affectation par le navigateur de la clé de continuité de session CSK1 calculé et attendu à la propriété Name de l'objet Windows ; - l'émission d'une requête par le navigateur, à destination du serveur, ayant pour objet l'accès à la page CIBLE ; - le traitement de la demande par le serveur ; la transmission par le serveur, à destination du navigateur, de la page CIBLE demandée ; - la réception par le navigateur de la page CIBLE ; - la mise en oeuvre d'un second processus qui contrôle que la page reçue est celle attendue en comparant la nouvelle clé CSK2 reçue à celle attendue CSK1 et précédemment enregistrée dans la propriété Name par ledit premier processus spécifique, ce processus de contrôle procède à : o la lecture du témoin de connexion comprenant le composant RND; o la lecture du témoin de connexion comprenant le composant FROM ; o la calcul du composant CIBLE de la page reçue ; o le calcul de la clé de continuité de session CSK2 de la page reçue ; - la comparaison par le navigateur de la valeur de la clé de continuité CSK2 obtenue en mettant en oeuvre le second processus spécifique avec la valeur de la clé CSK1 obtenue avec le premier processus spécifique ; - l'affichage de la page CIBLE par le navigateur et l'accès à l'ensemble des données demandé par l'utilisateur dans le cas où ces deux valeurs sont égales, l'utilisateur pouvant saisir les informations nécessaires à la poursuite du service S demandé ; d'autres échanges suivant les mêmes principes peuvent être éventuellement effectués entre l'utilisateur et le prestataire - serveur en mettant de nouveau en oeuvre ce sous - procédé de réalisation d'une transaction ; ou - l'exécution automatique d'un plan d'action spécifique anti-intrusion, ayant pour objet la clôture de la session en cours, dans le cas où ces deux valeurs ne sont pas égales. 6. Procédé selon la revendication 5, caractérisé en ce que la détection d'une telle tentative d'usurpation entraîne la mise en oeuvre d'un plan d'action spécifique anti-intrusion comportant 10 notamment les étapes suivantes : - l'émission d'une requête par le navigateur à destination du serveur, cette requête ayant pour objet l'accès à la page « Plan d'action antiintrusion » correspondant au plan d'action ; - le traitement de la demande par le serveur suivi par la fermeture de la 15 session et de la transmission à destination du navigateur, de la page correspondant au plan d'action ; - la réception par le navigateur de cette page « Plan d'action » ; l'exécution par le navigateur du (des) action(s) figurant dans ledit plan d'action ; 20 la fermeture par le navigateur de la fenêtre ouverte, qui se traduit par la fermeture de la session en cours avec le serveur. 7. Procédé selon l'une des revendications 3 à 6, caractérisé en ce qu'il comprend un processus de contrôle local de l'assiduité 25 de l'utilisateur qui comporte notamment les étapes suivantes : - l'initialisation d'un compteur timer' tel qu'une horloge, par le navigateur, à la suite de la réception et de l'affichage par ce dernier d'une page transmise par le serveur ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité 30 de l'utilisateur pendant un délai prédéterminé dl qui a commencé à courir à compter de l'initialisation dudit compteur Limer' ; - dans l'hypothèse où à l'expiration dudit délai prédéterminé di, aucun signal d'assiduité n'est détecté, le déclenchement d'une alarme Alarmel est provoqué par le navigateur, suivi de l'initialisation d'un compteur timer2 du type susdit ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé d2 qui a commencé à courir à compter de l'initialisation dudit compteur timer2 ; - dans l'hypothèse où à l'expiration dudit délai prédéterminé d2, aucun signal d'assiduité n'est détecté, le déclenchement d'une alarme Alarme2 est provoqué par le navigateur, suivi éventuellement de l'initialisation d'un compteur timer3 du type susdit ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé d3 qui a commencé à courir à compter de l'initialisation dudit compteur timer3 ; - dans l'hypothèse où à l'expiration dudit délai prédéterminé d3, aucun signal d'assiduité n'est détecté, le déclenchement d'une alarme Alarme3 est provoqué par le navigateur ; - le contrôle par le navigateur de la survenance d'un signal d'assiduité de l'utilisateur pendant un délai prédéterminé qui a commencé à courir à compter du déclenchement de Alarme3 ; - dans l'hypothèse où à l'expiration dudit délai prédéterminé aucun signal d'assiduité n'est détecté, le déclenchement par le navigateur du processus local de clôture de la session qui peut consister en : o la fermeture de la fenêtre en cours ; et/ou o l'appel d'une page de clôture ; - si le processus local de clôture consiste en la fermeture de la fenêtre en cours, le serveur, après avoir reçu la requête correspondante du navigateur, provoque la fermeture de la session et se conclut par la fermeture de la fenêtre en cours ; - si le processus local de clôture consiste en un appel de la page de clôture, le serveur, après avoir reçu la requête correspondante du navigateur, provoque la fermeture de la session et l'envoi de la page de clôture qui est affichée par le navigateur dès réception. 8. Procédé selon la revendication 7,caractérisé en ce que dans l'hypothèse où un signal d'assiduité de l'utilisateur est détecté, le processus de contrôle local de l'assiduité comprend alors, à la suite de l'étape de détection de ce signal d'assiduité, les étapes suivantes : - la réinitialisation de tous les compteurs préalablement initialisés ; - le retour à l'étape initiale et la relance du processus de contrôle local de l'assiduité. 9. Procédé selon la revendication 8, caractérisé en ce que lors de la mise en oeuvre du sous - procédé d'établissement d'une session, le serveur après avoir reçu la demande d'authentification de l'utilisateur, et identifié ce dernier, prépare un témoin comportant les paramètres desdits compteurs timern et l'inclut dans sa réponse au navigateur ; le navigateur enregistre ensuite ce témoin et initie le processus de contrôle local de l'assiduité ; en outre, lors de la mise en oeuvre d'un plan d'action spécifique anti-intrusion du type susdit, dans l'hypothèse où il existe une identité entre la valeur de la clé de continuité obtenue en mettant en oeuvre le second processus spécifique avec celle obtenue avec le premier processus spécifique, le navigateur affiche la page CIBLE demandée et lance le processus de contrôle local de l'assiduité. 10. Procédé selon l'une des revendications 8 et 9, caractérisé en ce que le « Plan d'action anti-intrusion » mais également le processus de contrôle local de l'assiduité de l'utilisateur peuvent en plus de réaliser la fermeture de la session en cours, provoquer simultanément : - l'envoi de messages, tels que par exemple des courriels, sur le réseau Internet ; - l'envoi de messages vocaux ou de SMS à une liste préétablie de contacts ; - la mise en oeuvre de processus multimédia, tels que le déclenchement du fonctionnement d'une caméra ; - la fermeture à distance de portes.