J'essaie de sécuriser mon blog wordpress. J'ai lu quelques articles sur le Web que je devrais changer table_prefix
et cacher wp-config.php
. Cependant, je ne comprends pas? Que pourrait faire un attaquant avec moi wp-config.php
?
Je veux dire qu'il y a mes configurations de base de données, mais l'attaquant a besoin de ma DB_HOST
par exemple, qui n'est pas si facile à obtenir, pour se connecter à ma base de données? (Dans mon cas define('DB_HOST', 'localhost');
, c'est:, que l'attaquant ne pouvait pas utiliser pour se connecter à ma base de données )
Ou me manque-t-il?
J'apprécie vraiment ta réponse!
Réponses:
localhost
fait référence à la machine sur laquelle il tourne. Par exemple, sur mon propre site, tomjn.com localhost est127.0.0.1
comme il est toujours. Cela ne signifie pas que le pirate ne sait pas où se connecter, cela signifie que le pirate remplacelocalhost
partomjn.com
.Bien sûr, si j'ai un proxy devant, cela ne fonctionnera pas, mais gardez à l'esprit que si l'attaquant a accès à mon
wp-config.php
, ce même accès leur permettrait de faire d'autres choses sur cette machine.Alors maintenant, l'attaquant a les détails de votre base de données, et ils peuvent lire
wp-config.php
. Ils ont désormais accès à tout dans votre base de données et peuvent tout changer dans votre base de données.Selon la sécurité de votre installation, ils peuvent créer un utilisateur pour eux-mêmes, se connecter, télécharger un plugin via zip avec un script PHP Shell et commencer à émettre des commandes ou utiliser le site dans le cadre d'un réseau de robots.
Ils ont également vos sels et vos clés secrètes (si vous n'en avez pas, mauvais mauvais mauvais), donc le forçage brutal des mots de passe de vos utilisateurs devient beaucoup plus facile. Ils ont également accès à leurs e-mails.
Il suffit de dire qu'obtenir
wp-config.php
est l'une des pires choses qui puisse arriver. Beaucoup plus de choses peuvent être faites avec mais il faudrait des mois pour taper toutes les attaques possibles qui en découlent.Dans le cas où votre
wp-config.php
est acquis, il est probable qu'un script d'attaque automatisé l'ait fait, pas une personne réelle. Modifiez toutes vos informations, réinitialisez tous les mots de passe et fermez le trou.la source
localhost
partomjn.com
. > Cela suppose que vous avez le port de la base de données accessible au monde extérieur. Ne seriez-vous pas en sécurité si vous fermiez le port dans les règles de pare-feu, autorisant uniquement les ordinateurs du réseau local (y compris l'ordinateur exécutant wordpress lui-même) à se connecter à la base de données?Si vous acceptez uniquement l'accès à la base de données à partir de
localhost
(cela ne se fait pas en définissantDB_HOST
commelocalhost
)? Pas trop par lui-même (le pire des cas serait un attaquant prenant le compte administrateur), mais en combinaison avec d'autres vulnérabilités, il pourrait être utile pour un attaquant d'avoir accès à votre configuration.Identifiants de connexion
Les gens réutilisent leurs noms d'utilisateur et mots de passe. Un attaquant vérifiera si le nom d'utilisateur et le mot de passe de votre base de données (ou des variantes de ceux-ci) fonctionnent pour votre installation wordpress, pour votre hébergeur, pour votre e-mail, etc.
À tout le moins, un attaquant a une idée du type de mots de passe que vous utilisez (totalement aléatoire, uniquement en minuscules / chiffres, longueur, etc.).
Préfixe de table
S'il y a une injection SQL possible, un attaquant doit connaître les noms des tables. Selon la base de données, cela peut être très simple ou impliquer des devinettes. Si cela implique de deviner, il est préférable d'avoir le préfixe de table.
Clés et sels
J'ai trouvé cet article suggérant que vous ne vouliez vraiment pas que ces fuites (en gros, n'importe qui puisse prendre le contrôle de votre compte administrateur), bien que je ne sache pas à quel point il est à jour.
Base de données Charset
Certaines injections SQL dépendent du jeu de caractères, il est donc bon pour un attaquant de le savoir.
Résumé
Si vous n'autorisez pas l'accès extérieur à la base de données, si vous ne réutilisez pas les mots de passe et si vous n'avez aucune injection SQL n'importe où, la principale inquiétude serait la clé et les sels.
la source
Je suppose que vous posez des questions sur l'accès en lecture, car l'accès en écriture est essentiellement un accès pour injecter son propre code pour faire tout ce qu'il veut avec votre site.
Votre hypothèse selon laquelle les informations DB ne sont pas sensibles est fausse. Supposons que votre site soit hébergé chez godaddy. godaddy AFAIK utilise des serveurs mysql dédiés qui ne sont probablement accessibles que depuis leurs propres serveurs, mais si je connais vos coordonnées, est-ce difficile pour moi de créer un compte godaddy et d'écrire un script qui accède à votre base de données? Dans le cas de bases de données locales, il est plus difficile à exploiter, mais sur des serveurs d'hébergement partagé, vous pouvez avoir 100 sites partageant le serveur avec vous, pouvez-vous leur faire confiance pour être suffisamment sécurisés pour que M. Evil ne puisse pas les pénétrer et les utiliser pour attaquer votre site?
la source