Tweet
Cet article explique comment contourner une protection Web très répandue basée sur les fichiers .htacess d'Apache.
Alors que les .htaccess, s'ils sont bien conçus, constituent une bonne sécurité, nous allons voir qu'il suffit d'un tout petit défaut pour rendre la protection totalement inefficace.
Ici, il s'agit de la balise Limit combinée avec l'existence d'une petite faille au niveau d'Apache...
Sommaire
Mise en évidence de la faille
Contourner le "Limit GET POST"
Correction
Limites
1. 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 requête 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.
2. 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
3. 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 "" et "" 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 lorsque l'on cherche à restreindre l'accès. Je cite : "In the general case, access control directives should not be placed within a section."
4. 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...
D'autre part, je suis loin d'être un expert en configuration Apache. Il est possible qu'il existe une option demandant à Apache de refuser systématiquement toutes les requêtes qui ne sont pas comprises. Si vous la connaissez, vous pouvez laissez un commentaire, cela m'intéresse... Je n'ai également pas testé avec d'autres serveurs Web comme IIS, mais à priori je pense qu'ils ne sont pas vulnérables.
credit: Trance
Alors que les .htaccess, s'ils sont bien conçus, constituent une bonne sécurité, nous allons voir qu'il suffit d'un tout petit défaut pour rendre la protection totalement inefficace.
Ici, il s'agit de la balise Limit combinée avec l'existence d'une petite faille au niveau d'Apache...
Sommaire
Mise en évidence de la faille
Contourner le "Limit GET POST"
Correction
Limites
1. 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 requête 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.
2. 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
3. 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 "" et "" 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 lorsque l'on cherche à restreindre l'accès. Je cite : "In the general case, access control directives should not be placed within a section."
4. 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...
D'autre part, je suis loin d'être un expert en configuration Apache. Il est possible qu'il existe une option demandant à Apache de refuser systématiquement toutes les requêtes qui ne sont pas comprises. Si vous la connaissez, vous pouvez laissez un commentaire, cela m'intéresse... Je n'ai également pas testé avec d'autres serveurs Web comme IIS, mais à priori je pense qu'ils ne sont pas vulnérables.
credit: Trance