Pourquoi des conseils courants peuvent passer à côté du vrai problème
De nombreuses recommandations semblent bonnes, mais n’améliorent pas de manière significative la sécurité d’un site WordPress typique.
Je m'appelle Cory Marsh et je travaille dans le domaine de la sécurité Web depuis plus de 25 ans dans l'Idaho et en Californie. Pendant cette période, j’ai entendu de nombreuses recommandations de sécurité qui semblent bonnes mais n’améliorent pas réellement votre posture de sécurité.
Beaucoup de ces recommandations proviennent d’un malentendu sur le fonctionnement de PHP et du Web. Étant donné que la plupart des sites WordPress sont hébergés sous Linux, cet article se concentre sur des conseils courants pour les sites WordPress fonctionnant sur un hébergement Web Linux typique.
Les autorisations de fichiers ne fonctionnent pas comme le suggèrent de nombreux guides
« L'autorisation publique d'écriture » est souvent décrite comme si n'importe qui sur Internet pouvait modifier vos fichiers PHP. Ce n’est pas ainsi que fonctionne un hébergeur WordPress normal.
Chaque fichier d'un système de fichiers Unix dispose d'autorisations de lecture, d'écriture et d'exécution. Ces autorisations peuvent être définies pour le propriétaire du fichier, le groupe de fichiers et toute autre personne, souvent appelée « publique » ou « autre ». Le malentendu commence lorsque les gens supposent que l'accès public en écriture signifie que tout utilisateur Internet distant peut modifier le fichier.
La plupart des sites WordPress utilisent un serveur Web tel que Nginx, Apache ou LiteSpeed et un serveur PHP tel que PHP-FPM. Ceux-ci s’exécutent généralement localement sous le nom du même utilisateur Web. Ils utilisent les autorisations des utilisateurs locaux, et non une autorisation publique directe sur Internet.
Pour qu'un système distant puisse modifier des fichiers via des autorisations de fichiers publics, il aurait besoin d'un accès au système de fichiers distant, tel qu'un partage NFS monté publiquement. Ce n’est pas ainsi que les fournisseurs d’hébergement classiques exposent WordPress. Vous devez toujours maintenir des autorisations cohérentes et réduire les accès en écriture inutiles, mais les autorisations publiques Unix ne constituent pas le risque direct d'édition à distance qu'impliquent de nombreuses listes de contrôle.
La sécurité des sociétés d’hébergement n’est pas le fondement de la prévention des exploits WordPress
Les mises à jour du système d’exploitation sont importantes, mais la plupart des compromis WordPress ne commencent pas par un package système obsolète.
Je ne veux pas jeter du sel dans le jeu marketing d’un fournisseur d’hébergement, mais j’ai rarement vu un site WordPress compromis en raison d’un système d’exploitation obsolète. À quelques exceptions inhabituelles telles qu’ImageMagick, il n’existe pas beaucoup de packages de système d’exploitation que le code PHP normal peut atteindre directement d’une manière qui conduit au compromis WordPress courant.
PHP est le système qui exécute le code d'application dynamique avec lequel les attaquants interagissent. Sur un hôte WordPress Linux typique, l'attaquant est beaucoup plus susceptible d'exploiter un plugin, un thème ou un point de terminaison non authentifié vulnérable qu'une vulnérabilité du noyau ou d'un package système.
Changer le préfixe de la base de données WordPress ne constitue pas une protection significative
Le préfixe par défaut est suffisamment visible pour les attaquants et assez facile à découvrir pour les logiciels malveillants.
WordPress a un préfixe de table de base de données. La valeur par défaut est wp_. Ce comportement provient de l’historique de WordPress, y compris des modèles multi-sites et multi-utilisateurs où des tables distinctes nécessitaient des préfixes distincts.
Aujourd’hui, changer le préfixe n’apporte que peu de valeur en matière de sécurité. Les logiciels malveillants modernes et les outils d'exploitation automatisés peuvent découvrir ou déduire le préfixe. L’existence de nombreux chemins d’exploitation wp-to-shell montre que cette valeur ne constitue pas une limite sérieuse à l’ère moderne des logiciels malveillants assistés par l’IA.
La suppression du numéro de version de WordPress n'arrête pas les attaquants
La plupart des attaques ne vérifient pas soigneusement votre balise de générateur avant de tenter un exploit.
Masquer le numéro de version de WordPress dans les balises du générateur rend généralement plus difficile pour les scanners de sécurité de signaler avec précision votre version. La plupart des attaques automatisées ne prennent pas la peine de vérifier au préalable le serveur Web ou la version de WordPress. Ils envoient l'exploit à toutes les cibles qu'ils peuvent trouver.
Si le site est vulnérable, il est compromis. S'il n'est pas vulnérable, l'attaquant continue son chemin. Dans certains cas, vérifier d’abord les versions peut même alerter les logiciels de sécurité et interdire l’adresse IP d’un attaquant avant que le véritable exploit ne soit lancé.
Un bon WAF ne bloque pas toutes les attaques Web
Les WAF traditionnels peuvent bloquer certaines attaques, mais de nombreux exploits WordPress modernes sont des problèmes de contrôle d'accès brisés.
Les ensembles de règles de pare-feu tels que 6G, 7G ou un WAF préféré peuvent bloquer certaines attaques Web. Ils sont souvent utiles contre certaines parties des scripts intersites et de l'injection SQL, même si même là, le bilan est mitigé. S’ils bloquent de manière trop agressive, ils bloquent le bon trafic. S'ils ne bloquent pas suffisamment, la valeur est limitée.
Les produits WAF en ligne de fournisseurs tels qu'AWS, Cloudflare et Sucuri peuvent faire un excellent travail avec les classes d'attaques qu'ils comprennent. Le problème est que de nombreux compromis WordPress modernes ne sont pas des injections XSS ou SQL classiques. Ils ont un contrôle d'accès brisé.
Un contrôle d'accès rompu signifie qu'un développeur a oublié d'exiger un administrateur valide ou un utilisateur autorisé avant d'autoriser une opération dangereuse, telle que le téléchargement d'un fichier sur un point de terminaison d'API. Un WAF basé sur des signatures peut n'avoir aucune idée de ce que la requête est sur le point de faire dans PHP. Il voit une demande, recherche des modèles connus et peut faire passer l'exploit.
Utiliser la protection d'exécution pour les comportements d'application dangereux
Le risque numéro un en matière de sécurité des applications nécessite des contrôles capables d’observer ce que fait la requête.
Pour obtenir une véritable protection contre les violations du contrôle d'accès, vous avez besoin d'une protection d'exécution qui surveille la requête pendant son exécution et empêche les requêtes non authentifiées d'effectuer des actions dangereuses. Un outil comme BitFire pour WordPress inclut la fonctionnalité RASP qui peut empêcher l'exploitation de plugins et de thèmes vulnérables en bloquant les opérations dangereuses en contexte.
Définissez des autorisations cohérentes sur le système de fichiers et réduisez les accès inutiles lorsque cela est possible.
Gardez le système d'exploitation, PHP, le noyau WordPress, les plugins et les thèmes à jour.
Un bon WAF peut bloquer les attaques réelles, en particulier les modèles malveillants connus et les tentatives d'injection courantes.
Empêchez les requêtes non authentifiées d'écrire des fichiers, de modifier des données sensibles ou d'effectuer des actions administratives.
Toutes les recommandations courantes ne sont pas mauvaises. Vous devez implémenter des autorisations de fichiers raisonnables. Vous devez garder votre système d'exploitation à jour pour la compatibilité, les correctifs et les améliorations de performances. Vous devriez exécuter un bon WAF car il peut bloquer certaines attaques réelles.
Ne vous attendez pas à ce que ces recommandations à elles seules sauvent votre site Web lorsque la prochaine vulnérabilité du plugin affecte votre site.
