OVH Community, votre nouvel espace communautaire.

La protection .htacces / .htpasswd


code_grabber
13/09/2011, 11h26
Citation Envoyé par creadiff
@toshop : Exactement !

Et voilà pour générer un fichier .htpasswd...
après un bon vieux déterrage de 4 ans, tu aurais au moins pu affiner la chose, car là je vois pas l'intérêt de ton post...
tu aurais pu par exemple lui dire qu'il pouvait concaténer ses deny en un seul histoire de pas écrire 50 lignes de deny à la suite...

enfin bon, on se revoit dans 4 ans

lefkeo
13/07/2011, 23h32
Pour crypter un mot de passe pour htpasswd il y a également la page Ovh : http://www.ovh.com/fr/support/outils/crypt_password.pl

creadiff
19/04/2011, 13h11
@toshop : Exactement !

Et voilà pour générer un fichier .htpasswd...

toshop
26/02/2007, 13h44
Bonjour Visualight,

Dans un fichier .htaccess pour bannir une IP, cela donne :
Deny from 'première IP'

Pour ajouter d'autres IP il faut procéder comme ceci ?
Deny from première IP;
Deny from seconde IP;
etc

Amicalement,
Toshop

visualight
15/12/2006, 18h41
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.

visualight
15/12/2006, 18h40
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 , 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 :

* 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 "loginassword" 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.

HTTP/1.1 401 Unauthorized
(...)
WWW-Authenticate: Digest realm="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 :

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

visualight
15/12/2006, 18h33
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 réseau 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 à proté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 :

Code:
    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 à quelque chose 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 :

Code:
    
    require user roswell mulder
    
Plus généralement, nous aurons :
Code:
    
    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 :

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

Exemple :

Code:
    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 sous partie qui est refusée (sous-domaine foo). Le reste du monde est refusé puisqu'il s'agit du défaut dans ce cas.

Variantes : pour autoriser seulement un groupe d'adresses IP : ici celles contenues dans la classe B 129.21 .

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

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

Code:
    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 .
Code:
    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é.
Code:
    AuthDCE On
    AuthType Basic
    AuthName dce
    require valid-user