wp-config.php e as constantes de segurança do WordPress

O arquivo wp-config.php do WordPress é o mais importante. Ele centraliza todas as informações sensíveis e de configuração, entre elas as constantes de segurança para blindar o WP.

As constantes de segurança refletem diferentes áreas da aplicação e do servidor. É importante conhece-las e saber das suas utilidades e o impacto que trarão.

Mas antes de tudo, você precisa reconhecer uma constante do PHP e por conseguinte do WordPress.

Sobre as contantes do PHP

As constantes são definidas como um identificador para um valor único. Elas são “parentes” das variáveis, mas tem suas particularidades, a saber:

• Seu valor não pode ser alterado durante a execução do script;
• Os nomes são case-sensitive, ou seja, “ESTE_NOME” é diferente de “Este_Nome”;
• Por uma convenção, os nomes das constantes são todos em maiúsculos;
• Ao contrário de uma variável, seu nome não começa com $ (cifrão);
• O nome válido de uma constante começa com letra ou sublinhado e seguido por letras, números ou sublinhados;
• As constantes são criadas através da função define().

Um exemplo de constante:

define( 'WP_DEBUG', false );

O impacto das constantes no WP

Sejam as constantes de segurança, ou não, elas impactarão todo o funcionamento da aplicação.

Como as constantes são alocadas no arquivo wp-config.php e esse é carregado primeiro do que qualquer outra coisa, as definições vão impactar todo o resto.

O valor de quase todas as constantes terão o valor de true ou false. Ou seja, de verdadeiro ou falso para habilitar ou desabilitar o recurso representado pela constante.

As constantes de segurança do WordPress

Neste artigo vamos conhecer e focar em importantes constantes que impactarão as seguintes áreas:

• Banco de dados;
• Chaves de segurança (Security Keys);
• Debug;
• Permissão de arquivos;
• Edição de arquivos de temas e plugins;
• SSL;
• Atualização.

Constantes para a base de dados

Embora as constantes destinada a base de dados não seja direcionada a segurança, é muito importante que os seus valores sejam seguros.

Principalmente a constante DB_PASSWORD que armazena a senha do usuário ao banco de dados em uso. Essa senha precisa ser forte.

Um exemplo de senha forte aplicada a constante.

define( 'DB_PASSWORLD', 'IQ&36c0Mubx)ANcTXIBTgxIhtvyl4y(l}]Dsfx?03;' );

Embora não seja uma constante, a variável $table_prefix, que por padrão tem o valor “wp_”, não deve conter o valor padrão e sim um valor diferente para evitar de termos os nomes da nossa tabela público, uma vez que o esquema do banco de dados do WordPress é conhecido.

Caso você esteja utilizando o prefixo “wp_”, saiba como altera-lo e definir um mais seguro.

As chaves de segurança do WordPress

As chaves de segurança do WordPress começaram a ser adicionadas à plataforma à partir da versão 2.6. Em seguida as Salts foram adicionadas.

Elas são conhecidas como Secret Keys (chaves secretas) e Salts. São utilizadas para dar mais segurança aos dados sensíveis dos usuários como senhas e cookies.

No total são oito chaves, sendo quatro de cada tipo. Ambas são armazenadas em constantes PHP, ou no banco de dados da plataforma em caso da ausência delas no arquivo.

Sobre o gerador de Secret Keys e Salts

O WordPress.org mantém um serviço que gera automaticamente essas chaves em formatos de constantes do WordPress para você simplesmente copiar e colar no wp-config.php.

Exemplo das chaves de segurança do WordPress gerado pelo serviço do WordPress.org

Debug, seguro.

Depurar uma aplicação se faz necessário durante o desenvolvimento do projeto ou na busca pelo entendimento de algum erro inesperado.

O WordPress possui um mecanismo próprio que lhe permite ativar ou desativar, definir a exibição, ou não, dos erros na tela e gravar essas informações em um arquivo chamado debug.log e fica localizado no diretório /wp-content.

Em ambientes de produção evite deixar o mecanismo ativado, exceto se houver necessidade. E considere blindar o arquivo debug.log com a permissão correta e bloqueio através do .htaccess para evitar a exposição das sensíveis informações nele armazenadas.

As constantes referentes ao Debug do WordPress são demonstradas abaixo em conjunto ao uso da função ini_set do PHP, utilizada para definir o valor de uma configuração.

É importante seu uso, além da constante do WP, para certificarmos que o comportamento desejado para a aplicação está alinhado com o comportamento do PHP configurado no servidor.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); 
@ini_set( 'log_errors', 'On' ); 
define( 'WP_DEBUG_DISPLAY', false ); 
@ini_set( 'display_errors', 'Off' );

As constantes de segurança aplicada aos arquivos

Todos os arquivos e pastas precisam ter sua correta permissão no servidor. Isso inclui o core do WordPress, os plugins e temas, ou seja, tudo. Arquivos e pastas.

Através do terminal é possível facilmente executar os seguintes comandos para essa finalidade.

find /path/to/wp-base-folder-install/ -type f ! -perm 644 -exec chmod 644 {} \;

find /path/to/wp-base-folder-install/ -type d ! -perm 755 -exec chmod 755 {} \;

O primeiro define a permissão 644 para os arquivos, enquanto o segundo a permissão 755 para os diretórios. Existem particularidades para alguns arquivos, portanto considere conhecer as permissões corretas para os arquivos e pastas do WordPress.

Em servidores Apache, e em algumas hospedagens pode ocorrer a execução do módulo suEXEC. Esse cenário combinado a atualização do WordPress pode comprometer a definição das permissões.

Existem duas constantes destinadas a essa tratativa. Uma para atuar sobre as permissões dos arquivos e outra para as pastas. São elas:

define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );

Evite a edição dos arquivos de temas e plugins

O painel do WordPress tem um editor que permite a edição dos arquivos de plugins e temas instalados.

É um recurso nativo e que por padrão vem ativado.

O problema desse recurso para a segurança está ligado a invasão ao painel através de um login e senha. A descoberta desses dados pode acontecer de várias formas, dentre elas o ataque de força bruta.

Uma vez que o atacante ganha acesso a área administrativa ele poderá fazer uso do recurso de edição de plugins e temas para injetar códigos maliciosos ou realizar qualquer alteração que comprometerá sua aplicação.

Com a constante DISALLOW_FILE_EDIT não será possível editar os arquivos de plugins e temas através da interface do WordPress. O seu valor precisa ser true.

define( 'DISALLOW_FILE_EDIT', true );

TLS / SSL, requerido.

O tempo em que todos os sites, independentemente da área de atuação ou tamanho, terão um certificado de segurança SSL implementado está batendo na porta.

É um caminho sem volta e temos assistido mobilizações por todos os lados para ajudar nessa implementação. A mais expressiva tem sido a Let’s Encrypt com a disponibilização do certificado gratuitamente.

Até a sua versão 4.0, o WordPress tinha duas constantes relacionados ao SSL, eram elas: FORCE_SSL_LOGIN e FORCE_SSL_ADMIN. Você deve desconsiderar a primeira que entrou em desuso.

A constante FORCE_SSL_ADMIN é utilizada para forçar o uso do mecanismo de login e todo painel administrativo do WordPress a utilizar o protocolo HTTPS e navegar os dados de forma criptografada. Incluindo, obviamente, dados sensíveis como senhas e cookies.

define( 'FORCE_SSL_ADMIN', true );

Tudo atualizado, sempre.

Manter o core, os plugins e temas atualizados é a regra mais básica e necessária para manter a segurança do WordPress e evitar ataques.

Você precisa ter o seguinte em mente: nenhum software será 100% seguro. É uma lei da segurança.

Mas quando uma brecha de segurança é descoberta, softwares comprometidos com a segurança dos seus usuários disponibilizam versões para correção, mas para isso é necessário que se atualize para a versão mais recente disponibilizada.

A constante WP_AUTO_UPDATE_CORE é uma dica fácil e rápida para lidar com os updates. No artigo as atualizações do WordPress e seus componentes de segurança detalho ainda mais essa questão.

O valor dessa constante podem ser três: true, false ou minor. Esse último é o padrão e informa que toda atualização minor será automaticamente aplicada. Utilizar um dos outros valores é algo mais avançado e você precisa conhecer os impactos e diferenças.

Proteção para o arquivo wp-config.php

Como percebido, o arquivo wp-config.php é o coração do WordPress. Todas as informações sensíveis, estratégicas e definições de comportamento da aplicação estão nele.

Você precisa considerar proteções para manter o arquivo wp-config.php seguro.

As três principais dicas são:

• Manter o arquivo um nível acima do diretório público;
• Usar a permissão 400 (readonly) ou 600 (para permissão de escrita);
• No arquivo .htaccess fazer uso de diretiva para proteção, se utilizar o Apache.

Conclusão

Considere proteger e ter um olhar diferente para com o arquivo wp-config.php. Considere mais ainda conhecer e fazer uso efetivo das constantes de segurança do WordPress para proteger o seu negócio.

Você pode imaginar que seria mais fácil se boa parte deles viessem ativadas por padrão. Eu também concordo. Mas é preciso ter a ciência que os casos de uso da plataforma são diversos.

E quando falo diverso, são diversos mesmo. Diferentes ambientes (desenvolvimento, homologação e produção); diferentes sistemas operacionais (Linux, Windows, Mac); diferentes servidores web (Apache, NGINX); diferentes combinações de sistemas e servidores e a lista continua.