web-dev-qa-db-fra.com

Évaluations de deux plans de sécurité wordpress contre les attaques par injection de code php

Senario:

J'ai posté un senario d'injection de code wordpress sur SO auparavant, url: https://stackoverflow.com/questions/26826082/what-is-the-highly -efficace-moyen-de-supprimer-un-bloc-de-chaîne-modèle-dans-fichier-php

J'ai constaté que cela se produisait régulièrement sur certains sites WordPress, ce qui entraînait un crash du plugin ou l'impossibilité de se connecter/wp-admin jusqu'à ce que vous ayez supprimé tous les modèles d'injection de tous les fichiers php en utilisant la méthode fastidieuse que j'ai mentionnée dans le post ci-dessus, cependant, jusqu'à présent, je ne sais pas où la faille est pour un attaquant d'injecter un tel code dans wordpress.

Néanmoins, après des recherches en plus de nettoyer régulièrement les fichiers de sauvegarde. J'ai ci-dessous des plans de sécurité wordpress pour éviter les injections:

Solution 1. Plan de mise à jour de wordpress

        meaning always check out updates wordpress to latest version
        always check out updates making sure plugins to latest version.

Solution 2. configuration stricte des permissions fichier/dossier sur wordpress [php, fichiers normaux, dossiers]

        never allow php file updates on production site, 
        Apache chmod set 
        all wordpress *.php files to chmod 644; 
        all normal files  *.js *.css *.html etc to 755; 
        wp-upload folder set chmod to 755
        rest wordpress folder set chmod to 644;

Pour ces deux approches,

Solution1: (concentrez-vous sur la mise à jour vers la dernière version comptant les derniers correctifs pour résoudre les vulnérabilités tout en laissant chmod comme autorisation par défaut lorsque wordpress/plugin est installé.)

est en fait très consommateur de travail car il y a tant de mises à jour à prendre en charge et vous ne savez jamais si la mise à jour de ce plugin causera un problème de compatibilité avec la version wordpress. et je ne pense pas qu'il puisse tout couvrir pour empêcher l'injection dans mon SO message. de plus, si le site a déjà été injecté et que vous ne vous êtes pas arrêté avant de commencer un processus de mise à jour, cela causera généralement un crash du plugin, comme je l’ai déjà vu plusieurs fois auparavant. Mais le plan de mise à jour est la méthode la plus répandue pour renforcer la sécurité wordpress, mais nécessite une surveillance humaine et une maintenance lors des mises à jour.

Solution2: (concentrez-vous sur la personnalisation des autorisations chmod pour interdire les modifications de fichiers) Voici un lien de référence du codex sur le paramètre chmod de wordpress: http://codex.wordpress.org/Changing_File_Permissions

semble raisonnable, mais devra absolument vérifier si la surprotection de chmod cause des incompatibilités avec les plugins actifs, etc. Certains plugins nécessitant des autorisations non sécurisées pour fonctionner. Cela signifie également que peu de modifications peuvent être apportées au site de production conformément à la configuration des autorisations.

Donc, les gars, quelle approche suggéreriez-vous de sécuriser les fichiers wordpress php d’être injectés? tout commentaire sur les deux solutions ci-dessus.

Ou de meilleurs plans pour lutter contre ce type d'injections de code?

(Les solutions moins impliquées dans la surveillance humaine sont préférées.)

phpsecurityserverapache
1
BOBO

Premièrement, ces deux choses (mises à jour et autorisations de fichiers saines) ne sont ni un choix "OU" ni une option. C'est ce que vous vous faites , car si vous ne le faites pas tôt ou tard (même si c'est beaucoup plus tard), vous allez avoir des problèmes à cause de cela. Relativement, je dirais que les mises à jour sont plus importantes, car les autorisations de fichiers défectueux ont tendance à être dommageables dans un environnement déjà compromis (comme un hébergement partagé mal configuré).

Deuxièmement, si vous à plusieurs reprises rencontrez une infection de votre/vos site (s), aucun des deux ne ferait quoi que ce soit pour vous. Vous avez un problème sérieux quelque part, soit facilement détecté comme pouvant être exploité par des scanners automatisés, soit quelqu'un le sait et continue à l'exploiter manuellement. Avant de déterminer ce qu'est ce trou et comment le fermer, toute autre mesure de sécurité est quasiment théorique.

2
Rarst