O que um hacker poderia fazer com o meu wp-config.php

Estou tentando proteger meu blog wordpress. Eu li algumas postagens na web que eu deveria mudar meu table_prefix e ocultar meu wp-config.php . No entanto, não entendi? O que um atacante pode fazer com o meu wp-config.php ?

Quero dizer, existem minhas configurações de db, mas o invasor precisa do meu DB_HOST por exemplo, o que não é tão fácil de obter, para se conectar ao meu db? (No meu caso é: define('DB_HOST', 'localhost'); , que o invasor não pôde usar para se conectar ao meu db)

Ou estou faltando sth?

Eu realmente aprecio sua resposta!

Solutions Collecting From Web of "O que um hacker poderia fazer com o meu wp-config.php"

localhost refere-se à máquina em que está sendo executada. Por exemplo, no meu próprio site, tomjn.com localhost é 127.0.0.1 como sempre é. Isso não significa que o hacker não sabe onde se conectar, isso significa que o hacker substitui localhost com tomjn.com .

Claro, se eu tiver um proxy sentado na frente, isso não funcionará, mas tenha em mente que, se o invasor tiver access ao meu wp-config.php , esse mesmo access os deixaria fazer outras coisas naquela máquina.

Então, agora, o atacante tem os detalhes do database e eles podem ler o wp-config.php . Agora eles têm access a tudo em seu database e podem mudar qualquer coisa em seu database.

Dependendo da segurança da sua instalação, eles podem criar um usuário para si próprios, fazer logon, fazer o upload de um plugin via zip com um script PHP Shell e começar a emitir comandos ou usar o site como parte de uma rede bot.

Eles também têm seus sais e chaves secretas (se você não tem nenhum desses, mau e mau ruim), então o bruta forçando as senhas de seus usuários torna-se significativamente mais fácil. Eles também têm access aos seus e-mails.

Basta dizer que obter o wp-config.php é uma das piores coisas que podem acontecer. Muitas coisas mais podem ser feitas com isso, mas levaria meses para digitar todos os possíveis ataques resultantes disso.

No caso de sua wp-config.php ser adquirida, é provável que um script de ataque automatizado tenha feito isso, não uma pessoa real. Mude todos os seus detalhes, redefina todas as senhas e feche o furo.

Se você só aceita o access ao database do localhost (isso não é alcançado definindo DB_HOST como localhost )? Não muito por si só (o pior caso seria um atacante assumindo a conta do administrador), mas em combinação com outras vulnerabilidades, pode ser útil para um invasor ter access à sua configuração.

Credenciais de login

As pessoas reutilizam seus nomes de usuário e senhas. Um invasor verificará se seu nome de usuário e senha do database (ou variações deles) funcionam para sua instalação wordpress, para o seu hoster, para o seu e-mail, etc.

No mínimo, um atacante tem uma idéia do tipo de senhas que você usa (totalmente random, apenas minúsculas / números, comprimento, etc.).

Prefixo de tabela

Se houver uma injeção SQL possível, um invasor deve conhecer os nomes das tabelas. Dependendo do database, isso pode ser muito fácil, ou pode envolver adivinhação. Se isso implique adivinhar, é melhor ter o prefixo da tabela.

Chaves e sais

Eu achei este artigo sugerindo que você realmente não quer que estes vazem (basicamente, qualquer um poderia assumir sua conta de administrador), embora eu não saiba o quão atualizado é.

Charset de database

Algumas injeções de SQL dependem do conjunto de caracteres, por isso é bom para um invasor saber disso.

Resumo

Se você não permitir o access externo ao database, se você não reutilizar senhas, e se você não tiver nenhuma injeção de SQL em qualquer lugar, a principal preocupação seria a chave e os sais.

Eu suponho que você está perguntando sobre access de leitura, pois o access de gravação é basicamente access para injetar seu próprio código para fazer o que quiser com seu site.

A sua suposição de que a informação DB não é sensível é errada. Vamos assumir que seu site está hospedado em godaddy. Godaddy AFAIK está usando um servidor mysql dedicado, que provavelmente só pode ser acessado a partir de seus próprios servidores, mas se eu conheço seus detalhes, é difícil criar uma conta godaddy e escrever um script que acessa seu database? No caso de bancos de dados locais, é mais difícil de explorar, mas em servidores de hospedagem compartilhada, você pode ter 100 sites compartilhando o servidor com você, você pode confiar neles para ter certeza de que o Sr. Evil não pode invadir eles e usá-los para atacar seu site?