L ES EVOLUTIONS DU SITE I NTERNET P REVADIES FR

Après l’analyse des mécanismes de sécurité sur le site Internet Prevadies.fr, il semble que celui- ci soit suffisamment protégé pour offrir une interface de consultation des décomptes dématérialisés.

La création de nouvelles pages Internet et la modification de certaines existantes sont un préalable à la mise en ligne de la fonctionnalité d’accès aux décomptes. Pour cela, les travaux sur le site portent à la fois sur les interfaces (IHM) et sur la gestion des fichiers PDF de décomptes. Les développements concernent :

- Les formulaires liés à l’inscription au service de dématérialisation : il s’agit ici de modifier des formulaires existants en rajoutant les champs de saisie des données liées au service, en particulier le choix de l’adhérent. Cette étape du projet n’est pas décrite car elle ne présente ni difficulté ni choix techniques à effectuer.

- La création de nouveaux formulaires spécifiques aux décomptes électroniques, tel que la page web de consultation des décomptes reçus.

6.5.3.2.1. L’identification des décomptes disponibles

Fonction de hachage MD5 Adhérent internaute Script ASP Comparaison des 2 signatures MD5 Serveur Web NoheProd Fonction de hachage MD5 Internet Mot de passe

en clair Mot de passe chiffré

Mot de passe chiffré Mot de passe en clair Echec ou réussite de l’identification

Figure 34 : Processus d'authentification à l’espace adhérent

Chronosprev Table UtilWeb

93

L’affichage des décomptes disponibles d’un adhérent sur le site Internet passe par la recherche des fichiers PDF correspondants. Deux possibilités s’offrent à nous :

- Le parcours de l’arborescence de fichiers directement sur le serveur de stockage, rendu possible par nos choix préalables en matière d’organisation du stockage : un répertoire par adhérent. En revanche, un accès réseau doit être mis en place entre le serveur web et le serveur de stockage et les temps de recherche des fichiers risquent de grever la fluidité du site Internet.

- L’accès à la table d’indexation – INSCRSERV – sur la base InternetDB du serveur CHRONOSPREV, sur laquelle un index a été créé sur l’identifiant d’adhérent, ce qui augure de bonnes performances.

L’accès à la table INSCRSERV a été privilégié : le serveur web va ainsi récupérer le nom des fichiers de décomptes de l’adhérent authentifié sur le site Prevadies.fr où des liens permettent d’accéder à chacun d’eux, la requête SQL étant paramétrable avec la variable de session contenant le numéro d’adhérent.

La première interface dédiée à la restitution des décomptes est la page web suivante qui affiche sous forme d’icones l’ensemble des décomptes disponibles dans l’ordre chronologique décroissant pour l’adhérent connecté.

Un clic sur l’un de ces éléments graphiques permet à l’Internaute de télécharger le document PDF correspondant. Une fois les décomptes disponibles pour un adhérent recensés et présentés sur la page web ci-dessus, l’internaute à la possibilité de les télécharger sur son poste. Pour cela, le serveur web doit lui-même le « télécharger » sur le serveur de stockage, puis l’envoyer vers le client web.

6.5.3.2.2. La recherche d’un fichier PDF sur le serveur de stockage

94

La deuxième étape dans l’envoi du fichier PDF vers le client web consiste à aller rechercher le fichier PDF correspondant au décompte sélectionné par l’adhérent.

Le problème rencontré ici tient à la méthode de récupération du fichier PDF, puisque le serveur web et le serveur de stockage ne sont pas sur le même sous-réseau : le premier est en DMZ alors que le second est sur le réseau local. Sachant que tout accès depuis la DMZ vers le réseau local peut représenter un risque pour la sécurité des systèmes, nous avons donc décrit les différentes possibilités à notre disposition dans le tableau ci-après

Protocole Avantages Inconvénients

NetBIOS Protocole de partage de fichiers natif _{dans Windows}

Protocole non sécurisé

autorise l’accès à l’ensemble des

ressources d’une machine (imprimantes, …)

FTP Transfert de fichiers uniquement Protocole non sécurisé : les informations _{circulent sur le réseau en clair}

FTPs, SCP 40 _{Protocoles sécurisés} Achat de licences nécessaires

Protocole « maison »

Fonctionnement connu par Prévadiès uniquement, procurant une sécurité supplémentaire

Protocole non standard

Solution non éprouvée face aux protocoles standards

L’usage à Prévadiès est d’utiliser des outils de communication standards. Ainsi, même si l’écriture d’un protocole de transfert de fichier « maison » semblait répondre à nos besoins en termes de sécurité, cette solution ne sera pas retenue. De même les protocoles dits « sécurisés » permettent de transférer des fichiers de façon standard, ils ne font pas partie des solutions adoptées par Prévadiès.

Ne restent à notre disposition que les protocoles non sécurisés, c'est-à-dire qui font circuler les informations en clair sur le réseau. Nous écarterons d’emblée l’usage du partage de ressources natif dans Windows (NetBIOS), car ses fonctionnalités vont au-delà de nos besoins, ce qui représente autant de failles potentielles dans la sécurité du réseau.

Enfin, le protocole FTP reste le seul à notre disposition et est utilisé couramment à Prévadiès. La couche logicielle du serveur FTP propose des options de configuration propres à contrôler les accès :

- en limitant les clients capables de s’y connecter : seul le serveur web sera à même d’y accéder (filtre par adresse IP)

- en interdisant de lister l’arborescence des fichiers : le chemin d’accès doit être connu par avance pour accéder à une ressource.

Même si la sécurité n’est pas assurée de façon optimale à ce niveau, elle nous paraît suffisante étant donné que le serveur de stockage n’est pas accessible directement depuis l’extérieur et l’ouverture du port 21 nécessaire au FTP entre la DMZ et le réseau local ne nous semble pas remettre en cause la sécurité du réseau local.

6.5.3.2.3. L’envoi des données par le serveur web vers le client web

95

Initialise l’objet MSXML2.XMLHTTP et récupère le contenu de l’url passée en paramètre.

Ajout d’un header au contenu de l’objet MSXML2.XMLHTTP pour définir un nom de fichier.

Information du navigateur client du type du fichier à venir et envoi du contenu de l’objet MSXML2.XMLHTTP.

Une fois récupéré sur le serveur de stockage, le fichier PDF est envoyé au navigateur web de l’adhérent pour y être visualisé.

Notre réflexion nous a tout d’abord conduits vers un transfert en trois temps :

- le FTP vers le serveur de stockage copie tout d’abord le fichier dans un répertoire temporaire public du serveur web,

- le serveur web envoi ensuite le fichier temporaire vers le client web, - le fichier temporaire est enfin supprimé du serveur web

Cette éventualité, tout en complexifiant l’opération de transfert avec une gestion de fichiers temporaires, ouvre une faille de sécurité non négligeable en mettant à disposition dans un répertoire public et donc accessible à tous un décompte personnel. Pour cette raison, nous nous sommes attachés à trouver une autre solution plus adaptée.

Cette nouvelle solution fait appel à un objet ActiveX et permet de rechercher et envoyer le fichier PDF en une seule étape tout en s’affranchissant d’une gestion de fichier temporaire. Pour cela nous utilisons l’objet ActiveX MSXML2.XMLHTTP dont l’usage est d’exécuter une requête HTTP en mode asynchrone. Cet objet s’implémente comme suit en langage ASP en lui indiquant comme url le chemin d’accès via le protocole FTP du fichier PDF :

Dim Lap

Set Lap = Server.CreateObject("MSXML2.XMLHTTP") Lap.Open "GET", url, False

Lap.send

Response.AddHeader "Content-Disposition", "attachment;filename=""nom_fichier.pdf" »" Response.ContentType = « application/pdf »

Response.BinaryWrite Lap.responseBody

Ici, le fichier PDF est positionné en « cache » dans l’objet MSXML2.XMLHTTP dont une instance est créée pour chaque internaute connecté, ce qui permet de ne plus être confronté à des données partagées entre tous les clients. A ce stade, une inconnue demeure : le temps d’établissement de la communication avec le protocole FTP. Les premiers tests nous ont permis de rapidement lever nos doutes, puisque l’établissement des la communication FTP est quasi instantanée (moins de 0,4 secondes en moyenne).