Sécurité des connexions

Vous pouvez sécuriser les connexions à votre serveur Web 4D à l'aide des éléments suivants :

• Pour les accès Web, la combinaison du système de gestion des mots de passe (mode BASIC ou mode DIGEST) et de la Méthode base Sur authentification Web,
• La définition d’un “Utilisateur Web générique”,
• La définition d’un dossier racine HTML par défaut,
• La définition de la propriété “Disponible via les balises et les URLs 4D (4DACTION…)” pour chaque méthode projet de la base,
• L'option de prise en charge spécifique des requêtes de synchronisation via HTTP.

Notes :

• La sécurité des informations transmises via la connexion est prise en charge par le protocole TLS/SSL. Pour plus d'informations, reportez-vous à la section Utiliser le protocole TLS.
• Pour une vue d'ensemble des fonctionnalités de 4D liées à la sécurité, reportez-vous au 4D Security guide.
  

Vous pouvez définir, dans les Propriétés de la base, le système de contrôle d’accès que vous souhaitez appliquer à votre serveur Web. Deux modes d'authentification sont proposés : le mode BASIC et le mode DIGEST. Le mode d’authentification concerne la manière dont sont collectées et traitées les informations relatives au nom d’utilisateur et au mot de passe.

• En mode BASIC, le nom et le mot de passe saisis par l’utilisateur sont envoyés en clair dans les requêtes HTTP. Ce principe n’assure pas une sécurité totale au système dans la mesure où ces informations peuvent être interceptées et utilisées par un tiers.
• Le mode DIGEST procure un niveau de sécurité plus élevé car les informations d’authentification sont traitées par un processus unidirectionnel appelé hachage qui rend leur contenu impossible à décrypter.

Côté utilisateur, l’emploi d’un mode d’authentification ou de l’autre est transparente.

Notes :

• Pour des raisons de compatibilité, le mode d’authentification BASIC est utilisé par défaut dans les bases 4D converties en version 11 (si l’option “Utiliser mots de passe” était cochée dans la version précédente). Vous devez activer explicitement le mode Digest.
• L’authentification Digest est une fonction de HTTP1.1 et n’est pas prise en charge par tous les navigateurs. Par exemple, seules les versions 5.0 et suivantes du navigateur Microsoft Internet Explorer acceptent ce mode. Si un navigateur ne prenant pas en charge cette fonctionnalité adresse une demande au serveur Web alors que l’authentification Digest est activée, le serveur rejette la demande et retourne un message d’erreur au navigateur.

Le choix du mode d'authentification s’effectue dans la page Web/Options (I) de la boîte de dialogue des Propriétés de la base :

Dans la zone “Mots de passe”, vous disposez de trois options :

• Pas de mots de passe : aucune authentification n’est effectuée pour la connexion au serveur Web. Dans ce cas :
  
  • Si la Méthode base Sur authentification Web existe, elle est exécutée et, outre $1 et $2, seules les adresses IP du navigateur et du serveur ($3 et $4) sont renseignées, le nom d’utilisateur et le mot de passe ($5 et $6) sont vides. Vous pouvez dans ce cas filtrer les connexions en fonction de l’adresse IP du navigateur et/ou de l’adresse IP demandée du serveur.
  • Si la Méthode base Sur authentification Web n’existe pas, les connexions sont automatiquement acceptées.
• Mots de passe protocole BASIC : authentification standard en mode BASIC. Lorsqu'un utilisateur se connecte, une boîte de dialogue lui permettant de saisir son nom et son mot de passe s'affiche sur son navigateur. Ces deux valeurs sont ensuite envoyées en clair à la Méthode base Sur authentification Web avec les autres paramètres de la connexion (adresse et port IP, URL...) pour que vous puissiez les traiter.
  Ce mode donne accès à l'option Inclure les mots de passe 4D, permettant d’utiliser, au lieu ou en plus de votre propre système, le système 4D de mots de passe de la base (défini dans 4D).
• Mots de passe protocole DIGEST : authentification en mode DIGEST. Comme en mode BASIC, l'utilisateur doit saisir son nom et son mot de passe lorsqu'il se connecte. Ces deux valeurs sont alors envoyées cryptées à la Méthode base Sur authentification Web avec les autres paramètres de la connexion. Vous devez authentifier l'utilisateur à l’aide de la commande WEB Valider digest.

Notes :

• Vous devez redémarrer le serveur Web pour que les modifications effectuées sur ces paramètres soient prises en compte
• Avec le serveur Web de 4D Client, il est à noter que tous les sites publiés par les postes 4D Client partageront la même table d’utilisateurs. En effet, la validation des utilisateurs/mots de passe est effectuée par l’application 4D Server.

Si vous utilisez le mode BASIC, le système de filtrage des connexions au serveur Web de 4D dépend de la combinaison de deux paramètres :

• les options de mots de passe Web dans la boîte de dialogue des Propriétés de la base,
• l’existence ou non de la Méthode base Sur authentification Web.

Voici les différentes possibilités de contrôle des connexions :

L’option “Mots de passe protocole BASIC” est cochée et l’option “Inclure les mots de passe de 4D” n’est pas cochée

• Si la Méthode base Sur authentification Web existe, elle est exécutée et tous ses paramètres sont renseignés. Vous pouvez dans ce cas filtrer très précisément les connexions à partir du nom d’utilisateur, du mot de passe et/ou des adresses IP du navigateur et du serveur Web.
• Si la Méthode base Sur authentification Web n’existe pas, la connexion est automatiquement refusée et un message indiquant que la méthode d’authentification n’existe pas est envoyé au navigateur.

Note : Si le nom d’utilisateur envoyé est une chaîne vide et si la Méthode base Sur authentification Web n’existe pas, une boîte de dialogue de demande de mot de passe est envoyée au navigateur.

Les options “Mots de passe protocole BASIC” et “Inclure les mots de passe de 4D” sont cochées

• Si le nom d’utilisateur envoyé par le navigateur existe dans la table des utilisateurs 4D et que le mot de passe est valide, la connexion est acceptée (dans ce cas, pour des raisons de sécurité le paramètre $6 n’est alors pas renseigné). Si le mot de passe est invalide, la connexion est refusée.
• Si le nom d’utilisateur envoyé par le navigateur n’existe pas dans 4D, deux cas sont alors possibles :
  
  • si la Méthode base Sur authentification Web existe, les paramètres $1, $2, $3, $4, $5 et $6 sont renseignés. Vous pouvez dans ce cas filtrer très précisément les connexions à partir du nom d’utilisateur, du mot de passe et/ou des adresses IP du navigateur et du serveur Web.
  • si la Méthode base Sur authentification Web n’existe pas, la connexion est refusée.

A la différence du mode BASIC, le mode DIGEST n’est pas compatible avec les mots de passe 4D standard : il n’est pas possible d’utiliser les mots de passe 4D comme identifiants Web. L’option “Inclure les mots de passe 4D” est grisée lorsque ce mode est sélectionné. Les identifiants des utilisateurs Web doivent être gérés de façon personnalisée (par exemple via une table).
Lorsque le mode DIGEST est activé, le paramètre $6 (mot de passe) est toujours retourné vide dans la Méthode base Sur authentification Web. En effet dans ce mode, cette information ne transite pas en clair par le réseau. Vous devez impérativement dans ce cas évaluer la demande de connexion à l’aide de la commande WEB Valider digest.

Le fonctionnement du système d’accès au serveur Web 4D est résumé dans le schéma suivant :

Certains robots (moteurs de recherche, spiders) parcourent les serveurs Web et les pages statiques. Si vous souhaitez que les robots ne puissent pas accéder à la totalité de votre site, il est possible de définir des URL qui leur seront interdits.
Pour cela, placez un fichier nommé ROBOTS.TXT à la racine du serveur. Ce fichier doit être structuré de la manière suivante :

“User-Agent: *” signifie qu’il s’agit de tous les robots.
“Disallow: /4D” signifie que les robots ne doivent pas accéder aux URL commençant par /4D.
“Disallow: /%23%23” signifie que les robots ne doivent pas accéder aux URL commençant par /%23%23.
“Disallow: /GIFS/’ signifie que les robots ne doivent pas accéder au dossier /GIFS/ ni aux sous-dossiers.

Autre exemple :

Vous pouvez désigner un utilisateur — préalablement défini dans la table des mots de passe de 4D — comme “Utilisateur Web générique”. Dans ce cas, chaque navigateur se connectant à la base bénéficie des autorisations et restrictions d’accès associées à cet utilisateur. Vous pouvez ainsi contrôler simplement l’accès des navigateurs aux différentes parties de la base.

Note : Il ne faut pas confondre cette option, permettant de restreindre les accès des navigateurs aux différentes parties de l'application (méthodes, formulaires, etc.), avec le système de contrôle des connexions au serveur Web, géré par les mots de passe et la Méthode base Sur authentification Web.

Pour définir un Utilisateur Web générique :

1. En mode Développement, créez au moins un utilisateur dans l’Editeur de mots de passe.
   Vous pouvez lui associer ou non un mot de passe.
2. Dans les différents éditeurs de 4D, assignez à cet utilisateur les autorisations et restrictions d’accès souhaitées.
3. Dans la boîte de dialogue des Propriétés, choisissez le thème Web, page Options (I).
   La zone “Mots de passe Web” contient la liste déroulante Utilisateur Web générique. Par défaut, l’utilisateur Web générique est le Super_Utilisateur : les navigateurs disposent donc d’un accès libre à toutes les parties de la base.
4. Choisissez l’utilisateur dans la liste déroulante et validez la boîte de dialogue.

Tous les navigateurs Web autorisés à se connecter à la base bénéficieront des autorisations et restrictions d’accès associées à l’utilisateur Web générique (sauf lorsque le mode BASIC et l’option “Inclure les mots de passe 4D” sont cochés et que l’utilisateur qui se connecte existe dans la table des mots de passe 4D, cf. ci-dessous).

L’option “Mots de passe protocole BASIC” n’influe pas sur le mécanisme de l’utilisateur Web générique : quel que soit l’état de cette option, les privilèges et restrictions d’accès associés à l’“Utilisateur Web générique” seront appliqués à tous les navigateurs Web autorisés à se connecter à la base.

En revanche, lorsque l’option "Inclure les mots de passe 4D" est cochée, deux cas peuvent se produire :

• Le nom et le mot de passe de l’utilisateur n’existent pas dans la table des mots de passe de 4D. Dans ce cas, si la connexion est acceptée par la Méthode base Sur authentification Web, les droits d’accès de l’utilisateur Web générique seront appliqués au navigateur.
• Le nom et le mot de passe de l’utilisateur existent dans la table des mots de passe de 4D. Dans ce cas, le paramètre “Utilisateur Web générique” est ignoré : l’utilisateur se connecte avec ses propres droits d’accès.

Cette option des Propriétés de la base vous permet de définir le dossier dans lequel 4D recherchera les pages HTML statiques et semi-dynamiques, les images, etc., à envoyer aux navigateurs.

De plus, le dossier racine HTML définit, sur le disque dur du serveur Web, le niveau hiérarchique au-dessus duquel les fichiers ne seront pas accessibles. Cette restriction d’accès s’applique aux URLs demandés par les navigateurs Web ainsi qu’aux commandes du serveur Web 4D telles que WEB ENVOYER FICHIER. Si un URL demandé par un navigateur ou une commande 4D tente d’accéder à un fichier situé en amont du dossier racine HTML, une erreur est retournée, indiquant que le fichier n’a pas été trouvé.

Par défaut, 4D définit un dossier racine HTML intitulé DossierWeb. S'il n'existe pas déjà, le dossier racine HTML est créé sur le disque au premier lancement du serveur Web.
Si vous conservez l'emplacement par défaut, le dossier racine est créé :

• avec 4D en mode local et 4D Server, au même niveau que le fichier de structure de la base.
  Note : dans le cadre d'une application compilée et fusionnée, le fichier de structure est placé dans le sous-dossier Database. 
• avec 4D en mode distant, dans le dossier local de la base 4D (cf. commande Dossier 4D).

Vous pouvez modifier le nom et l'emplacement du dossier racine HTML par défaut dans la boîte de dialogue des Propriétés de la base (thème Web, page Configuration) :

Dans la zone “Racine HTML par défaut”, saisissez le nouveau chemin d’accès du dossier que vous souhaitez utiliser.
Le chemin d’accès saisi dans cette boîte de dialogue est relatif : il est établi à partir du dossier contenant la structure de la base (4D en mode local ou 4D Server) ou du dossier contenant l'application ou le progiciel 4D (4D en mode distant).
Afin d’assurer la compatibilité multiplate-forme de vos bases, le serveur Web 4D utilise, pour décrire les chemins d’accès, des conventions d’écriture particulières. Les règles de syntaxe sont les suivantes :

• les dossiers sont séparés par le caractère /
• le chemin ne doit pas se terminer par /
• pour “remonter” d’un niveau dans la hiérarchie des dossiers, saisissez “..” (point point) devant le nom du dossier,
• le chemin ne doit pas commencer par / (sauf si vous souhaitez que le dossier racine HTML soit le dossier de la base ou du 4D distant, cf. ci-dessous).

Par exemple, si vous souhaitez que le dossier racine HTML soit le sous-dossier “Web”, placé dans le dossier “Base4D”, saisissez Bases4D/Web
Si vous souhaitez que le dossier racine HTML soit le dossier de la base ou du 4D distant, mais que l’accès aux dossiers des niveaux supérieurs soit interdit, saisissez / dans la zone. Pour que l’accès aux volumes soit totalement libre, laissez la zone “Racine HTML par défaut” vide.

ATTENTION : Si vous ne définissez aucun dossier racine HTML par défaut, le dossier contenant le fichier de structure de la base ou l'application 4D est utilisé. Dans ce cas, il n’y a pas de restrictions d’accès (tous les volumes sont accessibles).

Notes :

• Lorsque le dossier racine HTML est modifié dans les Propriétés de la base, le cache est effacé afin de ne pas conserver des fichiers dont l’accès serait devenu restreint.
• Il est possible de définir dynamiquement le dossier racine HTML par défaut à l’aide de la commande WEB FIXER RACINE. Dans ce cas, la modification s’applique à tous les process Web courants pour la session de travail. Le cache des pages HTML est alors effacé.

L'URL spécial 4DACTION, les balises 4DSCRIPT, 4DEVAL, 4DTEXT, 4DHTML (ainsi que les anciennes balises 4DVAR et 4DHTMLVAR) permettent de déclencher l'exécution de toute méthode projet d’une base 4D publiée sur le Web. Par exemple, la requête http://www.serveur.com/4DACTION/Effacer_Tout provoque l'exécution de la méthode projet Effacer_Tout, si elle existe.

Ce mécanisme présente donc un risque pour la sécurité de la base, notamment si un internaute déclenche intentionnellement ou par erreur une méthode non destinée à une exécution via le Web. Vous pouvez prévenir ce risque de trois manières :

• restreindre les accès aux méthodes projet via le système de mots de passe 4D. Inconvénients : ce système nécessite l'utilisation des mots de passe 4D et interdit tout type d'exécution de la méthode (y compris via des balises HTML).
• filtrer les méthodes appelées via des URLs à l'aide de la Méthode base Sur authentification Web. Inconvénients : si la base comporte de nombreuses méthodes, ce système peut être difficile à gérer.
• utiliser l'option Disponible via les balises et les URLs 4D (4DACTION…) affichée dans la boîte de dialogue des Propriétés des méthodes projet :

  

Cette option permet de désigner individuellement chaque méthode projet pouvant être appelée via l'URL spécial 4DACTION et les balises 4DSCRIPT, 4DEVAL, 4DTEXT et 4DHTML (ainsi que 4DVAR et 4DHTMLVAR). Lorsqu’elle est désélectionnée, la méthode projet concernée ne peut pas être exécutée via une requête HTTP contenant un URL ou une balise spécial(e). En revanche, elle peut être exécutée à l'aide d’autres types d'appels (formules, autres méthodes, etc.).

Cette option est désélectionnée par défaut à la création d'une base. Vous devez désigner expressément les méthodes pouvant être exécutées via l'URL 4DACTION et les balises 4D.

Dans l'Explorateur, les méthodes projet ayant cette propriété bénéficient d’une icône spécifique :

Cette option de la page "Web/Configuration" des Propriétés de la base permet de contrôler la prise en charge des requêtes comportant des URLs /4DSYNC. Ces URLs sont utilisés pour la synchronisation des données via HTTP (pour plus d’informations sur ce mécanisme, reportez-vous au paragraphe URL 4DSYNC/).

Cette option a pour effet d’activer ou d’inactiver le traitement spécifique des requêtes contenant /4DSYNC :

• lorsqu’elle n’est pas cochée, les requêtes /4DSYNC sont considérées comme des requêtes standard et ne permettent pas de traitement spéficique (l’utilisation d’une requête de synchronisation provoque l’envoi de la réponse type 404 - ressource indisponible).
• lorsqu’elle est cochée, le mécanisme de synchronisation est activé ; les requêtes /4DSYNC sont considérées comme des requêtes spéciales et sont analysées par le serveur HTTP de 4D.

Par défaut :

• cette option est désélectionnée dans les bases de données créées avec 4D à partir de la version 13.
• cette option est sélectionnée dans les bases de données converties depuis une version de 4D antérieure à la version 13, pour des raisons de compatibilité. Il est recommandé de la désélectionner si votre application n’exploite pas la fonction de réplication par HTTP. 

Cette option a une portée locale à l’application et sa prise en compte nécessite un redémarrage du serveur Web.