Toujours lors de nos audits de sécurité, une faille qui revient très régulièrement est la mauvaise configuration d’une protection par le biais d’un htaccess. La plupart des administrateurs ou webmasters fouinent sur le net afin de créer leur .htaccess, et de fait, se retrouvent avec des choses dont ils n’ont pas réellement besoin, ou en tout cas qu’ils n’ont pas tout à fait compris. Bon, je pense que mon teasing a fait son petit effet, y’a plus qu’à cliquer sur le lien suivant pour lire la suite.

Bon j’avoue, j’ai un peu triché, derrière ce titre racoleur se trouve une erreur de configuration assez grossière, mais que l’on retrouve, sans exagérer dans 70% des cas. Le premier responsable de cette faille est, il me semble, le site http://www.commentcamarche.net/. Pourquoi ca ? Simplement parce qu’ils sortent premier sur la recherche « Création htaccess« .

Et comment nous proposent-ils de créer un htaccess ?
Je cite:

ErrorDocument 403 http://www.commentcamarche.net/accesrefuse.php3
AuthUserFile /repertoire/de/votre/fichier/.FichierDeMotDePasse
AuthGroupFile /dev/null
AuthName "Accès sécurisé au site CCM"
AuthType Basic
<LIMIT GET POST>
Require valid-user
</LIMIT>

Donc si l’on fait un tour rapide:

• La première ligne donne la page où l’on doit rediriger lors d’une 403 (Erreur d’auth ou deny from all par exemple)
• La seconde donne le chemin du fichier contenant les mots de passe
• La troisième le chemin du fichier de groupe
• La quatrième, c’est le wording du prompt login / pass
• La cinquième donne le mode d’authentification, dans ce cas auth basic (mod_auth_basic)
• Enfin, les trois dernières expliquent que pour exécuter les requêtes GET et POST, il faut être un utilisateur authentifié.

Tout cela est assez schématisé, mais l’idée est là. Donc si je tente d’accéder à la page protégée, j’effectuerais une requête de type:

GET http://www.example.com/admin/index.php HTTP/1.0

Et je vais donc atterir sur une 401 Authorization Required. Où se situe l’astuce ? Apache ne gère pas correctement les requêtes mal formée. Je m’explique, si à la place de faire un GET ou un POST, je fais un:

JOHN http://www.example.com/admin/index.php HTTP/1.0

Apache me renverra le contenu de la page présente derrière /admin/index.php (200). Lorsque je dis que 70% des sites sont faillibles, c’est tellement il est facile pour un webmaster paresseux de réaliser cette configuration. htaccess permet de modifier localement la configuration d’apache, du coup chaque webmaster peut créer sa propre faille en suivant les conseils d’un site généraliste comme commentcamarche. Deux coupables: le webmaster car il dépose une config qu’il ne comprend pas et Apache car il interprète les requêtes mal formée comme étant des GET. Grosso-modo, il est possible pour le premier venu d’aller se balader sur les backoffices en forgeant simplement sa requête à base de JOHN.

Comment patchons nous cette faille ?
Tout simplement en ôtant de notre htaccess la limit GET, POST. En effet, aucun intérêt de limiter à GET et POST le require valid-user si ce dernier est effectivement nécessaire. D’ailleurs dans les préconisations globales d’apache, ils recommandent de ne pas utiliser les limit lors de la création de htaccess. Je cite:

Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control directives should not be placed within a <Limit> section.

The purpose of the <Limit> directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the <Limit> bracket will have no effect. The following example applies the access control only to the methods POST, PUT, and DELETE, leaving all other methods unprotected.