Mise en évidence de la faille

Supposons que nous disposons d'un serveur Apache local et que nous avons une page index.php très simple comme ceci :

<h1>Bonjour !</h1>

Pour accéder à la page, nous accédons à l'URL http://127.0.0.1/~trance/vuln/ avec un navigateur Web. La requête envoyée est grossièrement la suivante :

GET http://127.0.0.1/~trance/vuln/ HTTP/1.1
Host: 127.0.0.1

La réponse reçue comporte alors le code HTML de la page Web. Jusqu'ici, tout est normal : Apache n'a fait qu'interpréter la requête GET qu'on lui a envoyé. Maintenant, imaginez que nous envoyons une requête mal formée qui n'est pas de type GET, comme :

n1Mp0rTeKwa http://127.0.0.1/~trance/vuln/ HTTP/1.1
Host: 127.0.0.1

Et là, nous constatons qu'Apache ne fait absolument aucune différence entre cette et la requête précédente ! Il n'y a aucune erreur ; il renvoie la même chose. A première vue, cela ne choque pas forcément, mais on s'aperçoit assez vite que l'on peut tirer profit de cette faille pour contourner certaines protections .htaccess.

Contourner le « Limit GET POST »

Dans de nombreux cas, un webmaster peut souhaiter restreindre l'accès à un fichier ou à un dossier sur son site Web. Pour cela, il place des fichiers .htaccess. Ces fichiers modifient localement la configuration d'Apache et utilisent une certaine syntaxe qui permet de faire des choses assez puissantes. La description de cette syntaxe est connue, et beaucoup de sites Web l'illustrent. Certains proposent une solution simple pour protéger l'accès à un fichier par un mot de passe. Il suffit, selon eux, de créer un .htaccess selon ce modèle :

<Files fichierAProteger.php>

AuthUserFile /chemin/vers/.htpasswd
AuthName "Zone à accès restreint"
AuthType Basic
    <Limit GET POST>
    require valid-user
    </Limit>
</Files>

Ce fichier permet d'indiquer à Apache de refuser toute requête POST ou GET si l'utilisateur n'est pas identifié avec un login et un mot de passe apparaissant dans le fichier .htpasswd correspondant. En fait, peu importe qu'il y ait de .htpasswd ; la faille ne se situe pas à ce niveau.

Souvenez-vous de ce que nous avons vu plus haut. Nous avons vu qu'Apache interprétait toutes les requêtes qu'il ne comprenait pas comme des requêtes GET. Ainsi, nous pouvons utiliser cela à notre avantage pour accéder à la page protégée sans s'authentifier !

Exemple : imaginons que nous avons un .htaccess rudimentaire de ce type dans le même dossier :

<Limit GET POST>
Deny from all
</Limit>

Logiquement, ce fichier est censé interdire tout accès aux pages du dossier. Le hic, c'est que seules les requêtes GET ou POST sont concernées... Tentez d'accéder à la page avec le navigateur : vous obtenez une erreur 403, puisque votre navigateur envoie implicitement un GET. Maintenant, envoyez une requête incorrecte avec un outil comme Netcat :

n1Mp0rTeKwa  http://127.0.0.1/~trance/vuln/ HTTP/1.1

Host: 127.0.0.1

Et vous obtiendrez la réponse suivante :

<h1>Bonjour !</h1>

Voila donc comment contourner la protection... Simple, n'est-ce pas ? Le pire, dans tout cela, c'est que la majorité des webmasters protègent leurs sites de cette façon. Et j'en faisais partie, jusqu'à ce qu'on me le signale.

Correction

La correction est ultra-simple : n'utilisez pas l'instruction « limit » quand vous voulez restreindre l'accès à un fichier ou dossier ! Bannissez les lignes « <Limit GET POST> » et « </Limit> » de vos fichiers .htaccess et vous éviterez ce genre de problèmes.

D'ailleurs, la documentation d'Apache précise bien qu'en général, il ne faut pas utiliser <Limit> lorsque l'on cherche à restreindre l'accès. Je cite : « In the general case, access control directives should not be placed within a <Limit> section. »

Limites

Un petit bémol cependant : pour le moment, nous n'avons pas trouvé le moyen de fausser les requêtes POST en injectant des données. Ainsi, si vous avez des formulaires POST protégés par des .htaccess, ils sont à priori sûrs. Mais je vous conseille quand même de patcher vos .htaccess en retirant les lignes « <Limit> » un peu trop dangereuses.