Sécurité sous UNIX

 ^{1 sur 10}     Le modèle de sécurité UNIX

La plupart des serveurs Web UNIX gèrent une liste des utilisateurs autorisés à utiliser le serveur Web. Ce fichier d'accès est distinct de la liste des utilisateurs et des groupes qui peuvent se connecter à l'ordinateur de façon interactive.

Le fichier d'accès d'un serveur Web contient les noms et les mots de passe de chaque utilisateur et des informations détaillées sur le contenu, des scripts CGI et d'autres ressources auxquelles chaque utilisateur est autorisé à accéder. Sur les serveurs Web Apache et NCSA, ce fichier s'appelle .htaccess ; sur les serveurs Netscape, il s'appelle .nsconfig. Le fichier d'accès associe des niveaux d'autorisation à des utilisateurs, des groupes et des adresses IP : GET (lecture), POST (exécution), PUT (écriture) et DELETE (suppression). Par exemple, un auteur exploitant FrontPage sera autorisé à utiliser les commandes HTTP POST (pour accéder aux extensions serveur FrontPage et enregistrer un nouveau contenu), et un visiteur de site Web disposant d'autorisations de navigation pourra utiliser les commandes HTTP GET (pour lire le contenu). Les listes qui définissent les membres de chaque groupe (les auteurs, par exemple) sont définies dans des fichiers distincts sur lesquels pointe le fichier d'accès.

Il est fréquent que plusieurs fichiers d'accès soient stockés sur un serveur Web. Chaque fichier définit la sécurité du répertoire qui le contient et de ses sous-répertoires qui n'ont pas de fichier d'accès propre. En créant des fichiers d'accès pour tout le contenu d'un serveur Web, on permet à plusieurs groupes d'utilisateurs disposant de niveaux d'autorisation distincts d'accéder à des zones différentes du serveur.

Pour accéder au système de fichiers de l'ordinateur hôte et exécuter des scripts et des programmes sur cet ordinateur, le serveur Web s'exécute en tant que compte UNIX (« www » le plus souvent) ; les traitements qu'il exécute et les fichiers auxquels il accède doivent donc être accessibles avec les autorisations de ce compte. Cela peut poser un problème de sécurité dans un environnement multi-hôtes, car le script CGI d'un utilisateur donné pourra lire les fichiers d'une zone de contenu du serveur appartenant à un autre utilisateur. Ce problème est encore plus aigu si l'accès en écriture est pris en charge, comme c'est le cas avec le client FrontPage. Si le script CGI d'un utilisateur dispose des autorisations suffisantes pour écrire des données dans un fichier appartenant à la zone de contenu de l'utilisateur, ce script pourra effectuer des opérations d'écriture dans des fichiers ou remplacer des fichiers se trouvant dans la zone de contenu d'autres utilisateurs.

Pour gérer ce problème (commun à tous les scripts CGI, y compris aux extensions serveur FrontPage), vous pouvez paramétrer le bit SUID (Set User ID : définir l'identificateur d'utilisateur) des autorisations d'exécution d'un script CGI. Cela force le serveur Web et le contenu en cours de création à basculer sur le compte utilisateur UNIX du propriétaire du traitement du script CGI lorsque ce script est exécuté. Ce dernier étant stocké dans une zone de contenu, et le compte du propriétaire du contenu n'étant vraisemblablement pas autorisé à effectuer des opérations d'écriture dans les zones de contenu d'autres utilisateurs, paramétrer le bit SUID du script empêche toute opération d'écriture non autorisée sur les fichiers. À l'aide des outils d'administration des extensions serveur FrontPage, vous pouvez configurer les fichiers exécutables des extensions serveur FrontPage de chaque zone de contenu pour qu'ils exécutent SUID.

Lors de l'authentification sur un serveur Web UNIX, quand un visiteur parcourt une page d'un serveur Web :

1. Le serveur Web reçoit une requête HTTP GET assortie d'un nom d'utilisateur et d'un mot de passe.
2. Le serveur Web vérifie les autorisations de l'utilisateur dans le fichier d'accès approprié.

   Si l'authentification de l'utilisateur conclut que la commande GET ne peut pas être exécutée, le serveur Web renvoie l'erreur 401, qui indique que l'utilisateur ne dispose pas des autorisations suffisantes. Le navigateur Web vous invite à fournir d'autres nom d'utilisateur et mot de passe et soumet à nouveau la requête.

3. Une fois l'utilisateur authentifié, le serveur Web essaie d'extraire le contenu à partir du système de fichiers UNIX. Si ce dernier autorise le serveur à accéder au contenu, il est envoyé au navigateur Web via HTTP.
   

Les requêtes POST sont traitées de la même façon. Quand un serveur Web reçoit une requête HTTP POST, comme lorsqu'un auteur utilisant FrontPage envoie une requête aux extensions serveur FrontPage, le serveur Web vérifie les autorisations de l'utilisateur dans le fichier d'accès approprié. Une fois l'utilisateur authentifié, le serveur Web essaie d'exécuter le programme demandé par la requête POST. Si le bit SUID du programme est paramétré, le traitement s'exécute sous le compte utilisateur UNIX du propriétaire du fichier. Sinon, il s'exécute sous le compte UNIX du serveur Web.

Les serveurs Web UNIX authentifient généralement les programmes clients avec l'authentification de base : le navigateur Web (ou le client FrontPage) demande son nom d'utilisateur et son mot de passe à l'utilisateur, informations qui sont ensuite transmises en clair. (Certains serveurs Web utilisent la technique de cryptage MD5, mais pas FrontPage.)

FrontPage utilise l'authentification de base car c'est la seule technique d'authentification qui fonctionne avec tous les pare-feux et serveurs proxy. Cette technique transmettant les mots de passe sur le réseau sous un format facile à décoder, il est très simple de les voler. Si cela vous pose un problème de sécurité, nous vous conseillons d'utiliser Secure Sockets Layer (SSL) pour crypter toutes les communications impliquant votre serveur Web.