Quand les redirections WordPress deviennent une vulnérabilité qui tue les serveurs

J’ai passé des années à optimiser WordPress sites, réglage MySQLen améliorant les configurations de serveur et en recherchant les goulots d’étranglement des performances. Mais rien ne m’a préparé à la découverte que j’ai faite lorsque mon propre serveur a commencé à fondre sous l’incessante Processeur charge au cours du mois dernier. Il ne s’agissait pas d’un pic de trafic. Ce n’était pas un plugin défaillant. Ce n’était même pas une mauvaise question au sens habituel du terme. Le véritable coupable s’est avéré être quelque chose auquel je ne m’attendais pas : la façon dont WordPress redirige les correspondances du cache du plugin.

En apparence, la mise en cache des résultats de redirection semble intelligente. Si un plugin de redirection détecte une correspondance de modèle, pourquoi le réévaluer pour le même chemin ? Avec des redirections exactes, ce comportement est inoffensif, voire bénéfique. Mais une fois qu’un site est attaqué et que vous vous mélangez LIKE ou des redirections de type regex, le cache de redirection devient un handicap si grave qu’il peut tranquillement détruire les ressources de votre serveur.

C’est l’histoire de la façon dont j’ai découvert cette vulnérabilité en traçant les problèmes de performances depuis les pics de CPU jusqu’à la saturation de MySQL, puis en approfondissant la croissance des tables qui est devenue complètement incontrôlable.

L’effondrement commence

Mon serveur fonctionnait plus rapidement que jamais depuis la migration vers Volerdonc l’augmentation soudaine de la consommation du processeur était préoccupante. MySQL était systématiquement associé à une utilisation élevée, PHP les travailleurs faisaient la queue et même le simple chargement des pages semblait lent. Le redémarrage du serveur m’a offert une brève fenêtre de stabilité, mais en quelques heures, tout se dégraderait à nouveau.

Quelque chose n’allait fondamentalement pas.

J’ai activé la journalisation complète des requêtes, dans l’espoir de trouver des jointures coûteuses ou des recherches non indexées. Au lieu de cela, une tendance surprenante est apparue. Un grand nombre de requêtes frappaient une table de cache de redirection créée par les plugins de redirection WordPress. Au début, cela ne m’a pas alarmé : la mise en cache des correspondances de redirection est une technique courante pour accélérer les requêtes futures. Mais le nombre d’entrées mises en cache dépassait de loin tout ce que le trafic normal pouvait justifier.

Cela m’a conduit dans un terrier de lapin.

Retracer le problème jusqu’à MySQL

La taille de la table de cache de redirection augmentait. Chaque fois que je vérifiais, il y avait des milliers de lignes supplémentaires. Un examen plus approfondi révèle pourquoi : chaque fois qu’un URL a frappé le serveur et toute règle de redirection a utilisé une correspondance partielle –LIKE comparaisons, modèles génériques ou regex : le plugin a enregistré le résultat en tant que toute nouvelle entrée de cache.

Les pirates et les robots d’exploration n’essayaient pas une poignée d’URL. Ils frappaient des milliers de permutations sur l’ensemble du site :

/random-path
/random-path1
/random-path2
/admin-old
/admin-new
/login-old
/login-backup

Chacun de ces chemins a déclenché une nouvelle évaluation de redirection. Avec les redirections basées sur des modèles en jeu, le plugin a dû effectuer des comparaisons coûteuses avec ses règles de redirection. Et comme il mettait en cache chaque correspondance, le tableau s’agrandissait à chaque requête faite par les robots, les scanners et les outils de force brute.

Plus le tableau devenait grand, plus chaque comparaison devenait coûteuse. MySQL n’avait aucune chance de suivre le rythme. Le serveur n’était pas submergé par le trafic légitime. Elle était submergée par le coût de la gestion des modèles de redirection.

Le danger caché des redirections basées sur des modèles

Les plugins de redirection pour WordPress promettent tous une correspondance flexible :

• Rediriger tout ce qui commence par un chemin spécifique
• Rediriger tout ce qui se termine par une structure spécifique
• Modèles de redirection à l’aide de caractères génériques
• Redirection en utilisant full expression régulière soutien

Ces fonctionnalités sont puissantes en théorie et inoffensives sur les petits sites. Le danger n’apparaît que lorsque la mise en cache de redirection et la correspondance de modèles entrent en collision à grande échelle.

La mise en cache semble être une bonne pratique, et avec des redirections exactes, c’est le cas. Mais quand LIKE Si des opérateurs ou des modèles d’expression régulière sont impliqués, la mise en cache devient une bombe à retardement. La combinaison d’une logique de recherche lourde, d’une correspondance continue et d’une croissance illimitée du cache signifie qu’un pirate informatique déterminé n’a même pas besoin de cibler spécifiquement les redirections. Sonder les chemins sur votre site suffit à paralyser votre serveur.

À mesure que davantage d’URL sont testées, davantage de lignes de cache sont créées. À mesure que davantage de lignes sont créées, chaque nouvelle comparaison devient plus lente. À mesure que les comparaisons ralentissent, l’utilisation du processeur augmente. Finalement, MySQL devient surchargé, les threads PHP calent derrière lui et l’architecture entière commence à se déformer.

Ce n’est pas un défaut dans un plugin. C’est ainsi que les plugins de redirection WordPress fonctionnent universellement lorsque la correspondance complexe est activée.

Trouver la cause profonde

Une fois que j’ai corrélé la charge de requête avec l’activité de mise en cache de redirection, j’ai inspecté directement la table de cache. Il était devenu si grand que même les opérations de base étaient lentes. Il n’était pas rare de voir des milliers de lignes ajoutées dans une courte fenêtre. Chaque scanner, robot d’exploration et robot frappant des chemins imprévisibles ajoutait plus d’entrées.

À ce stade, la vulnérabilité est devenue évidente : les plugins de redirection WordPress permettent involontairement aux attaquants d’encourir des coûts exponentiels en sondant un grand nombre d’URL. Ils n’ont pas besoin de chemins valides. Ils n’ont pas besoin de s’introduire par effraction. Il leur suffit de forcer la logique de redirection pour fonctionner.

Le moteur de redirection a fait le reste.

Le correctif

Une fois que j’ai compris la mécanique, la solution est apparue rapidement. Bien que le nom de la table varie selon le plugin, chaque plugin de redirection conserve un cache similaire. Dans ce cas, j’utilise Classement mathématique pour mes exemples ci-dessous:

1. Supprimez toutes les redirections de style LIKE et regex: toute règle de redirection utilisant une correspondance basée sur un modèle devait être désactivée. Seules les redirections exactes un à un pouvaient rester actives. Parce que l’administrateur était réactif, j’ai dû le faire via une requête UPDATE directement sur ma base de données.

UPDATE wp_rank_math_redirections
SET status="inactive"
WHERE sources NOT LIKE '%"comparison":"exact"%';

2. Tronquer la table du cache de redirection: Effacer la table a supprimé l’énorme arriéré de correspondances stockées :

TRUNCATE TABLE wp_rank_math_redirections_cache;

3. Surveiller le serveur après le nettoyage: La charge du processeur a chuté presque instantanément. MySQL stabilisé. Les travailleurs PHP ont repris leur fonctionnement normal. La croissance effrénée s’est arrêtée.

Les redirections exactes ont fonctionné exactement comme prévu. Sans redirections génériques ou regex, aucune attaque ne pourrait forcer la croissance du cache.

Ce que cela signifie pour les utilisateurs de WordPress

Les plugins de redirection WordPress ne sont pas sécurisés au sens traditionnel du terme. Mais ils partagent une vulnérabilité architecturale commune : la mise en cache des résultats de redirection n’est bénéfique que lorsque ces redirections sont exactes. Une fois la correspondance de modèles introduite, la mise en cache devient dangereuse car chaque URL inconnue devient une nouvelle entrée de cache.

Sur un site à fort trafic ou fortement exploré, cela signifie :

• La croissance de la table devient illimitée
• MySQL est débordé
• Spirales d’utilisation du processeur
• Le serveur ralentit ou tombe en panne

La meilleure protection est simple :

• Ne comptez jamais sur les redirections génériques ou regex dans WordPress
• Gardez la logique de redirection exacte autant que possible
• Transférez des règles de redirection complexes vers NGINX ou une couche périphérique CDN
• Inspectez ou effacez périodiquement les tables de cache de redirection

La mise en cache de redirection est utile lorsqu’elle est utilisée avec des règles simples et exactes. Mais une fois que le site est soumis à une enquête automatisée et que vous disposez de redirections basées sur des modèles, ce même mécanisme de mise en cache devient un handicap qui peut dévaster les performances du serveur.

J’ai appris cela à mes dépens. Espérons que cela aide quelqu’un d’autre à éviter le même piège.