PUT et DELETE : ce que votre serveur accepte sans le dire

Avant d'attaquer une application, un pentesteur pose une question bête à votre serveur : « quels verbes acceptes-tu ? ». Pas quelles pages tu sers, pas quelle techno tu fais tourner. Juste : quels verbes HTTP sont activés. Et trop souvent, la réponse contient PUT et DELETE — c'est-à-dire, traduit en clair, « tu peux écrire des fichiers chez moi, et tu peux en supprimer ».

C'est une des toutes premières vérifications qu'on fait en énumération web, parce qu'elle coûte une seule requête et qu'elle peut, à elle seule, donner le contrôle du serveur. Aujourd'hui je vous montre comment elle se fait, pourquoi le résultat est si souvent mauvais, et comment vous assurer en cinq minutes que votre serveur ne répond pas la mauvaise chose.

Un verbe HTTP, c'est une permission déguisée

Quand votre navigateur charge une page, il envoie une requête GET. Quand vous soumettez un formulaire, c'est souvent un POST. Ces deux-là, tout le monde les connaît. Mais le protocole HTTP en définit d'autres, et chacun correspond à une intention différente.

Le problème saute aux yeux dès qu'on lit la colonne « Effet ». PUT et DELETE ne sont pas des lectures. Ce sont des écritures. Un serveur qui accepte PUT sur un répertoire web accessible, c'est un serveur sur lequel un inconnu peut, potentiellement, déposer un fichier de son choix — y compris un script exécutable. Et un script déposé sur un serveur web, c'est, dans la plupart des cas, le point de départ d'une prise de contrôle complète.

La méthode OPTIONS, elle, n'est pas dangereuse en soi. Mais elle est le cadeau de bienvenue de l'attaquant : c'est le verbe qui sert à demander poliment au serveur la liste de tous les autres verbes qu'il accepte. La reconnaissance commence là.

Comment un attaquant pose la question

L'outil de référence pour cette vérification, c'est Nmap, à travers son moteur de scripts. Le script http-methods fait exactement une chose : il interroge le serveur et liste les verbes HTTP actifs sur une route donnée. La commande tient en une ligne :

nmap -p80 -sV --script http-methods --script-args http-methods.test-all scanme.nmap.org

Décortiquons, parce que chaque morceau a son rôle. -p80 cible le port web. -sV demande la détection de version du service, ce qui révèle au passage le serveur web et sa version. --script http-methods charge le script qui nous intéresse. Et --script-args http-methods.test-all est le détail qui change tout : par défaut, le script se contente de lire la réponse de la méthode OPTIONS — c'est-à-dire qu'il fait confiance au serveur sur ce que celui-ci déclare accepter. Avec test-all, le script va plus loin : il essaie réellement chaque verbe, un par un, pour voir lesquels répondent vraiment. La distinction est capitale, parce qu'un serveur peut très bien « oublier » de mentionner PUT dans sa réponse OPTIONS tout en l'acceptant en pratique.

Sur une cible bien configurée, le résultat ressemble à ceci :

80/tcp open  http    Apache httpd
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS

GET, HEAD, POST, OPTIONS. Que de la lecture et de l'envoi de données vers des routes qui savent les traiter. Aucune écriture de fichier arbitraire. C'est ce qu'on veut voir.

Sur une cible mal configurée, la ligne devient :

|_  Supported Methods: GET HEAD POST OPTIONS PUT DELETE

Et là, le pentesteur s'arrête net, parce qu'il vient peut-être de trouver son chemin vers le serveur.

Vérifier à la main, sans Nmap

Vous n'avez pas besoin d'installer quoi que ce soit pour reproduire l'essentiel de ce test. curl, présent partout, suffit. La première étape, c'est la question polie — OPTIONS :

curl -s -X OPTIONS -i https://votre-domaine.example/  # lit l'en-tête Allow renvoyé

Cherchez dans la réponse un en-tête Allow:. S'il liste PUT, DELETE, PATCH ou TRACE, c'est un premier signal. Mais souvenez-vous de la leçon du test-all : la déclaration n'est pas la réalité. La vraie vérification, c'est d'essayer concrètement d'écrire un fichier — dans un répertoire de test, sur votre propre serveur, jamais sur un système qui ne vous appartient pas :

curl -s -i -X PUT --data "preuve" https://votre-domaine.example/test-put.txt  # tente une écriture

Si la réponse est un 201 Created ou un 200 OK, allez vérifier : le fichier test-put.txt est probablement en ligne, déposé par une requête anonyme. Vous venez de démontrer, sur votre propre infrastructure, qu'un inconnu peut écrire sur votre serveur. Supprimez le fichier de test, et passez à la correction — c'est une urgence, pas une observation.

Pourquoi ça arrive, et ce n'est jamais « par méchanceté »

Personne n'active sciemment PUT en grand sur un serveur de production. Ces configurations dangereuses naissent toujours d'un raccourci qui semblait raisonnable sur le moment.

Le cas le plus fréquent, c'est WebDAV (Web-based Distributed Authoring and Versioning) — l'extension qui fait d'un serveur web un espace de fichiers partagé, et qui s'appuie justement sur PUT et DELETE. Activé un jour pour permettre à une équipe de déposer des documents, puis laissé en place quand l'usage a disparu. Le module reste chargé, les verbes restent actifs, et plus personne ne s'en souvient.

Vient ensuite la confusion entre l'API (Application Programming Interface) et les fichiers statiques. Une API REST (Representational State Transfer) moderne utilise légitimement PUT et DELETE — c'est normal, c'est même propre, parce que derrière ces verbes il y a du code applicatif qui vérifie l'authentification et les droits. Le danger, c'est quand le serveur web autorise PUT et DELETE au niveau du système de fichiers, pas seulement au niveau de l'API. Le verbe censé piloter du code finit par piloter directement le disque.

Enfin, il y a la configuration héritée : un fichier de conf recopié d'un projet à l'autre, un réglage par défaut d'une vieille version, un « on verra plus tard » qui a tenu trois ans. La cause n'est pas technique. C'est qu'aucun verbe n'a jamais été remis en question, parce que tout fonctionnait.

La correction : refermer ce qui n'a pas à être ouvert

Le principe directeur tient en une phrase : un serveur web ne devrait accepter que les verbes dont ses routes ont réellement besoin, et rien de plus. Tout le reste se refuse au niveau du serveur, avant même que la requête n'atteigne votre application.

Sur Nginx, on liste les méthodes autorisées et on rejette les autres :

location / {
    limit_except GET HEAD POST {
        deny all;                 # tout autre verbe : 403, PUT et DELETE inclus
    }
}

Sur Apache, la logique est la même, exprimée différemment, et on prend soin de désactiver WebDAV s'il traîne :

<Location />
    <LimitExcept GET HEAD POST>
        Require all denied
    </LimitExcept>
</Location>
Dav Off    # coupe WebDAV, donc PUT et DELETE au niveau fichiers

Trois précautions accompagnent ce réglage. D'abord, désactivez explicitement WebDAV partout où il n'est pas indispensable — c'est la source numéro un de PUT ouvert. Ensuite, si vous avez une vraie API REST qui a besoin de PUT et DELETE, restreignez ces verbes au préfixe de l'API (par exemple /api/) et laissez le reste du serveur en lecture seule : le code applicatif qui se trouve derrière /api/ reste, lui, responsable de vérifier qui a le droit de faire quoi. Enfin, pensez à TRACE : ce verbe de débogage, rarement utile, a son histoire de fuites d'informations, et se désactive de la même manière. C'est exactement le genre de durcissement systématique qu'on industrialise dans un pipeline DevSecOps — un sujet central du Bootcamp DevSecOps.

Les limites : ne pas confondre « refermé » et « sécurisé »

Soyons honnêtes sur la portée de cette correction. Bloquer PUT et DELETE au niveau du serveur ferme une porte béante, et c'est une vraie victoire. Mais ce n'est pas une stratégie de sécurité à soi seule, pour deux raisons.

D'abord, un attaquant peut écrire des fichiers par d'autres chemins qu'un PUT direct : un formulaire d'upload mal validé, une faille d'inclusion de fichier, une désérialisation non sûre qui exécute du code arbitraire. Refermer PUT ne traite que ce vecteur-là. Le déni d'écriture arbitraire doit être défendu en profondeur, pas à un seul endroit.

Ensuite, le test http-methods ne dit rien de la qualité de votre autorisation applicative. Un serveur qui n'accepte que GET et POST peut parfaitement souffrir d'une IDOR (Insecure Direct Object Reference), d'une injection ou d'un contrôle d'accès cassé sur ses routes légitimes. Les verbes dangereux sont un symptôme visible et grossier ; leur absence ne garantit pas la santé du reste.

La bonne manière de voir les choses : la vérification des méthodes HTTP est un test d'hygiène, au même titre que vérifier qu'on n'a pas laissé un .git ou un .env accessible. Ça ne prouve pas que vous êtes en sécurité. Mais en échouer un, c'est laisser ouverte une porte qu'aucun attaquant ne se prive d'essayer, parce qu'elle ne coûte qu'une requête à tester. C'est précisément ce type de réflexes d'audit qu'on muscle dans la formation OWASP Web Security.

Ce qu'il faut retenir

Faites le test aujourd'hui, sur vos propres serveurs. Une commande Nmap, ou deux requêtes curl, et vous saurez exactement ce que votre serveur répond à un inconnu qui lui demande s'il accepte d'être modifié. Si la réponse contient PUT ou DELETE hors d'une API qui les gère consciemment, vous avez une correction à faire avant ce soir.

Parce que la vraie question n'est pas « est-ce que mon site est en ligne ? ». C'est « qu'est-ce que mon serveur accepte de faire pour quelqu'un que je n'ai jamais autorisé ? » — et il répond honnêtement à qui prend la peine de le lui demander.