Désécuriser des pages sous Apache

Ne vous méprenez pas sur le but de cet article. Le but n’est pas de casser le serveur web Apache mais plutôt de jouer avec ses options de configuration. Le but est de vous montrer comment améliorer la gestion de la sécurité d’accès a ses pages.

Les préliminaires

Le nombre de sites web qui expliquent comment configurer apache par un .htaccess pour interdire l’accès non autorisé à des pages d’un site ne manquent pas. Cependant comme c’est un pré-requis pour aller plus loin je vais faire un rapide résumé.

On peut, dans Apache, modifier l’accès à des pages. Ceci se fait au niveau du fichier de configuration du serveur. On peut cependant autorisé les utilisateurs à reparamétrer à la volée l’accès à certain répertoires en utilisant des fichiers spéciaux (généralement nommé .htaccess mais c’est paramétrable). A noter aussi qu’un FAI peut interdire l’utilisation des .htaccess pour améliorer les performances de son serveur web (qui n’a plus à vérifier l’existance de ces fichiers à chaque nouvel accès à un répertoire).

Pour sécuriser l’accès à un répertoire on utilise généralement un fichier de login / mot de passe stockés dans un répertoire non visible depuis le web (soit en dehors de l’arborescence du serveur – ce qui est le plus sécurisé – soit dans un dossier lui-même protégé par une interdiction totale d’accès en HTTP). On peut également utiliser la notion de groupes qui permet de limiter l’accès à un ou plusieurs groupes.

Ensuite il suffit d’écrire un petit .htaccess qui pourrait resembler à ceci, en partant du plus contraignant :

AuthUserFile /auth/.htpasswd
AuthName "Secure Access"
AuthType Basic require user toto 

AuthUserFile /auth/.htpasswd
AuthGroupFile /auth/.htgroups
AuthName "Secure Access"
AuthType Basic require group admin 

AuthUserFile /auth/.htpasswd
AuthName "Secure Access"
AuthType Basic require valid-user 

Dans le premier exemple seul l’utilisateur toto peut accéder aux pages. Dans le deuxième exemple tout membre du groupe admin peut accéder aux pages. Enfin dans le troisième tout utilisateur déclaré dans le fichier .htpasswd peut accéder aux pages. Bien entendu ceci suppose d’avoir connaissance du mot de passe !

Les fichier .htpasswd et .htgroups peuvent resembler à ceci :

# Fichier .htpasswd
toto:CryptedPassword
tutu:OtherCryptedPass
titi:SecurePass!

# Fichier .htgroups
admin: titi toto
test: tutu titi 

L’avantage des groupes c’est que quand vous ajoutez un utilisateur à votre système, si vous avez plusieurs zones logiques, il suffit d’ajouter l’utilisateur aux différents groupes auxquels il a droit et hop tout le site est bon. Sans cela il faut aller éditer tous les fichier .htaccess (ou modifier le fichier de config du serveur) pour ajouter / enlever l’utilisateur avec toujours le risque d’en oublier un quelque part. Bref d’un point de vue maintenance cela permet de tout centraliser… bien entendu si votre fichier central est mal protégé le château de cartes s’écroule !

Hey, c’est récursif cette protection !

Une fois un répertoire sécurisé, tous ses sous-répertoires se voient appliquer les même restrictions. C’est dans 99,999% des cas une bonne chose mais il peut arriver qu’on désire modifier voire supprimer la sécurité d’un répertoire. Pourquoi ? Parce-que ! Bon disons que par exemple vous sécurisez une zone de votre site web en l’appelant extranet. Dedans vous mettez les outils qui sont accessibles à votre collaborateurs et vous spécifiez que cette zone est cryptée SSL. Et puis vous vous dites tient je vais mettre tel outil que j’ai trouvé qui a l’air sympa (IMP pour lire son mail ?)… et comme de juste cet outil propose sa propre authentification. Donc pour éviter le double login vous devez supprimer l’une ou l’autre des protection d’accès. Généralement pour le logiciel c’est pas évident… donc il faut supprimer la protection apache. Oui mais comment ?

Une tentative pour mettre un .htaccess vide ne fonctionne pas. Zut, bien essayé. Mais alors comment lui faire comprendre à l’animal ? En fait il suffit de ruser un peu. Il existe une directive permettant de restreindre les adresses IP qui peuvent se connecter au répertoire. Ainsi on peut sécuriser une zone en n’autorisant que les adresses IP du réseau interne. C’est pas 100% sûr (on peut usurper une adresse IP) mais c’est déjà un bon début. On peut aussi dire j’autorise/interdit n’importe quelle adresse IP.

Voici par exemple un fichier qui interdit tout acces à un répertoire et ce quelle que soit l’adresse utilisée. Un tel fichier est souvent placé pour interdire à un client web de lire le contenu du répertoire qui peut contenir, au hasard, un fichier .htpasswd

Deny from all 

On peut donc se dire que si on utilise la directive Allow from all celle-ci va remplacer la sécurité du répertoire… un rapide essai vous prouvera le contraire. En fait les directives se complètent. On pourrait en effet expliquer au serveur web qu’il faut que l’utilisateur soit valide ET qu’il se connecte depuis une adresse IP valide.

Heureusement il y a une solution. En fouillant un peu dans la documentation Apache on trouve la directive magique Satisfy. Celle-ci permet de modifier le mode de sécurisation par défaut (un ET de toutes les directives) pour, par exemple, dire qu’une seule directive suffit. Exemple :

AuthUserFile /auth/.htpasswd
AuthName "Secure Access"

AuthType Basic
require valid-user

Order allow,deny
Allow from all

Satisfy any 

J’ai remis la directive de protection par utilisateur mais en réalité elle ne sera jamais utilisée puisque dans cet exemple j’ai mis un "Allow from all". La directive Order permet de dire qu’on commence par autoriser l’accès puis ensuite on applique les restrictions. Je ne pense pas que dans ce cas préci cela change quelque chose mais je n’ai pas vérifié !

Autre exemple d’utilisation de la directive satisfy. Revenons à notre exemple d’extranet. Disons que depuis internet nous trouvions normal que les utilisateurs saisissent un login et un mot de passe (à noter que cela pourrait tout aussi bien être "présenter un certificat SSL… mais là n’est pas notre propos). Cependant en interne on peut décider d’autoriser toutes les machines à se connecter sans mot de passe.

Première mauvaise idée utiliser le nom de domaine pour le allow. Il ne faut surtout pas dire Allow from .mondomaine.com car il est plus facile d’usurper un nom qu’une adresse IP (du moins je pense, je ne suis pas expert en sécurité !). Il faut donc donner le domaine d’adresse IP autorisées (adresses qui si c’est bien fait ne seront pas routables sur internet).

Pour en savoir plus sur ce domaine je vous invite à lire en détail la documentation du serveur Apache. On trouve toujours plein de choses amusantes. A noter que tout ceci est valable pour une version 1.3 du serveur. Je n’ai pas expérimenté sur une version 2.x donc si ça ne fonctionne pas merci de m’envoyer un petit message !