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

localhost refere-se à máquina em que está sendo executado. 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 saiba onde se conectar, isso significa que o hacker substitui localhost por tomjn.com .

É claro que se eu tiver um proxy sentado na frente, isso não funcionará, mas lembre-se de que se o atacante tiver acesso ao meu wp-config.php , esse mesmo acesso permitiria que eles fizessem outras coisas nessa máquina.

Agora, o invasor tem os detalhes do seu banco de dados e eles podem ler wp-config.php . Eles agora têm acesso a tudo em seu banco de dados e podem alterar qualquer coisa em seu banco de dados.

Dependendo da segurança de sua instalação, eles podem criar um usuário para si mesmos, efetuar login, fazer upload de um plug-in via zip com um script PHP Shell e começar a emitir comandos ou usar o site como parte de uma bot net.

Eles também têm seus sais e chaves secretas (se você não tem nada disso, ruim, ruim, ruim), então a força bruta forçando as senhas dos usuários fica significativamente mais fácil. Eles também têm acesso aos seus e-mails.

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

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

Se você aceitar apenas o acesso ao banco de dados de localhost (isso não é possível definindo DB_HOST as localhost )? Não muito por si só (o pior caso seria um invasor invadindo a conta de administrador), mas, em combinação com outras vulnerabilidades, pode ser útil para um invasor ter acesso à sua configuração.

Credenciais de login

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

No mínimo, um invasor tem uma ideia de que tipo de senha você usa (totalmente aleatório, apenas letras minúsculas / números, tamanho, etc.).

Prefixo da tabela

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

Chaves e sais

Eu encontrei este artigo sugerindo que você realmente Não quero que isso vaze (basicamente, qualquer um poderia assumir sua conta de administrador), embora eu não saiba o quanto está atualizado.

Conjunto de caracteres do banco de dados

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

Resumo

Se você não permitir acesso externo ao banco de dados, se não reutilizar as senhas e não tiver nenhuma injeção de SQL em algum lugar, a principal preocupação seria a chave e os sais.

Suponho que você esteja perguntando sobre o acesso de leitura, já que o acesso de gravação é basicamente o acesso para injetar seu próprio código para fazer o que quiser com seu site.

Sua suposição de que as informações do banco de dados não são confidenciais está errada. Vamos supor que seu site está hospedado no godaddy. godaddy AFAIK está usando servidores mysql dedicados que provavelmente só podem ser acessados de seus próprios servidores, mas se eu souber seus detalhes, como é difícil para mim criar uma conta godaddy e escrever um script que acesse seu banco de dados? No caso de bancos de dados locais, é mais difícil explorá-los, mas em servidores de hospedagem compartilhada você pode ter 100 sites compartilhando o servidor com você, você pode confiar que eles estão protegidos o suficiente para que o malvado não possa invadi-los e usá-los para atacar seu site?