Mover o wp-config para fora da raiz da web é realmente benéfico?

135

Uma das práticas recomendadas de segurança mais comuns atualmente parece estar movendo wp-config.phpum diretório mais alto que a raiz do documento do vhost . Eu realmente nunca encontrei uma boa explicação para isso, mas presumo que seja para minimizar o risco de um script malicioso ou infectado dentro da raiz da web de ler a senha do banco de dados.

Mas você ainda precisa permitir que o WordPress o acesse, então você precisa expandir open_basedirpara incluir o diretório acima da raiz do documento. Isso não acaba com todo o objetivo e também potencialmente expõe os logs do servidor, backups etc. aos atacantes?

Ou a técnica está apenas tentando impedir uma situação em wp-config.phpque seria mostrada em texto sem formatação para quem solicita http://example.com/wp-config.php, em vez de ser analisada pelo mecanismo PHP? Parece uma ocorrência muito rara e não superaria as desvantagens de expor logs / backups / etc a solicitações HTTP.

Talvez seja possível movê-lo para fora da raiz do documento em algumas configurações de hospedagem sem expor outros arquivos, mas não em outras configurações?


Conclusão: Depois de muitas idas e vindas sobre esse assunto, surgiram duas respostas que eu acho que deveriam ser consideradas as autoritativas. Aaron Adams faz um bom argumento a favor de mover o wp-config e chrisguitarguy faz um bom argumento contra ele . Essas são as duas respostas que você deve ler se for novo no tópico e não quiser ler a coisa toda. As outras respostas são redundantes ou imprecisas.

Ian Dunn
fonte
Realmente, não é necessário plugar sua escolha de respostas e rejeitar todas as outras respostas, dentro da sua pergunta. Como você pode ver abaixo, é para isso que serve o sistema de votação stackexchange, votando nas respostas que fazem sentido para as pessoas, enquanto os que fazem a pergunta devem estar usando o mecanismo de "resposta aceita" e seus próprios votos de cima / baixo.
Kzqai
6
Não faço isso em 99% das perguntas que fiz, mas achei que era apropriado nesse caso específico. Existem 8 respostas para a pergunta, algumas das quais bastante longas / complexas e outras com muitos votos positivos, apesar de conter informações imprecisas ou não adicionar nada à conversa. Eu acho que oferecer uma conclusão sem autoridade é útil para as pessoas que estão lendo o tópico pela primeira vez. Como sempre, os leitores são livres para se decidir; Só estou oferecendo minha opinião como OP.
Ian Dunn
1
@Kzqai: O "sistema de votação de troca de pilha" é um processo democrático, e os participantes geralmente 1) não sabem o que o OP está realmente pedindo ou tentando resolver e 2) não compreendem a validade de qualquer resposta em particular. Depois que as respostas chegam e os votos são emitidos, é mais do que útil que o OP esclareça as respostas que forneceram assistência. Afinal, o OP é o único que sabe, e eu gostaria que mais OPs o fizessem. Sim, as pessoas "votam nas respostas que fazem sentido para as pessoas", mas vamos deixar o OP ter a última palavra sobre o que faz sentido para ele.
Mac

Respostas:

127

Resposta curta: sim

A resposta a esta pergunta é um sim inequívoco , e dizer o contrário é completamente irresponsável .


Resposta longa: um exemplo do mundo real

Permitam-me fornecer um exemplo muito real, do meu servidor muito real, onde a movimentação para wp-config.phpfora da raiz da web impedia especificamente que seu conteúdo fosse capturado .

O inseto:

Dê uma olhada nesta descrição de um bug no Plesk (corrigido no 11.0.9 MU # 27):

O Plesk redefine o encaminhamento de subdomínio após sincronizar a assinatura com o plano de hospedagem (117199)

Parece inofensivo, certo?

Bem, aqui está o que eu fiz para acionar esse bug:

  1. Configure um subdomínio para redirecionar para outro URL (por exemplo, site.staging.server.compara site-staging.ssl.server.com).
  2. O plano de serviço da assinatura foi alterado (por exemplo, sua configuração PHP).

Quando fiz isso, o Plesk redefiniu o subdomínio para os padrões: exibir o conteúdo de ~/httpdocs/, sem intérpretes (por exemplo, PHP) ativos.

E eu não percebi. Por semanas.

O resultado:

  • Com wp-config.phpa raiz da web, uma solicitação para /wp-config.phpbaixar o arquivo de configuração do WordPress.
  • Com wp-config.phpfora da raiz da web, uma solicitação para /wp-config.phpbaixar um arquivo completamente inofensivo. wp-config.phpNão foi possível baixar o arquivo real .

Portanto, é óbvio que wp-config.phpsair da raiz da web traz benefícios de segurança autênticos no mundo real .


Como mudar wp-config.phppara qualquer local no seu servidor

O WordPress procurará automaticamente um diretório acima da instalação do WordPress para o seu wp-config.phparquivo; portanto, se foi para onde você o moveu, está pronto!

Mas e se você o mudou para outro lugar? Fácil. Crie um novo wp-config.phpno diretório WordPress com o seguinte código:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Certifique-se de alterar o caminho acima para o caminho real do seu wp-config.phparquivo realocado .)

Se você tiver algum problema open_basedir, basta adicionar o novo caminho à open_basedirdiretiva na sua configuração do PHP:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

É isso aí!


Separando argumentos em contrário

Todo argumento contra a wp-config.phpsaída da raiz da web depende de suposições falsas.

Argumento 1: se o PHP estiver desativado, eles já estão no

A única maneira de alguém ver esse conteúdo de [ wp-config.php] é contornar o intérprete de PHP do servidor ... Se isso acontecer, você já está com problemas: eles têm acesso direto ao seu servidor.

FALSO : O cenário que descrevi acima é resultado de uma configuração incorreta, não de uma invasão.

Argumento 2: Desabilitar acidentalmente o PHP é raro e, portanto, insignificante

Se um invasor tiver acesso suficiente para alterar o manipulador de PHP, você já está ferrado. Mudanças acidentais são muito raras na minha experiência e, nesse caso, seria fácil alterar a senha.

FALSO : O cenário que descrevi acima é o resultado de um bug em um software comum de servidor, afetando uma configuração comum de servidor. Isso dificilmente é "raro" (além disso, segurança significa se preocupar com o cenário raro).

WTF : Alterar a senha após uma invasão dificilmente ajuda se informações confidenciais foram coletadas durante a invasão. Realmente, ainda achamos que o WordPress é usado apenas para blogs casuais e que os invasores estão interessados ​​apenas em desfiguração? Vamos nos preocupar em proteger nosso servidor, não apenas em restaurá-lo depois que alguém entrar.

Argumento 3: Negar acesso a wp-config.phpé bom o suficiente

Você pode restringir o acesso ao arquivo via sua configuração de host virtual ou .htaccess- efetivamente limitando o acesso externo ao arquivo da mesma maneira que a movimentação fora da raiz do documento.

FALSO : Imagine sua padrões do servidor para um host virtual são: não PHP, não .htaccess, allow from all(dificilmente incomum em um ambiente de produção). Se sua configuração for de alguma forma redefinida durante uma operação de rotina - como, por exemplo, uma atualização do painel - tudo voltará ao seu estado padrão e você será exposto.

Se seu modelo de segurança falhar quando as configurações forem acidentalmente redefinidas para os padrões, você precisará de mais segurança.

WTF : Por que alguém recomendaria especificamente menos camadas de segurança? Carros caros não têm apenas fechaduras; eles também têm alarmes, imobilizadores e rastreadores de GPS. Se algo vale a pena proteger, faça o que é certo.

Argumento 4: acesso não autorizado a wp-config.phpnão é grande coisa

As informações do banco de dados são realmente as únicas coisas sensíveis em [ wp-config.php].

FALSO : As chaves de autenticação e os sais podem ser usados ​​em qualquer número de possíveis ataques de seqüestro.

WTF : Mesmo se as credenciais do banco de dados fossem a única coisa wp-config.php, você deve ter pavor de um invasor colocar as mãos nelas.

Argumento 5: Mover-se para wp-config.phpfora da raiz da Web torna um servidor menos seguro

Você ainda precisa permitir que o WordPress acesse [ wp-config.php], então você precisa expandir open_basedirpara incluir o diretório acima da raiz do documento.

FALSE : Assumindo que wp-config.phpestá dentro httpdocs/, basta movê-lo para ../phpdocs/e definido open_basedirpara incluir apenas httpdocs/e phpdocs/. Por exemplo:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Lembre-se de sempre incluir /tmp/, ou seu tmp/diretório de usuários , se você tiver um.)


Conclusão: os arquivos de configuração devem sempre estar sempre localizados fora da raiz da web

Se você se preocupa com segurança, sairá wp-config.phpda raiz da web.

Aaron Adams
fonte
1
Se você tem um bug no apache, linux ou no cérebro do administrador, você é um brinde em qualquer caso. No seu cenário, você não explica por que é mais provável que ocorra uma configuração incorreta na raiz do site e em qualquer outro local do servidor. A apache configurado incorretamente provavelmente pode acessar /../config.php tão fácil como /config.php
Mark Kaplun
1
Você não é "brinde em nenhum caso". É muito provável , e até demonstrável , que um bug resulte na redefinição da raiz da Web para o padrão; nesse caso, você não é "brindado" - wp-config.phppermanece em segurança. E é extremamente improvável - tanto que seja essencialmente impossível - que um bug resulte na raiz da web sendo arbitrariamente redefinida para o diretório exato em que você colocou o seu wp-config.php.
Aaron Adams
1
@IanDunn Na verdade, é fácil mudar wp-config.phppara um local arbitrário. Adicionei instruções à minha resposta; envolve apenas a criação de um manequim wp-config.phpno diretório WordPress, referenciando a localização do real.
Aaron Adams
3
Essa resposta é imediata. Minha empresa de hospedagem teve uma falha no conjunto de unidades. Quando tudo foi dito e feito, eles restauraram o sistema parcialmente. Acontece que eles usaram uma série de scripts cPanel / WHM para recriar arquivos httpd.conf que fizeram isso incorretamente. Felizmente, eu já tinha o wp-config.php fora da raiz do documento, mas se eu não tivesse o conteúdo estava lá para a captura. Sim raro, mas, como observado, os casos raros são com o que você precisa se preocupar. Além disso, afirmar que "pessoas de mente simples estariam perdidas" é uma desculpa ruim por ter menos segurança.
Lance Cleveland
1
Esse é um bom argumento, Aaron. Ainda estou um pouco cético pelas razões que mencionei neste e em outro tópico de comentários, mas você me convenceu de que ele tem mais mérito do que eu pensava inicialmente. No mínimo, se feito corretamente, não acho que vai doer nada. Eu ainda tenho um problema com o fato de que a maioria das pessoas que o promove não parece entender os motivos, e a maneira como o ensinam geralmente leva à exposição do diretório acima dos httpdocs, mas você ajudou a resolver esses problemas em sua resposta.
Ian Dunn
40

A principal coisa é que wp-config.phpcontém algumas informações confidenciais: nome de usuário / senha do banco de dados, etc.

Então a idéia: mova-a para fora da raiz do documento e você não precisa se preocupar com nada. Um invasor nunca poderá acessar esse arquivo de uma fonte externa.

Aqui está o problema, no entanto: wp-config.phpna verdade, nunca imprime nada na tela. Ele define apenas várias constantes usadas durante a instalação do WP. Portanto, a única maneira de alguém ver esse conteúdo é contornar o interpretador PHP dos servidores - eles obtêm.php arquivo seja renderizado como texto sem formatação. Se isso acontecer, você já está com problemas: eles têm acesso direto ao seu servidor (e provavelmente permissões de root) e podem fazer o que quiserem.

Vou seguir em frente e dizer que não há benefício em wp-configsair da raiz do documento de uma perspectiva de segurança - pelos motivos acima e :

  1. Você pode restringir o acesso ao arquivo via sua configuração de host virtual ou .htaccess - limitando efetivamente o acesso externo ao arquivo da mesma maneira que a movimentação fora da raiz do documento
  2. Você pode garantir que as permissões de arquivo sejam rígidas wp-config para impedir que qualquer usuário sem privilégios suficientes leia o arquivo, mesmo que obtenha acesso (limitado) ao seu servidor via SSH.
  3. Suas informações confidenciais, configurações do banco de dados, são usadas apenas em um único site. Portanto, mesmo que um invasor obtenha acesso a essas informações, o único site afetado seria a instalação do WordPress à qual o wp-config.phparquivo pertence. Mais importante, esse usuário de banco de dados tem apenas permissões para ler e gravar no banco de dados da instalação do WP e nada mais - sem acesso para conceder permissões a outros usuários. Em outras palavras, se um invasor obtém acesso ao seu banco de dados, é simplesmente uma questão de restaurar a partir de um backup (consulte o ponto 4) e alterar o usuário do banco de dados.
  4. Você faz backup com frequência. Muitas vezes, é um termo relativo: se você publicar 20 artigos todos os dias, é melhor fazer backup todos os dias ou a cada poucos dias. Se você postar uma vez por semana, o backup uma vez por semana provavelmente será suficiente.
  5. Você tem seu site sob controle de versão ( assim ), o que significa que, mesmo que um invasor obtenha acesso, é possível detectar facilmente alterações de código e revertê-las. Se um invasor tiver acesso awp-config , provavelmente já mexeu com outra coisa.
  6. As informações do banco de dados são realmente as únicas informações confidenciais wp-confige, como você é cuidadoso (consulte os pontos 3 e 4), não é grande coisa. Os sais e tal podem ser alterados a qualquer momento. A única coisa que acontece é que isso invalida os cookies dos usuários conectados.

Para mim, wp-configsair da raiz do documento cheira a segurança pela obscuridade - o que é um homem de palha.

chrisguitarguy
fonte
2
Sim, é isso que eu tenho pensado. Fico feliz em saber que não sou o único :) Gostaria de deixar a pergunta em aberto por mais um ou dois dias, caso alguém tenha um contra-argumento convincente, mas até agora essa parece ser a resposta certa para mim.
Ian Dunn
3
Correção menor: Não há benefício de segurança em mover o arquivo wp-config.php para fora da raiz do documento. Há outros benefícios, que não estão relacionados à segurança e que se aplicam apenas a configurações incomuns.
Otto
4
Apenas para desmembrar um possível mito - não é possível, algo pode dar errado no servidor - nesse caso, o código php é impresso na tela?
Stephen Harris
3
@IanDunn Mas as melhores respostas defendem movê-lo para fora dessa hierarquia em um separado, o que atende sua preocupação com os logs etc. Essa resposta não responde ao título da sua pergunta "está se movendo ... é realmente benéfico", apenas diz outras medidas de segurança são benéficas e tenta tranquilizá-lo para que não se preocupe com a segurança. Todo mundo pensa que sua casa é segura até ser assaltada. Depois disso, eles fazem um trabalho melhor. Algumas pessoas nunca são assaltadas, apesar de sua segurança ser baixa, mas isso não significa que é um bom conselho ter uma segurança mais baixa.
AndrewC
4
Esses são bons pontos, mas o meu maior problema é que eles são argumentos corretivos, não preventivos. A maioria deles fala sobre como não é um grande negócio, porque A) você assume que alguém manipulou o usuário db corretamente e B) possui backups. O que acontece quando você usa algo como woocommerce ou armazena informações confidenciais em seu banco de dados? Então você está ferrado.
Goldentoa11
25

Eu acho que Max é uma resposta experiente, e esse é um lado da história. O Codex do WordPress tem mais conselhos :

Além disso, certifique-se de que apenas você (e o servidor da Web) possam ler esse arquivo (geralmente significa uma permissão 400 ou 440).

Se você usa um servidor com .htaccess, pode colocá-lo nesse arquivo (na parte superior) para negar acesso a qualquer pessoa que esteja navegando nele:

<files wp-config.php>
order allow,deny
deny from all
</files>

Observe que a configuração das permissões 400 ou 440 no wp-config.php pode impedir que os plugins os gravem ou modifiquem. Um caso genuíno, por exemplo, seria o plug-in de cache (cache total do W3, super cache do WP etc.). Nesse caso, eu usaria 600 (a permissão padrão para arquivos no /home/userdiretório).

wsou eu
fonte
5
Max's é a resposta. +1 para ele. Estou simplesmente tentando estendê-lo.
its_me
1
Aahan Krish, você atingiu o alvo. Obrigado pela adição.
Max Yudin
Portanto, se você usar o htaccess para negar solicitações HTTP ao wp-config.php, isso não terá o mesmo resultado que movê-lo para fora da raiz do documento, mas sem expor logs / backups / etc?
11118 Ian
4
@IanDunn Depende do que é a raiz do documento: (1) Se o wordpress estiver hospedado em um diretório public_html, mover para wp-config.phpfora do diretório significa que ele estará no public_htmldiretório. Nesse caso, você terá que usar as regras htaccess para negar solicitações HTTP para wp-config.php. (2) Se o WordPress estiver instalado diretamente no public_htmldiretório, um nível acima => você o moverá para o /home/userdiretório. Nesse caso, você está bastante seguro, pois o arquivo está fora da raiz do documento. Você ainda pode definir as permissões do arquivo para 600 (ou até 440 ou 400).
its_me
@IanDunn Como eu disse, esse é meu entendimento básico e não sou especialista em segurança. :)
its_me
17

Alguém nos pediu para brilhar, e eu responderei aqui.

Sim, existem benefícios de segurança ao isolar o wp-config.php do diretório raiz do seu site.

1- Se o seu manipulador PHP for quebrado ou modificado de alguma forma, suas informações de banco de dados não serão expostas. E sim, vi isso acontecer algumas vezes em hosts compartilhados durante as atualizações do servidor. Sim, o site será quebrado durante esse período, mas suas senhas permanecerão intactas.

2- As melhores práticas sempre recomendam isolar os arquivos de configuração dos arquivos de dados. Sim, é difícil fazer isso com o WordPress (ou qualquer aplicativo da Web), mas movê-lo para cima faz um pouco de isolamento.

3- Lembre-se da vulnerabilidade do PHP-CGI, onde qualquer um poderia passar os? -S para um arquivo e visualizar a fonte. http://www.kb.cert.org/vuls/id/520827

No final, esses são pequenos detalhes, mas ajudam a minimizar os riscos. Especialmente se você estiver em um ambiente compartilhado, onde qualquer pessoa possa acessar seu banco de dados (tudo o que precisa é de um usuário / senha).

Mas não deixe que pequenas distrações (otimizações prematuras) cheguem ao que é realmente necessário para obter um site adequadamente seguro:

1- Mantenha-o sempre atualizado

2- Use senhas fortes

3- Restrinja o acesso (via permissões). Temos um post sobre isso aqui:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

obrigado,

Sucuri
fonte
Ei pessoal, obrigado por adicionar seus pensamentos. Acho que já atingimos a maioria desses pontos nas outras respostas e nos comentários deles. 1) Sim, isso é possível, mas raro; 2) Sim, isso tem benefícios, mas são mínimos; 3) Sim, isso é possível, mas é improvável que esse tipo de vulnerabilidade ocorra novamente, e protegê-lo é como brincar de sacanagem, ou fazer as pessoas tirarem os sapatos nos aeroportos porque alguns idiotas esconderam uma bomba em sua sapato uma vez. É reacionário e improvável que tenha benefícios futuros.
11118 Ian
Nas várias discussões, a questão foi refinada de "Existem benefícios?" para "Ok, existem alguns benefícios, mas eles superam os riscos?" O principal risco ao qual estou me referindo é o fato de que você precisa expandir o escopo do openbase_dir para permitir que o PHP acesse scripts fora da raiz da web. Muitas configurações de hospedagem - incluindo aquelas que usam muito o Plesk - armazenam logs, backups, áreas de FTP privadas que deveriam estar isoladas da raiz da web etc. no diretório acima da raiz da web. Portanto, conceder acesso ao PHP a esse diretório pode ser uma vulnerabilidade séria.
11114 Ian
15

Definitivamente sim.

Quando você move o wp-config.php para fora do diretório público, você o protege da leitura usando o navegador quando o manipulador de php é maliciosamente alterado (ou acidentalmente!).

A leitura do login / senha do banco de dados é possível quando o servidor dificilmente está infectado por uma falha do administrador coxo. Carregue uma multa ao administrador e obtenha um host de servidor melhor atendido e mais confiável. Embora isso possa ser mais caro.

Max Yudin
fonte
4
Se um invasor tiver acesso suficiente para alterar o manipulador de PHP, você já está ferrado. Mudanças acidentais são muito raras na minha experiência e, nesse caso, seria fácil alterar a senha. À luz dessas coisas, você ainda acha que vale a pena expor logs / backups / etc por causa do open_basedirescopo expandido ?
11111 Ian Dunn
1
Eu nunca tive -rwxacesso a diretórios mais altos do public_htmlque nunca open_basedir. Meus logs estão em um diretório separado, assim como os backups. Eu acho que é isso que todos os hosts compartilhados têm.
Max Yudin
Hosts variam muito; não há estrutura de diretório padrão. O Plesk (um dos painéis de controle mais populares para hosts compartilhados) coloca logs em /var/www/vhosts/example.com/statistics/logs e a raiz do documento é /var/www/vhosts/example.com/httpdocs. Mover wp-config.php para /var/www/vhosts/example.com/wp-config.php exigiria dar aos scripts acesso a todo o diretório example.com.
Ian Dunn
Por curiosidade, onde estão seus logs e backups armazenados, se não estiverem no diretório do domínio? Eles são acessados ​​através de um painel de controle ou algo assim?
Ian Dunn
1
Sim, através de um painel de controle.
precisa
8

Eu só quero esclarecer, por uma questão de argumento, que mover o arquivo wp_config.php não significa necessariamente que você precise movê-lo apenas para o diretório pai. Digamos que você tenha uma estrutura como / root / html, em que o html contenha a instalação do WP e todo o seu conteúdo HTML. Em vez de mover o wp_config.php para / root, você pode movê-lo para algo como / root / secure ... que está fora do diretório html e também não no diretório raiz do servidor. Obviamente, você precisaria garantir que o php também possa ser executado nesta pasta segura.

Como o WP não pode ser configurado para procurar o wp_config.php em uma pasta irmã como / root / secure, você precisa executar uma etapa adicional. Deixei o wp_config.php em / root / html e recortei as partes sensíveis (login no banco de dados, salt, prefixo da tabela) e as movi para um arquivo separado chamado config.php. Então você adiciona o PHPinclude comando ao seu wp_config.php, assim:include('/home/content/path/to/root/secure/config.php');

Isso é essencialmente o que eu fiz na minha configuração. Agora, com base na discussão acima, ainda estou avaliando se é necessário ou mesmo uma boa ideia. Mas eu só queria acrescentar que a configuração acima é possível. Ele não expõe seus backups e outros arquivos raiz e, desde que a pasta segura não esteja configurada com seu próprio URL público, não poderá ser navegada.

Além disso, você pode limitar o acesso à pasta segura criando um arquivo .htaccess com:

order deny,allow
deny from all
allow from 127.0.0.1
Michael
fonte
Hey Michael, obrigado por compartilhar isso. Você já experimentou em um ambiente real para verificar se funciona? Eu acho que a open_basedirdirectiva tem toda uma árvore , de modo a fim de acessar /root/securea partir /root/html, você tem que definir open_basedira /root.
Ian Dunn
Para que sua ideia funcione, acho que você precisará configurar a estrutura de diretórios como /root/httpdocs/config/accessible, onde httpdocscontém logs, backups, etc; configdetém wp-config.php, e accessibledetém WordPress e todo o conteúdo. Você precisaria modificar a configuração do vhost, etc, para remapear a raiz do documento accessible. No entanto, não vejo nenhum benefício em negar solicitações HTTP para o wp-config na configuração padrão.
Ian Dunn
1
De acordo com php.net/manual/pt/ini.core.php#ini.open-basedir : "No Windows, separe os diretórios com ponto e vírgula. Em todos os outros sistemas, separe os diretórios com dois pontos. Como módulo Apache, Os caminhos open_basedir dos diretórios pai agora são herdados automaticamente. " Assim, você pode definir vários diretórios, não sendo necessário que eles estejam em uma única árvore.
Michael
Acabei de testar isso e parece que você está certo. Ainda não tenho certeza de qual benefício de segurança isso tem sobre simplesmente negar o acesso ao arquivo via Apache.
Ian Dunn
@IanDunn dirigida bem em resposta Aaron Adams'
AndrewC
4

Existem muitos temas e plugins mal escritos por aí que permitem aos atatckers injetar código (lembre-se do problema de segurança com o Timthumb). Se eu fosse um invasor, por que devo procurar o wp-config.php? Simplesmente injete este código:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Você pode tentar ocultar o seu wp-config.php. Desde que o WordPress torne todas as informações confidenciais acessíveis em todo o mundo, não há nenhum benefício em ocultar o wp-config.php.

A parte ruim do wp-config.php não é que ele contém dados confidenciais. A parte ruim é definir os dados confidenciais como uma constante acessível global.

Atualizar

Quero esclarecer os problemas com define() e por que é uma má idéia definir dados confidenciais como uma constante global.

Existem várias maneiras de atacar um site. A injeção de script é apenas uma maneira de atacar um site.

Supondo que o servidor tenha uma vulnerabilidade que permite que um invasor acesse um despejo de memória. O invasor encontrará na memória despejar todos os valores de todas as variáveis. Se você definir uma constante global acessível, ela deverá permanecer na memória até o final do script. Criando uma variável em vez de uma constante, há uma boa chance de que o coletor de lixo substitua (ou libere) a memória depois que a variável não for mais necessária.

Uma maneira melhor de proteger dados confidenciais é excluí-los imediatamente após usá-los:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

Depois de usar os dados confidenciais, a atribuição a nullsubstituirá os dados na memória. Um invasor precisa obter o despejo de memória no momento em que $db_concontém os dados confidenciais. E esse é um período muito curto no exemplo acima (se a classe Database_Handler não salvar uma cópia dela).

Ralf912
fonte
Esta resposta não aborda diretamente a questão. Qualquer autor de plug-in pode ter um dia de campo com o WordPress se o convencer a instalar o código e tiver uma intenção maliciosa. Não é diferente de instalar voluntariamente um vírus no seu sistema. Este argumento para não mover o wp-config.php é inútil. É como dizer que instalar intencionalmente um carro bomba no seu carro torna inútil definir o alarme do carro. Tecnicamente verdade, mas o WTF?!?
Lance Cleveland
2
Não, não é inútil. A questão é: Posso proteger a conta do banco de dados ocultando o wp-config.php. E a resposta é clara: não. É o mesmo que se você perguntasse 'Posso proteger meu carro contra carros-bomba com um alarme de carro?' Não há outro benefício ocultando o wp-config como para proteger o acesso ao banco de dados ou o acesso ftp. Ambos estão no escopo global. Tenho certeza de que existem mais maneiras de os invasores obterem acesso a vars globais sem injetar código.
Relf912 6/12/12
Não vejo "posso proteger a conta do banco de dados ocultando o wp-config.php" na pergunta original. A pergunta original era "faz sentido mover o wp-config.php". A resposta é absolutamente sim, IMO. É como perguntar se você deve trancar a porta da frente quando sair. Dizer "alguém pode facilmente quebrar uma janela e entrar de qualquer maneira, então por que se preocupar" não responde ao ponto fundamental da pergunta. Na IMO, a pergunta feita foi a seguinte: "Vale a pena o esforço extra de mover o wp-config.php? QUALQUER benefício para fazer isso?". Sim. No mínimo, mantém de fora os hackers preguiçosos.
Lance Cleveland
2
Uma das práticas recomendadas de segurança mais comuns ... Você perdeu um ponto muito (muito, muito) importante: Para o que um invasor está interessado? E é não como você estilo seu wp-config.php. Um invasor está interessado nos valores que você definiu em seu wp-config. Agarrando seu exemplo com a porta da frente: Ocultar o seu wp-config é o mesmo que se você trancasse a porta da frente, mas armazene todo o seu ouro desprotegido no jardim. Todos os valores definidos no wp-config são definidos globalmente . Portanto, todos eles são acessíveis fora do wp-config. Mesmo se você ocultar sua wp-config, os valores ainda estarão presentes.
Relf912
1
Acho que aqueles que argumentam a favor de movê-lo estão tentando se proteger de cenários em que o wp-config.php possa ser exibido em texto sem formatação por meio de uma solicitação HTTP, em vez de cenários em que possa ser exposto a outro código PHP em execução no host.
Ian Dunn
-1

Além dos benefícios de segurança, ele também permite que você mantenha sua instância do WordPress sob controle de versão e mantenha os arquivos principais do WordPress como um submódulo / externo. Foi assim que Mark Jaquith configurou seu projeto WordPress-Skeleton. Consulte https://github.com/markjaquith/WordPress-Skeleton#assumptions para obter detalhes.

Emzo
fonte
8
Ele tem a configuração na raiz do documento, não fora dela, portanto não é relevante para esta questão. A técnica sobre a qual a pergunta foi especificada especifica que você mova wp-config.phpum diretório acima da raiz do documento do vhost , não apenas um diretório acima da pasta de instalação do WordPress. O ponto principal é tirá-lo da pasta que pode ser lida por solicitações HTTP.
111112 Ian Ian Dunn