Wordpress contient-il un code d'injection anti-SQL "par défaut" qui répond par une erreur 404?
J'ai déjà parcouru les "sept couches de la forêt de canne à sucre" sur celle-ci… :)
Notre plugin reçoit les données via une requête POST. Sur un site particulier sur lequel notre plug-in est installé, nous avons observé un comportement étrange. Dans un scénario spécifique, les demandes POST généraient par erreur une erreur 404 (non trouvé).
J'ai commencé très large et j'ai réduit le problème petit à petit jusqu'à ce qu'il me reste le scénario de reproduction suivant. L'erreur déroutante se produit pour:
- Toute demande "POST"
- vers n'importe quelle URL inférieure ou égale à http://example.com/wp-content/
- qui fournit des données x-www-form-urlencoded
- avec
or("ou" suivi d'un espace; non sensible à la casse) suivi immédiatement d'un numéro n'importe où dans les données soumises (pas seulement les valeurs de champ) (par exemple,an ARM or 30-year fixed-rate mortgage)
J'ai vérifié les autres plugins installés. Rien. J'ai vérifié les modèles. Nada. J'ai vérifié quelques autres sites avec notre plugin installé mais je ne pouvais toujours pas reproduire le bogue.
D'après tout ce que je peux dire, il s'agit d'un problème extrêmement spécifique sur le site en question. En raison du scénario de reproduction, je suppose que cela est dû à un code d'injection anti-SQL trop ambitieux.
Existe-t-il un code présent par défaut dans Wordpress qui pourrait être à l'origine de ce problème? Mon hypothèse est que ce problème est à blâmer pour autre chose (par exemple un pare-feu, une règle .htaccess, etc. ), mais je pensais que je vérifierais avec les experts! :)
Mettre à jour:
Nous avons également observé ce problème avec des données de publication au format "[opérateur] ayant [chaîne]", telles que < having x, or having y, and having z, etc. Étant donné que HAVING est un mot clé SQL, je soupçonne qu'il s'agit d'une preuve supplémentaire d'un outil de sécurité mal configuré. Notez que ces différentes observations ont été faites sur différents serveurs, ce n'est donc pas quelque chose de génial sur ce serveur unique. Je suppose que plusieurs serveurs pourraient être mal configurés/avoir des protocoles de sécurité stricts en place, bien que ...
Une autre mise à jour: j'ai à nouveau rencontré ce problème. Cette fois-ci, j’ai simplifié le problème POST charge utile simplement en la chaîne <strong>. Toute donnée POSTed incluant cette chaîne (en ligne avec les autres conditions ci-dessus) génère un 404.
Comme suggéré par @Jeff Mattson, des heures de recherche et de tests laissent penser que cela est probablement dû à mod_security. J'ai également étudié la probabilité que cela soit dû à Suhosin, mais je ne pense pas que ce soit à blâmer.
Voici le deal. Cela n'aide pas vraiment si nous vérifions que le problème est dû à mod_security. Nous ne contrôlons pas les serveurs qui exécutent notre plugin et nos efforts pour désactiver mod_security via .htaccess ont échoué.
Heureusement, il y a de la lumière au bout du tunnel. Indépendamment de la cause du problème, un correctif presque garanti consiste à modifier simplement nos données POST.
La solution que je prévois d'implémenter consiste à coder en base62 les données que nous envoyons à notre plugin. Base64 fonctionnerait probablement aussi, mais j'aimerais résoudre ce problème une fois pour toutes et, en raison de son jeu de caractères limité, Base62 est le pari le plus sûr face à une bête névrosée comme mod_security.
Cela devrait fonctionner car mod_security recherche certaines chaînes de "problèmes" dans les données soumises. Je doute que le module soit suffisamment sophistiqué pour essayer d'appliquer différents codages aux données soumises (sans quoi cela nuirait aux performances), il est donc presque certain que cela résoudra nos problèmes.
Yay!