Bonjour,
Une manière d'interdire l'accès à certaines parties d'un site est d'utiliser un .htaccess. Ce fichier réglemente l'accès en demandant le plus souvent un identifient et un mot de passe. A première vue, sans connaitre les identifiants, il n'est pas facile de passer cette protection. Cependant, beaucoup d'administrateur copient/collent des .htaccess trouvés sur Internet et oublient de les vérifier, ainsi ils laissent très souvent la ligne suivante dedans :
<LIMIT GET POST>
Require valid-user
</LIMIT>
Cette ligne signifie que sur la partie protégée par le fichier, les requêtes GET et POST ne sont pas autorisées.
Ainsi, si avec telnet nous lançons la commande suivante :
> GET http://www.site.com/admin/admin.php HTTP/1.0
Le serveur nous retournera la réponse suivante :
HTTP/1.1 401 Authorization Required
Date: Fri, 24 Jun 2011 18:33:29 GMT
Server: Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.8e-
auth_passthrough/2.1
WWW-Authenticate: Basic realm="Veuillez vous identifier"
Content-Length: 711
Connection: close
Content-Type: text/html; charset=iso-8859-1
On voit bien ici que l'accès nous est refusé.
Toutefois, la restriction ne s'applique qu'aux requêtes GET et POST. Essayons avec une requête différente toujours sur telnet :
> telnet http://www.site.com 80
> OPTIONS http://www.site.com/admin/admin.php HTTP/1.0
Si nous obtenons la réponse suivante :
HTTP/1.1 202 OK
Date: Fri, 24 Jun 2011 18:33:29 GMT
Server: Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.8e
Content-Length: 711
Connection: close
Content-Type: text/html; charset=iso-8859-1
Nous avons réussi ! Le contenu de la page protégée est listé. Pourquoi ? Parce que la requête OPTIONS n'est pas concerné par la restriction de requête et donc Apache l'interprète comme une requête valide.
Si toutefois l'erreur 401 persiste ; inutile de continuer