Société de Sécurité Informatique - Audit Firewall Appliance
La sécurité informatique - La sécurité des informations

La méthode d'authentification htaccess


Envoyer cet article par Email !Imprimer cet article !Exporter cet article en PDF !FacebookTwitterGoogle Bookmarks

Concept d'authentification


Ce système d'authentification est fréquemment utilisé pour restreindre l'accès au contenu de répertoires spécifiques, sur un intranet ou sur Internet. Le fichier contenant les informations de configuration relatives aux personnes ou groupes de personnes habilitées à accéder les données protégées, ainsi que leurs droits, se nomme ".htaccess" par défaut. Il est stocké dans le même répertoire où résident les données à portéger.


Fonctionnement


La méthode d'authentification htaccess a été développée en même temps que les programmes destinés à récupérer des données "Web" sur Internet, tel que les démons HTTPd. Ainsi, dans une url (Universal Resource Locator), la commande "http://" va être interprétée par le démon (il s'agit du programme sur le serveur Web attendant toute connexion ou requête pour la traiter); celui-ci dispose d'un fichier global de gestion des accès stocké à la racine le plus souvent. Les fichiers .htaccess représentent des niveaux additionnels dans la gestion des accès, et apportent un raffinement lié à chaque répertoire.

Ainsi, si le démon trouve un fichier .htaccess dans l'arborescence à parcourir pour accéder au fichier requis par le client, il va procéder suivant les informations contenues dans ce fichier : il va soit interdire l'accès et refuser la requête, soit demander une authentification de l'utilisateur via login/password. Il est intéressant de noter que la plupart du temps les données d'authentification (à l'inverse des données de configuration) sont stockées à un autre endroit dans l'arborescence, protégées de tout accès via le Web (par exemple avec un fichier .htaccess où est spécifié "Deny from All"). Le démon va comparer ces données avec celles renvoyées par l'utilisateur lors de la requête d'authentification et autoriser, suivant le résultat du test, l'utilisateur à accéder ou non à la page web.


Aspects pratiques : le fichier .htaccess


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 :
<Limit GET>
require user roswell mulder
</Limit>
Plus généralement, nous aurons :
<Limit GET>
require valid-user
</Limit>
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 :
<Files index.html>
require valid-user
</Files>
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.
Exemple :

Order Allow,Deny
Allow from apache.org
Deny from foo.apache.org

Tout le monde provenant du domaine apache.org est autorisé à accéder au serveur web sauf une souspartie qui est refusée (sous-domaine foo). Le reste du monde est refusé puisqu'il s'agit du défautdans ce cas.
Variantes : pour autoriser seulement un groupe d'adresses IP : ici celles contenues dans la classe B 129.21 .
Order Deny,Allow
Allow from 129.21
Deny from All
Pour autoriser seulement un groupe d'hôtes ou réseaux : ici le domaine rit.edu .
Order Deny,Allow
Allow from rit.edu
Deny from All
Pour exclure seulement un groupe d'adresses IP : ici celles contenues dans 129.21.3 .
Order Allow,Deny
Allow from All
Deny from 129.21.3
Pour exclure seulement un groupe d'hôtes ou réseaux : ici le domaine isc.rit.edu .
Order Allow,Deny
Allow from All
Deny from isc.rit.edu

- 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 :


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 :


GET http://www.securiteinfo.com/restricted_zone/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Accept-Language: fr
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Host: www.securiteinfo.com
Proxy-Connection: Keep-Alive


HTTP/1.1 401 Authorization Required
Via: 1.1 PROXY2
Connection: close
Content-type: text/html; charset=iso-8859-1
Date: Wed, 22 Aug 2001 15:25:40 GMT
Server: Apache/1.3.12 (Unix) Debian/GNU mod_perl/1.24
Www-authenticate: Basic realm="Acces Restreint"


GET http://www.securiteinfo.com/restricted_zone/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Accept-Language: fr
Authorization: Basic QWxpY2U6TGFwaW4=
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Host: www.securiteinfo.com
Proxy-Connection: Keep-Alive


HTTP/1.1 200 OK
Via: 1.1 PROXY2
Connection: close
Content-type: text/html
Date: Wed, 22 Aug 2001 15:25:45 GMT
Server: Apache/1.3.12 (Unix) Debian/GNU mod_perl/1.24



Explications :


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).


HTTP/1.1 401 Unauthorized
(...)
WWW-Authenticate: Digestrealm="testHash",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"


Authorization header:Authorization: Digest
username="Alice",
realm="testHash",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
response="e966c932a9242554e42c8ee200cec7f6",
opaque="5ccc069c403ebaf9f0171e9517f40e41"


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 :

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

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)
- ...


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.

SoGoodToBe

Ils nous font confiance
© 2014 - Tous droits réservés - SecuriteInfo.com