Vale lembrar que as técnicas utilizadas para aumentar a segurança no WordPress com .htaccess possuem muito eficácia, pois inserindo as instruções na pasta raiz do servidor, as medidas passam a servir para todos os arquivos ali inseridos; incluindo suas subpastas.
Antes de realizar grandes mudanças em seu arquivo .htaccess, esteja ciente que após edições equivocadas eventualmente o site pode retornar erro HTTP 500 e deixar de funcionar. Em outros casos é possível acontecer de sua URL conter o endereço intercalado a /index.php/ mesmo após ter sido atualizadas as opções de reescrita.
Em ambos os casos, tenha sempre a mão uma cópia das instruções originais do .htaccess, apenas com os códigos do WordPress; como segue abaixo:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /meu-site/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /meu-site/index.php [L]
</IfModule>
A instrução /meu-site/ diz respeito ao diretório onde o WordPress encontra-se instalado. Em grande parte dos casos a instalação é feita na raiz do servidor; nessa situação o código .htaccess correto será:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Sobre o problema com o arquivo index.php, saiba que esse arquivo fica na pasta raiz da instalação do WordPress e é chamado toda vez que o site é requisitado. A incorporação dele no endereço das páginas, posts e demais conteúdos se dá em razão de configurações do servidor de hospedagem (caso o problema persista, mesmo após resetar os códigos, entre em contato com o serviço que você contratou).
Um modo muito eficaz para aprimorar a segurança no WordPress é impedir que os arquivos do sistema, em especial os códigos PHP, sejam acessados e possam ser executados fora do escopo do WordPress.
Impedir o acesso direto a arquivos do tipo PHP contribui para prevenção de ataques possíveis de serem realizados mediante brechas nas permissões do servidor.
O WordPress possui como boa prática inserir em todos os diretórios de sua estrutura de pastas um arquivo index.php vazio. Isso impede que o servidor faça a listagem dos arquivos do diretório em questão.
Faça um teste em seu WordPress, acesse http://seuwordpress.com.br/wp-content/. Você verá provavelmente uma tela em branco (resultado do arquivo index.php do WordPress inserido nessa pasta).
Agora tente acessar http://seuwordpress.com.br/wp-content/uploads/. O quê aconteceu?
Caso você tenha visto uma tela parecida com essa acima, você tem um grande problema a resolver. Isso porquê além de mostrar o seu conteúdo para as pessoas, isso pode representar que o servidor não possui tanto cuidado com a segurança.
Resolva esse problema inserindo, dentro do arquivo .htaccess (pode ser antes da instrução #BEGIN WordPress), a seguinte linha:
Options All -Indexes
Feito o bloqueio da listagem de diretórios, agora você precisa bloquear o uso indevido dos arquivos do WordPress. A estrutura de pastas do WordPress contém as pastas:
Começando pela pasta wp-includes, faça o bloqueio dos códigos PHP inserindo dentro do .htaccess as seguintes instruções:
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
Em continuidade, a próxima pasta a ser protegida será a wp-admin. Nesse caso o bloqueio deve ser feito com cuidado pois alguns arquivos dessa pasta precisam necessariamente ser executados individualmente; como é o caso do wp-admin/admin-ajax.php usado para as requisições AJAX no WordPress.
Por isso as instruções do .htaccess serão para impedir que os arquivos dessa pasta sejam executados por outro domínio. Desse modo a segurança do WordPress fica garantida pois apenas os códigos do seu servidor podem transferir dados via POST aos arquivos da pasta wp-admin.
RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^http://(.*)?seuwordpress.com.br/ [NC]
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteRule ^(.*)$ - [F]
No caso dos Plugins, a prevenção a ser feita será impedir que qualquer arquivo do tipo PHP seja executado individualmente. Como os Plugins necessitam que o WordPress tenha sido carregado para executar como esperado, não faz sentido fazer a chamada dos arquivos de maneira isolada.
RewriteRule wp-content/plugins/(.*\.php)$ - [R=404,L]
No entanto talvez algum plugin que você tenha feito não siga essa estrutura de funcionamento e você faça chamadas diretas aos arquivos PHP; você pode então permitir apenas o acesso aos arquivos desse seu Plugin. Veja abaixo no exemplo a exceção da regra para rodar os arquivos do Plugin Query Monitor.
RewriteCond %{REQUEST_URI} !^/wp-content/plugins/query-monitor/
Caso você faça a chamada de apenas um ou poucos arquivos do seu Plugin de modo direto, você também pode optar por criar exceções aos arquivos e não ao diretório completo. Abaixo o exemplo liberando o acesso ao arquivo index.php do Plugin Kirki.
RewriteCond %{REQUEST_URI} !^/wp-content/plugins/kirki/index.php
Para os Temas o controle do acesso direto aos arquivos PHP ocorre do mesmo modo que os Plugins. Basta que você troque o endereço da pasta de Plugins para a pasta de Temas e no caso das exceções, especificar qual pasta ou arquivo pode ser acessado via endereço absoluto.
RewriteCond %{REQUEST_URI} !^/fotologia-wp/wp-content/themes/meu-tema/
RewriteCond %{REQUEST_URI} !^/fotologia-wp/wp-content/themes/meu-tema/arquivo-permitido.php
RewriteRule wp-content/themes/(.*\.php)$ - [R=404,L]
A proposta é ter controle sobre os arquivos da pasta wp-content inteira. Essa medida de segurança requer a criação de um novo arquivo .htaccess a ser inserido dentro da pasta wp-content. Dentro dele insira apenas as seguintes intruções:
Order Allow,Deny
Deny from all
<FilesMatch "\.(css|js|html|jpg|jpeg|png|gif)$" >
Allow from all
</FilesMatch>
Ao fazer isso você informa ao servidor que apenas os arquivos com as extensões previstas podem ser acessados diretamente via caminho absoluto (ex: http://seuwordpress.com.br/wp-content/pagina.html).
Lembrando que esse arquivo .htaccess não se trata do arquivo na raiz do servidor e portanto não traz as instruções da estrutura de reescrita responsável pelos links permanentes do WordPress. O código é apenas esse mostrado acima mesmo.
O arquivo wp-config.php é um arquivo muito importante para o WordPress e por isso contém informações muito sensíveis (conexão com banco de dados, chaves secretas, prefixo das tabelas etc). Em geral um atacante não conseguiria acessar essas informações pois mesmo que ele tente acessar esse arquivo diretamente, o servidor web iria tentar executar o arquivo .php e retornar alguma saída.
Contudo caso algum problema aconteça com o módulo PHP do servidor, os arquivos .php no lugar de serem executados serão enviados para download aos usuários. Existem também outros cenários em que o atacante pode obter o arquivo wp-config.php. Nos últimos meses foram descobertas diversos plugins com brechas que permitiam entre outras coisas a obtenção do arquivo wp-config.php.
Para se prevenir em caso desses possíveis erros é possível bloquear o acesso ao arquivo wp-config.php via .htaccess, para isso basta colocar o código abaixo no final do conteúdo do arquivo .htaccess da sua instalação do WordPress.
<files wp-config.php>
order allow,deny
deny from all
</files>
Uma vez que você aplicou essa medida de segurança em seu WordPress, ao tentar acessar qualquer arquivo cuja extensão não seja permitida, o visitante receberá a tela de erro 403 (Acesso proibido). Por padrão o servidor possui uma tela para esse tipo de erro; pode ser uma tela personalizada ou alguma mensagem do tipo:
A fim de permitir que você faça essa personalização por conta própria, informando um arquivo específico para ser executado nesses casos; você pode informar no seu .htaccess:
ErrorDocument 403 /erros/acesso-proibido.html
Note que foi referenciado um arquivo específico, no entanto você pode direcionar esse acesso a uma URL do seu WordPress, se assim preferir.
ErrorDocument 403 http://seuwordpress.com.br/acesso-proibido/
E o mesmo pode ser feito para os outros tipos de erros de acordo com o código do situação do HTTP:
ErrorDocument 400 /erros/requisicao-invalida.html
ErrorDocument 404 /erros/pagina-nao-encontrada.html
ErrorDocument 500 /erros/erro-interno-do-servidor.html
Proteja seu WordPress do Hotlink. Um hotlink é um link feito para arquivos hospedados em outro servidor. O grande problema desse tipo de linkagem é o consumo de recursos do servidor onde o arquivo encontra-se hospedado.
Imagine que você possui em seu site uma imagem muito bem produzida e posicionada nas buscas. Caso algum outro site faça uso dessa imagem inserindo apenas a referência da imagem ao seu servidor, toda requisição feita nesse outro site vai consumir seus recursos. Em código seria algo como:
// seu site está hospedado em http://seuwordpress.com.br/
// o código abaixo está em http://outrosite.com.br/
<img src="http://seuwordpress.com.br/imagem.jpg">
Isso pode acontecer para todo tipo de arquivo, e quanto mais ‘pesado’ o arquivo, mais consumo do seu servidor a cada requisição feita através de hotlinks.
Previna esse tipo de problema inserindo algumas novas instruções ao arquivo .htaccess na raiz do servidor.
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?seuwordpress.com.br [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]
As instruções permitirão o acesso apenas se a requisição for feita pelo seu próprio site. Você talvez queira abrir algumas excessões, como por exemplo permitir que as imagens sejam indexadas por algum outro site seu, site parceiros ou mesmo pelo Google Images. Nesse caso, crie novas excessões, além da exceção ao seu próprio domínio, do seguinte modo:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?seuwordpress.com.br [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(.*\.)?google\..* [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]
Uma variação do uso dessa técnica é ao invés de apresentar a tela de acesso proibido a tentativas de hotlink é exibir um arquivo vazio ou alguma imagem com informações de copyright. Assim, todas as requisições não permitidas de hotlink mostrarão esse conteúdo.
RewriteRule \.(jpg|jpeg|png|gif)$ http://seuwordpress.com.br/imagem-vazia.gif [NC,R,L]
Cuidados com a segurança no WordPress são essenciais para a manutenção do seu projeto em perfeito funcionamento. Entre os diferentes tipos de ataques que um site pode sofrer, o Script Injection pode causar sérios danos ao seu site.
Esse ataque se caracteriza pela inserção de códigos (“injeção de scripts”) específicos que permitem tomar o controle de todo sistema; desde realizar certos processos do site sem a devida autorização a infectar os códigos com rotinas de SPAM, sobrescrita do site ou somente para “derrubar o servidor” mesmo.
As tentativas de Script Injection podem ocorrer – entre outros meios – via passagem de parâmetros na URL do site ou via preenchimento de formulários. Por isso é muito importante que seus Temas e Plugins possuam o devido tratamento das transferências de informações entre uma página e outra, entre um arquivo e outro.
Trate as informações de input (variáveis de requisições GET e POST), faça a validação e sanitização dos dados antes de utilizá-los em seu código ou armazená-los em banco de dados.
Além desse cuidado essencial de preparar o seu código para se comportar bem, mesmo diante de ameaças; faça uso do .htaccess na raiz do seu servidor para que de nenhuma forma esses códigos mal intencionados possam trafegar em meio ao seu WordPress.
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]
Um Erro de HTTP do tipo 403 (Acesso Proibido) será apresentado caso exista alguma referência a tag <script> dentro da requisição ou caso tenha ocorrido uma tentativa de alterar as variáveis GLOBALS ou _REQUEST do PHP.