Chemins d'administration par défaut et contournement par verbe HTTP

Beaucoup de serveurs web et de frameworks exposent une interface d’administration sur un chemin prévisible, sans configuration personnalisée. Trouver ce chemin est souvent la première étape. La seconde est d’observer comment le serveur réagit selon le verbe HTTP utilisé — certaines configurations ne protègent que GET ou POST, laissant d’autres verbes sans contrôle d’accès.

Trouver les chemins d’administration

Les chemins à tester en priorité selon la technologie détectée :

# Génériques
/admin
/administrator
/admin.php
/admin/login
/admin/dashboard
/panel
/backoffice
/manage
/management
/console
/cp                  # control panel

# PHP
/phpmyadmin
/pma

# Java / Tomcat
/manager
/manager/html
/host-manager

# Node.js / Express
/admin
/api/admin

# WordPress
/wp-admin
/wp-login.php

# Drupal
/admin
/user/login

# Jenkins
/jenkins

# Spring Boot Actuator
/actuator
/actuator/env
/actuator/beans

Un outil comme feroxbuster ou gobuster automatise cette énumération :

feroxbuster -u https://exemple.com -w /usr/share/wordlists/dirb/common.txt
gobuster dir -u https://exemple.com -w /usr/share/wordlists/dirb/common.txt

Identifier l’authentification Basic

Quand une page d’administration retourne un code 401 Unauthorized, le serveur indique dans les en-têtes de réponse le mécanisme d’authentification attendu :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Administration"

L’authentification HTTP Basic encode les credentials en base64 dans l’en-tête Authorization de la requête :

Authorization: Basic dXNlcjpwYXNzd29yZA==

Décoder la valeur base64 pour lire les credentials transmis :

echo "dXNlcjpwYXNzd29yZA==" | base64 -d
# → user:password

En interceptant la requête dans Burp Suite avec des identifiants aléatoires, l’en-tête Authorization apparaît en clair dans le panneau Proxy. La valeur base64 se décode immédiatement — ce n’est pas du chiffrement.

Le verb tampering

Un serveur peut protéger un endpoint uniquement pour certains verbes HTTP et laisser les autres sans contrôle d’accès. C’est une erreur de configuration fréquente dans les frameworks qui définissent des règles d’autorisation par verbe.

Verbes HTTP disponibles

GET       Lecture d'une ressource
POST      Création ou soumission
PUT       Remplacement complet d'une ressource
PATCH     Modification partielle
DELETE    Suppression
HEAD      Comme GET mais sans corps de réponse
OPTIONS   Liste des verbes acceptés par le serveur
TRACE     Écho de la requête (diagnostic)

Tester les verbes avec Burp Repeater

1. Intercepter la requête vers /admin dans Burp Proxy
2. L’envoyer dans Repeater (Ctrl+R)
3. Modifier le verbe HTTP dans le panneau de requête
4. Rejouer et observer la réponse

# Requête initiale bloquée
GET /admin HTTP/1.1
Host: exemple.com
→ 401 Unauthorized

# Même ressource, verbe différent
POST /admin HTTP/1.1
Host: exemple.com
→ 200 OK

# Ou avec HEAD pour vérifier l'existence sans corps de réponse
HEAD /admin HTTP/1.1
Host: exemple.com
→ 200 OK

Tester avec curl

# GET standard
curl -i -X GET https://exemple.com/admin

# Tester POST
curl -i -X POST https://exemple.com/admin

# Tester d'autres verbes
curl -i -X PUT https://exemple.com/admin
curl -i -X PATCH https://exemple.com/admin
curl -i -X HEAD https://exemple.com/admin

# Découvrir les verbes acceptés
curl -i -X OPTIONS https://exemple.com/admin
# Allow: GET, POST, HEAD, OPTIONS

Exemple de configuration vulnérable

En Java avec Spring Security, une configuration qui ne couvre pas tous les verbes :

// Configuration vulnérable
http.authorizeRequests()
    .antMatchers(HttpMethod.GET, "/admin/**").authenticated()
    .antMatchers(HttpMethod.POST, "/admin/**").authenticated();
    // PUT, DELETE, HEAD non couverts → accessibles sans auth

En Apache avec .htaccess :

# Vulnérable : seul GET est protégé
<Limit GET>
    Require valid-user
</Limit>

Ce qu’on peut faire une fois l’accès obtenu

Selon ce que le verbe non protégé permet d’atteindre :

• HEAD / OPTIONS : confirmer l’existence d’une ressource, découvrir les verbes acceptés
• GET sans auth : lire le contenu de la page d’administration
• POST sans auth : soumettre des formulaires, créer des ressources
• PUT / PATCH : modifier des ressources existantes
• DELETE : supprimer des entrées

Remédiation

Couvrir tous les verbes dans les règles d’autorisation

// Spring Security — couvrir tous les verbes
http.authorizeRequests()
    .antMatchers("/admin/**").authenticated();
// Sans restriction par HttpMethod : s'applique à tous les verbes

# Apache — utiliser LimitExcept pour couvrir tout ce qui n'est pas explicitement autorisé
<LimitExcept GET POST>
    Require all denied
</LimitExcept>

Désactiver les verbes inutiles au niveau serveur

# Nginx — autoriser uniquement GET et POST
if ($request_method !~ ^(GET|POST)$) {
    return 405;
}

Remplacer l’authentification Basic par un mécanisme robuste

L’authentification HTTP Basic transmet les credentials encodés en base64 à chaque requête. Base64 n’est pas du chiffrement — la valeur est lisible immédiatement après décodage. En l’absence de TLS, les credentials transitent en clair sur le réseau.

Préférer :

• Des sessions authentifiées avec tokens signés (JWT, sessions serveur)
• De l’OAuth 2.0 pour les interfaces d’administration exposées
• Un VPN ou un accès réseau restreint pour les interfaces internes

À retenir

Tester les chemins par défaut ne prend pas longtemps et donne des résultats sur des cibles peu configurées. Quand une authentification est trouvée, tester systématiquement les autres verbes HTTP : la protection est souvent partielle et laisse des verbes sans contrôle d’accès.