HTTP Method Tampering

Pourquoi c'est important

Les contrôles d'accès ne gardent souvent que les portes que les développeurs s'attendent à voir emprunter par les attaquants. Un mur de connexion placé devant GET et POST peut laisser HEAD, OPTIONS, PUT et TRACE grands ouverts, et un attaquant qui change simplement le verbe entre directement. Comme le contrôle a toujours l'air correct dans un navigateur normal, où chaque requête est un GET ou un POST, cette faille peut survivre en production pendant des années.

Le HTTP method tampering est une forme d'école de contrôle d'accès défaillant, le risque numéro un du Top 10 de l'OWASP, et il est trivial à tester une fois que vous interceptez une requête avec un proxy comme Burp Suite.

Comment ça fonctionne

Un chemin d'administration protégé renvoie 401 dans le navigateur. Le testeur capture la requête et la rejoue avec différentes méthodes, sans rien changer d'autre :

GET     /admin   ->  401 Unauthorized
POST    /admin   ->  401 Unauthorized
HEAD    /admin   ->  200 OK
OPTIONS /admin   ->  200 OK

Le 200 sur HEAD signifie que le serveur a traité la requête comme valide. La mauvaise configuration sous-jacente ressemble généralement à un bloc Apache qui ne liste que deux méthodes :

<Limit GET POST>
  require valid-user
</Limit>

Tout ce qui n'est pas nommé, HEAD, OPTIONS, TRACE et PUT, contourne entièrement la vérification d'authentification. Une variante connexe abuse de frameworks qui routent une méthode inattendue vers le même gestionnaire mais appliquent un chemin d'autorisation différent et plus faible.

Pourquoi elle persiste

Le bug survit parce que les développeurs raisonnent sur les deux méthodes qu'un navigateur utilise réellement et oublient le reste de la spécification HTTP. La liste blanche donne un sentiment de sécurité, mais toute méthode absente de la liste n'hérite d'aucune protection. Les répartiteurs de charge, les anciennes règles mod_auth et les extraits de configuration copiés propagent le même schéma à travers de nombreuses applications.

Comment la tester

Pour chaque point de terminaison protégé, rejouez la requête avec l'ensemble complet des méthodes : GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH et TRACE. Guettez toute méthode qui renvoie un 200 ou un corps différent, et comparez soigneusement les codes de statut, car un 405 est sain tandis qu'un 200 sur un verbe inattendu est une trouvaille. Des méthodes arbitraires ou inventées révèlent parfois une gestion encore plus laxiste.

Prévention

Imposez l'autorisation sur toutes les méthodes par défaut et n'autorisez que les verbes dont un point de terminaison a réellement besoin. Remplacez les blocs de configuration spécifiques à une méthode par une politique de refus par défaut, renvoyez 405 pour les méthodes non prises en charge, désactivez TRACE, et testez chaque point de terminaison restreint avec l'ensemble complet des méthodes pour vérifier que le contrôle ne peut pas être contourné.