On retrouve ce type d'authentification dans la plupart des distributions : Apache permet l'utilisation de fichiers nommés ".htaccess" par défaut. Netscape utilise des fichiers nommés ".nsconfig" dont la syntaxe varie quelque peu.

Du côté de cette syntaxe, nous allons voir celle qui est la plus habituelle, à savoir celle utilisée par Apache ou NCSA HTTPd; un exemple typique de fichier .htaccess est le suivant :

AuthUserFile /repertoire_protege/.htpasswd
AuthGroupFile /dev/null
AuthName Area_51
AuthType Basic
require user roswell
Nous utilisons ici un fichier ".htpasswd" qui est placé dans le répertoire "/repertoire_protege", et qui contient nos paires de login/password de références. Nous verrons ce fichier un peu plus loin; nous n'utilisons pas de fichier définissant des groupes d'utilisateurs : nous sommes dans un cas simple (le paramètre "/dev/null" correspond au device null sous Unix, autrement dit à quelquechose d'inexistant). "Area_51" est le nom que nous donnons à cette authentification (éviter les espaces) et "Basic" est le type d'authentification.

La deuxième partie du fichier est celle où nous allons définir les droits requis pour accéder au contenu du répertoire dans lequel se trouve notre fichier .htaccess . Ainsi dans le cas présent, nous n'autorisons que l'utilisateur "roswell" (attention à la casse) à accéder à notre répertoire. Lors de l'authentification, cet utilisateur donnera son mot de passe qui sera alors comparé à la valeur contenue dans notre fichier de mots de passe, à savoir .htpasswd .

Nous allons voir maintenant qu'il est possible d'affiner ces droits en limitant suivant le cas les hôtes, requêtes HTTP, fichiers accédés, protocoles, etc...
- premier cas, la limitation des requêtes HTTP. HTTP est un protocole de transfert de données utilisé pour le web (c.f. la rfc 2616), qui comporte un nombre limité de fonctions; il est possible de n'accepter que certains types de fonctions pour que, par exemple, les utilisateurs ne puissent qu'accéder en lecture au répertoire. C'est le cas dans l'exemple suivant où nous limitons l'accès aux requêtes (fonctions HTTP) de type GET (lecture) pour les utilisateurs roswell et mulder :

require user roswell mulder

Plus généralement, nous aurons :
require valid-user

où tout utilisateur présent dans la liste du fichier .htpasswd sera autorisé à effectuer des requêtes GET sur le répertoire protégé.
- autre cas, limitation des fichiers accédés :


require valid-user


Nous limitons ici l'accès au fichier spécifié, "index.html", en excluant le reste du répertoire. Cet accès est lui-même limité aux utilisateurs valides (autorisés).

- cas suivant, les restrictions suivant les hôtes :
Expliquons tout d'abord les options utilisées : Order, Deny et Allow. Order permet de spécifier un ordre d'évaluation des critères de test. Allow signifie autoriser les entités satisfaisant le test correspondant et Deny signifie rejeter les entités satisfaisant également le test correspondant. On utilise généralement un combinaison des 2, et suivant l'ordre, la politique de sécurité varie quelque peu.

Dans l'ordre Deny,Allow, les directives Deny sont évaluées avant celles de la clause Allow. Le défaut est d'autoriser l'accès. Tout client qui ne correspond pas à la directive de déni ou qui satisfait au test d'autorisation spécifique Allow se verra autorisé l'accès au serveur web. Dans l'ordre Allow,Deny, les directives Allow sont évaluées avant celles de la clause Deny. Le défaut est d'interdire l'accès. Tout client qui ne correspond pas à la directive d'autorisation ou qui satisfait au test de déni se verra refusé l'accès au serveur web.

- dernier cas, l'authentification sécurisée : elle fait appel au protocole SSL (ou sa version standardisée, TLS) pour les échanges de données, ce qui évite que les mots de passe circulent en clair sur le réseau. Pour l'utiliser, il faut faire des requêtes de type https://... sur un serveur correctement configuré.

AuthDCE On
AuthType Basic
AuthName dce
require valid-user

Aspects pratiques : le fichier .htpasswd

Le fichier htpasswd contient les login et mots de passe des utilisateurs autorisés à accéder aux pages web. Plusieurs fichiers htaccess peuvent utiliser le même fichier htpasswd comme base de secrets (credentials) centrale si la méthode d'authentification est basique. Mais dans tous les cas ce fichier doit être clairement protégé (bien qu'accessible en lecture par le démon pour lui permettre de l'utiliser); le plus souvent, on utilise là encore une protection par htaccess au moyen de la ligne de configuration : "Deny from All", ce qui signifie qu'aucun accès (du démon donc via le web) n'est autorisé.

Par contre, ce fichier reste accessible comme tout autre fichier par le système d'exploitation et donc via les autres services tel que FTP.
Pour créer le fichier ".htpasswd", il faut utiliser la commande *nix htpasswd ou utiliser un site web qui fournit le même service. La commande type est (-c pour création d'un nouveau fichier):

htpasswd -c /répertoire_destination/.htpasswd login

Le système va ensuite demander le mot de passe associé à ce login qu'il va crypter et rajouter au fichier .htpasswd. Voici un exemple de ce que l'on peut trouver dans un fichier .htpasswd :

foobar:Z39sR$s9xLyx
karen:44KvbqBfLZ5Yw
La fonction htpasswd accepte plusieurs types de cryptage des mots de passe :

* -m utilise la fonction de hachage MD5 (128 bits). Attention, Apache utilise une version spécifique de l'algorithme, ce qui signifie qu'il n'est pas interoperable avec les autres serveurs web.
* -d utilise la fonction système crypt(). Pour rappel, cette fonction est basée sur le DES, et est également utilisée pour le cryptage des most de passe système (fichier passwd ou shadow).
* -s utilise la fonction de hachage SHA-1 (160 bits).
* -p laisse les mots de passe en clair.

Faiblesse htaccess : l'authentification HTTP

Comme nous l'avons vu précédemment, htaccess est un processus d'authentification qui va être reconnu par le démon HTTP lorsqu'il essayera d'accéder aux fichiers pour les envoyer au client. Mais cette authentification repose en fait complètement sur les fonctionnalités du protocole HTTP (c.f. la rfc 2617), et le démon va demander au client de s'authentifier via une requête particulière. Prenons l'exemple suivant :

Explications :

* L'utilisateur souhaite accéder à une page web qui s'avère être protégée par htaccess. Concrètement, il y a 2 échanges requête/réponse HTTP qui sont éffectués pour donner accès à cette page.
* Le premier est une requête simple (un GET) signifiant que le client souhaite accéder à la page. La réponse est "401 Authorization Required", ce qui signifie que la page est protégée et nécessite une authentification (de type "Basic"). L'utilisateur ne voit pas cette réponse, seul le navigateur (browser) la voit et affiche en réponse une popup dans laquelle il demande à l'utilisateur de taper son login et mot de passe.
* Après cette opération, le navigateur réitère son GET en ajoutant cette fois-ci les informations de l'utilisateur ("Authorization: Basic QWxpY2U6TGFwaW4=") qui serviront au serveur pour l'authentifier.
* Si tout se passe bien, la requête est acceptée ("200 OK") et l'utilisateur peut accéder à la page web.

Nous avons ici le cas le plus simple : les informations de l'utilisateur circulent quasiment en clair sur le réseau. Prenons l'élément "crypté" : QWxpY2U6TGFwaW4=. Cet élément est en fait "login:password" uuencodé en base 64, ce qui n'est d'aucune protection (l'uuencodage est un procédé servant à coder du binaire en ASCII et inversement, autrement dit de passer de 24 à 32 bits tout en restant dans l'intervalle des caractères imprimables, ce qui permet de transférer des fichiers binaires sous forme de texte par exemple).

Copions cet élément dans un fichier type :
begin-base64 644 my_file QWxpY2U6TGFwaW4= ====
Un simple passage dans la fonction *nix uudecode nous donne :

Alice:Lapin
Nous avons retrouvé le login : "Alice" et le mot de passe : "Lapin".
Il existe une autre méthode utilisée pour coder les informations transitant sur le réseau : on utilise l'algorithme de hash MD5 (c.f. la rfc 1321). Les propriétés d'une fonction de hachage rendent impossible le fait qu'un attaquant puisse remonter aux informations initiales (login/password); de plus, le hasché reste caractéristique de ces données, autrement dit un hasché correspond à un et un seul texte original (dans la limite de son intervalle de sortie, à savoir 2^128 possibilités pour MD5).

Néanmoins, cela ne préserve pas des "replay-attacks", dans lesquelles l'attaquant va se contenter d'intercepter ce hasché et de l'utiliser à son propre compte comme s'il s'agissait du sien : il n'a nul besoin de posséder le texte original puisque c'est le hasché qui est demandé! Pour remédier à cette faiblesse, l'authentification HTTP utilisant cet algorithme va donc rajouter des éléments -uniques- dans le calcul du hasché, le plus souvent en envoyant un challenge (le "nonce") au client lors de la requête d'authentification. Le client va rajouter ce challenge dans le calcul du hasché, le rendant unique par la même occasion (c.f. la rfc 2069 et suivantes).

Malheureusement, cette deuxième méthode d'authentification est peu utilisée (cela dépend entre autres des fonctionnalités du serveur, du navigateur, etc...).
Les navigateurs suivants supportent l'authentification basée sur MD5 :

* Internet Explorer 5.0 et +
* Amaya
* NCSA Mosaic/X 2.7
* Spyglass Mosaic

Alors que ceux-ci ne la supportent pas (liste non-exhaustive):

* Netscape Communicator 4.5 (Mac) et 4.7 (PC)
* iCab Preview 1.7 (Mac)

Avantages et désavantages

La méthode d'authentification par htaccess permet de déléguer le contrôle d'accès au niveau local, et autorise ainsi plus de flexibilité pour créer et changer les droits d'accès suivant les besoins.

Par contre, on comprendra que ce système devient rapidement ingérable lorsque le nombre d'utilisateurs et/ou de répertoires augmentent, rendant toute politique de sécurité globale impossible.
D'autre part, le système reste faible dans son concept; il est basé sur les services du Web à l'exclusion de tous les autres sevices d'Internet, ce qui n'est pas une hypothèse raisonnable. En effet, tout utilisateur malveillant qui a accès au serveur par un autre moyen ou service (ce qui n'est pas irréaliste) sera capable de modifier et corrompre complètement ce système d'authentification. Ainsi on peut dresser une liste (non-exhaustive bien sûr) qui permet de se faire une idée du nombre de menaces à prendre en compte lorsque l'on souhaite utiliser ce système d'authentification :

- accès via FTP (utilisateur autorisé)
- accès via FTP (utilisateur non-autorisé, buffer-overflows et autres exploits type wu-ftpd)
- accès via Telnet (sur services particuliers, la liste étant trop longue pour être citée...)
- accès via Web (script cgi non protégé type PHF, débordements)
- ...

Protéger l'accès à un fichier

On peut protéger un fichier avec la balise . par exemple:

AuthUserFile /exemple/.htpasswd AuthName "Accès restreint" AuthType Basic require valid-user

La balise permet d'effectuer les instructions juste pour un fichier. Cette balise n'accepte qu'un seul fichier, vous aurez donc le même nombre de balises que de fichiers : si vous mettez plusieurs fichiers dans la même balise, Apache retournera une erreur.

Redirection

Lorsque vous saisissez une URL dans votre navigateur en tapant par exemple www.monsite.com, vous êtes automatiquement redirigés vers l'index, par exemple, index.php.
Dans votre httpd.conf, le fichier de configuration d'apache, vous avez par exemple:
DirectoryIndex index.php index.html /erreurs/erreur_403.php
Donc cette instruction dit: Si rien n'est entré, on redirige vers index.php ; s'il n'existe pas, on redirige vers index.html, s'il n'existe pas, on redirige vers erreur_403.php (qui est la page d'interdiction) afin de ne pas afficher tout le contenu du dossier.

Maintenance

On va interdire au visiteur toutes les pages et de le rediriger vers une page de maintenance. à l'aide de cet exemple:

ErrorDocument 403 /maintenance.html deny from all allow from xx.xxx.xxx.xxx allow from all

On définit le fichier d'erreur 403 (l'erreur 403 est l'erreur qui indique que l'accès est interdit) comme étant la page maintenance.html : le site va donc afficher cette dernière lorsque la page est "interdite" (à la place du message Error 403 Forbidden).
deny from all
L'accès à tout le répertoire dans lequel se trouve le .htaccess. est interdit
allow from xx.xxx.xxx.xxx
On autorise l'accès au mainteneur du site

allow from all Et là on autorise à tout le monde le droit de voir le fichier maintenance.html qui sera placé à la racine de votre site

Rewriting

L'url rewriting permet de rediriger votre visiteur Par exemple, si vous saisissez une adresse de type

www.monsite.com/page-1-2.html , en réalité cela correspond à www.monsite.com/page.php?id=1&var=2 .

Cela permet aux moteurs de recherche, qui ont du mal à indexer ce type d'adresse, de vous faire tout de même référencer
On utilise pour cela un fichier .htaccess, placé à la racine de votre site. Et on utilise le mod_rewrite d'Apache. Pour savoir si ce dernier est activé, ouvrez le fichier httpd.conf situé dans le répertoire d'Apache et vérifiez que ces deux lignes ne sont pas des commentaires (un # indique un commentaire) :

LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c


Si elles en sont, décommentez le #

POur vérifier si le mod rewrite fonctionne, on va créer un fichier test.php à la racine de votre site. Ensuite, créez un fichier .htaccess ou bien mieux incorporez ces lignes à un fichier htaccess déjà présent

RewriteEngine on ////crée une règle de redirection où test.html devient test.php).
RewriteRule ^test\.html$ /test.php [L] /////^test\.html$ est une regexp

Ensuite allez sur votre serveur à l'adresse à http://www.votresite.com/test.html.
Si le contenu de ce fichier s'affiche, tout fonctionne , sinon le mod_rewrite n'est pas activé

À présent, on va réecrire toutes les pages de votre site php en *.html.

RewriteRule ^([0-9a-zA-Z-]+)\.html$ /$1.php [L]

Bref, avec ce RewriteRule, index.html renvoie sur index.php, liste-news.html renvoie sur liste-news.php, etc.

Et pour les urls avec des variables,

RewriteRule ^news-([0-9]+)-([0-9]+)-([0-9]+)\.html$ /news.php?var=$1&comm=$2&id=$3 [L]

Conclusion

Nous avons vu que la méthode d'authentification par htaccess comporte beaucoup d'inconvénients, voir de faiblesses, pour un nombre d'avantages assez restreint. Néanmoins, il ne faut pas oublier son principal intérêt qui est le fait qu'elle reste la seule méthode facilement utilisable par le client de base d'un fournisseur d'accès internet et d'espace web. En effet la plupart du temps cette personne n'a pas accès aux serveurs et ne peut donc pas faire appel à des services auxiliaires pour des types d'authentifications alternatives. Les quelques options restantes sont plus compliquées à implémenter (PHP/MySQL par exemple) surtout si l'on souhaite assurer un bon niveau de sécurité (modules cryptographiques en PHP). Et l'on ne parle même pas des solutions utilisées par la plupart des interfaces web de mail gratuit type Yahoo!, où l'on utilise un simple POST dans lequel le mot de passe est présent en clair!

Pour finir, la méthode htaccess peut très bien être sécurisée car elle en possède les moyens : cryptographie avec MD5 ou sécurisation de bout en bout grace à SSL... A chacun de s'assurer que ces mesures soient correctement utilisées.

Sources de l'article