En bref : filtrer les requêtes d'upload en bordure signifie rejeter, au proxy, au serveur web ou dans le WAF, les requêtes POST de type multipart/form-data qui ne vont pas vers une voie d'upload connue. Des auteurs spécialisés proposent cela comme mesure temporaire et non officielle contre PHP2Shell. Elle peut casser des formulaires et des uploads et ne remplace jamais la mise à jour. Procédez en trois étapes : journaliser, définir les exceptions, bloquer seulement ensuite, avec une date de fin fixe.
Une proposition issue de la discussion spécialisée
Tant qu'un serveur n'est pas corrigé, les exploitants cherchent tout ce qui réduit le risque. Dans la discussion spécialisée sur PHP2Shell est apparue une proposition : n'autoriser les requêtes POST au format multipart/form-data, donc le format des uploads de fichiers et de certains formulaires, qu'aux endroits où l'application les attend réellement. Toutes les autres sont rejetées au proxy ou dans le pare-feu applicatif web.
La mise en perspective est importante. La proposition ne vient pas de php.net, mais d'auteurs spécialisés, et elle est expressément conçue comme mesure temporaire. php.net cite ses propres mesures transitoires, rassemblées dans Mesures immédiates si vous ne pouvez pas encore appliquer le correctif. Le filtre peut les compléter, pas les remplacer.
Nous décrivons ici comment l'introduire de façon contrôlée. Nous laissons volontairement de côté les détails sur les raisons pour lesquelles il pourrait aider contre telles ou telles attaques.
Ce que fait le filtre et où il nuit
L'idée sous-jacente est une réduction de la surface d'attaque. La plupart des pages d'un site n'ont pas besoin d'uploads de fichiers. Si seuls quelques chemins connus acceptent encore de telles requêtes, une grande partie des tentatives d'attaque possibles n'atteint plus du tout PHP.
Le revers est tout aussi clair. Toute fonction qui envoie des requêtes multipart et ne figure pas sur la liste d'exceptions tombe. Cela ne concerne pas seulement les formulaires d'upload évidents.
| Fonction | Utilise souvent multipart/form-data | Risque en cas de blocage |
|---|---|---|
| Formulaires de contact et de candidature avec pièce jointe | oui | des demandes sont perdues |
| Gestion des médias dans le back-office du CMS | oui | la rédaction ne peut plus téléverser d'images |
| Import de produits ou de clients | oui | les interfaces cassent silencieusement |
| Formulaires sans pièce jointe | parfois | selon le générateur de formulaires |
| Interfaces et retours de services externes | rarement, mais possible | la panne se remarque tard |
S'y ajoute un problème de principe : Cloudflare, qui a lui-même déployé des règles de protection contre PHP2Shell, avertit que des règles fondées sur les seules données de la requête ne suffisent pas. La manière de penser les deux niveaux ensemble est décrite dans WAF ou mise à jour : pourquoi il faut les deux.
Étape 1 : d'abord journaliser, puis bloquer
Avant de bloquer quoi que ce soit, déterminez quels chemins reçoivent réellement des requêtes multipart. Les journaux standard n'indiquent pas le type de contenu. Pour Nginx, créez donc temporairement un journal dédié :
# dans le bloc http
map $uri $upload_pfad {
default 0;
~^/kontakt/upload\.php$ 1;
~^/admin/medien/ 1;
}
map "$request_method:$upload_pfad:$content_type" $multipart_fremd {
default 0;
"~*^POST:0:multipart/form-data" 1;
}
log_format multipart '$time_iso8601 $remote_addr "$request" "$content_type" $status';
# dans le bloc server
# Attention : un access_log dans le bloc server remplace le journal hérité,
# il faut donc indiquer ici à nouveau le journal normal.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;
Les entrées de $upload_pfad sont des exemples. Commencez avec une liste d'exceptions vide, le journal de test montrera alors tous les POST multipart. Sous Apache, la même chose est possible avec une variable d'environnement :
# dans le VirtualHost
SetEnvIfNoCase Content-Type "^multipart/form-data" ist_multipart
CustomLog ${APACHE_LOG_DIR}/multipart-test.log combined env=ist_multipart
Laissez le journal tourner quelques jours, idéalement sur une période pendant laquelle la rédaction, les candidats et les interfaces ont aussi été actifs.
Étape 2 : définir les exceptions et bloquer de façon contrôlée
À partir du journal de test, déduisez les chemins qui ont légitimement besoin d'uploads. Rapprochez la liste des responsables : qui gère les contenus, quels formulaires existent, quels services envoient des données ?
- Établir la liste d'exceptions à partir du journal et des questions posées, et l'inscrire dans
$upload_pfadou dans les lignesRewriteCond. - Activer le filtre d'abord sur un environnement de test ou dans une fenêtre horaire calme.
- Tester soi-même tous les formulaires, uploads et parcours de commande.
- Surveiller dans le journal d'erreurs les requêtes rejetées (statut 403) et compléter la liste si nécessaire.
- Fixer une date de fin : après la mise à jour de PHP et le redémarrage de tous les workers, le filtre est retiré.
Dans Nginx, vous ajoutez pour cela le blocage dans le bloc server :
# dans le bloc server, après évaluation de la phase de journalisation
if ($multipart_fremd) {
return 403;
}
Dans Apache, mod_rewrite prend en charge cette tâche. Selon la documentation d'Apache, plusieurs conditions sont combinées par ET :
RewriteEngine On
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/kontakt/upload\.php$
RewriteCond %{REQUEST_URI} !^/admin/medien/
RewriteRule ^ - [F]
Si vous utilisez un CDN ou un WAF dans le cloud, la même logique peut souvent être reproduite sous forme de règle dédiée. Là aussi : d'abord en mode journalisation, puis blocage.
Le filtre ne remplace pas la mise à jour de PHP et n'est pas une raison de la repousser. PHP2Shell n'est corrigé qu'avec PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou un backport confirmé, suivi du redémarrage de tous les processus PHP.
Bien situer la mesure
Le filtre d'upload s'inscrit dans une série d'autres propositions qui circulent actuellement. Certaines sont judicieuses, d'autres nuisibles. Un aperçu des conseils que les auteurs spécialisés rejettent, par exemple le blocage de toutes les requêtes avec cookie de session, est donné dans Conseils dangereux sur PHP2Shell.
La manière dont PHP traite les uploads en interne et pourquoi le format multipart/form-data y joue un rôle particulier est expliquée dans Comment PHP traite les uploads de fichiers. Pour la plupart des entreprises, l'étape la plus importante n'est toutefois pas le filtre, mais une date claire pour la mise à jour.
Conclusion : un outil pour des jours, pas pour des mois
Le filtre d'upload en bordure est un exemple typique de mesure d'urgence : il peut réduire la surface d'attaque pendant la période transitoire, mais a des effets secondaires et ne bénéficie d'aucun soutien officiel de php.net. Utilisé correctement, avec phase de journalisation, liste d'exceptions concertée, tests et date de fin fixe, il est défendable. Sans ces étapes, vous risquez des candidatures perdues, des rédactions bloquées et des erreurs d'interface silencieuses.
Prenez donc la décision en connaissance de cause et consignez qui l'a prise et quand. Et gardez l'ordre en tête : d'abord vient la mise à jour de PHP avec redémarrage de tous les workers, les mesures transitoires de php.net comblent le temps d'ici là, et le filtre n'est tout au plus qu'une couche supplémentaire.
Comment PHP SOS aide-t-il concrètement ?
- Évaluer la situation : nous clarifions si un filtre d'upload a un sens dans votre situation ou si la mise à jour est possible plus rapidement.
- Journaliser et analyser : nous mettons en place la phase de journalisation et déduisons la liste d'exceptions d'accès réels.
- Bloquer de façon contrôlée : nous activons le filtre, testons formulaires et parcours de commande et surveillons les requêtes rejetées.
- Démonter proprement : dans le cadre de WAF et correctif virtuel, nous retirons le filtre après la mise à jour.
Questions fréquentes
Filtrer les requêtes multipart est-il une recommandation officielle de php.net ?
Non. php.net cite d'autres mesures transitoires, par exemple des limites pour post_max_size et la désactivation de session.upload_progress. Le filtrage en bordure est une proposition issue d'articles spécialisés, expressément conçue comme mesure temporaire seulement.
Quelles fonctions peuvent tomber à cause du filtre ?
Tout ce qui envoie des fichiers ou des formulaires au format multipart et ne figure pas sur votre liste d'exceptions : formulaires de contact avec pièce jointe, formulaires de candidature, gestion des médias dans le CMS, fonctions d'import, certaines interfaces et retours de paiement. C'est pourquoi une phase de journalisation précède le blocage.
Le filtre remplace-t-il la mise à jour de PHP ?
Non. Il réduit tout au plus la surface d'attaque pendant la période transitoire. Cloudflare souligne lui-même que des règles fondées sur les seules données de la requête ne suffisent pas. PHP2Shell n'est corrigé qu'avec une version corrigée de PHP et le redémarrage de tous les workers.
Dois-je bloquer à la place les requêtes avec PHPSESSID ?
Non. Ce conseil qui circule est expressément rejeté par les auteurs spécialisés. Il paralyse les connexions et les paniers sans offrir de protection solide.