Explicador de .htaccess

Uma configuração que mora na pasta

Um servidor web tem um arquivo de configuração principal que só o administrador pode editar. Numa hospedagem compartilhada esse administrador não é você, então o Apache oferece outra porta de entrada. É um arquivo de texto simples chamado .htaccess, colocado numa pasta do site, e as instruções dele valem para essa pasta e tudo o que está abaixo dela. Os servidores LiteSpeed leem o mesmo arquivo. O nginx não lê e o ignora por completo.

O servidor relê o arquivo a cada requisição, então uma mudança vale no instante em que você salva. Um erro também. Uma diretiva mal escrita e todas as páginas respondem com erro 500 até você corrigir a linha. Guarde uma cópia antes de cada edição.

Raramente você é o único autor. O WordPress escreve um bloco entre # BEGIN WordPress e # END WordPress, e plugins de cache, de segurança e de imagens acrescentam os próprios blocos marcados. O explicador reconhece as marcas de cerca de 25 deles, entre eles WP Rocket, LiteSpeed Cache, Wordfence e Really Simple SSL, e diz a quem pertence cada bloco.

Lendo uma regra de rewrite em voz alta

O mod_rewrite é onde a maioria das pessoas se perde. Veja este par:

RewriteCond %{HTTP_HOST} ^shop\.example\.com$ [NC]
RewriteRule ^products/(\d+)$ https://www.example.com/item?id=$1 [R=301,L]

Ele se lê como uma frase: “Se o host pedido for shop.example.com, em maiúsculas ou minúsculas, e o caminho for products/ seguido de dígitos, mande o visitante de forma permanente para o novo endereço com esses dígitos como id e pare o processamento.”

• Um RewriteCond é uma condição sobre uma variável do servidor. Ele só vale para o RewriteRule seguinte. Vários em sequência têm de ser todos verdadeiros, a menos que um termine com [OR].
• A primeira parte de um RewriteRule é uma expressão regular testada contra o caminho. Os parênteses capturam texto, e $1, $2 o reutilizam no destino. %1 reutiliza uma captura da última condição.

O que é sinalizado

Atacantes que conseguem acesso de escrita a um site muitas vezes vão direto ao .htaccess, porque poucas linhas ali bastam para redirecionar visitantes ou manter um script escondido acessível. O explicador compara cada linha com padrões vistos em infecções reais e lhe dá um de dois rótulos.

Suspeita, em vermelho:

• um redirecionamento para outro domínio que só vale para visitantes vindos de um buscador, ou só para celulares. O dono, que digita o endereço direto no computador, nunca o vê;
• um script PHP diferente servido aos robôs dos buscadores;
• AddHandler, AddType ou SetHandler fazendo arquivos de imagem ou de texto rodarem como PHP, ou arquivos comuns rodarem como scripts CGI;
• php_value auto_prepend_file ou auto_append_file carregando um arquivo antes ou depois de cada script, e allow_url_include;
• um bloco FilesMatch que nega todo arquivo .php, .py e .exe, seguido de um bloco que libera uma lista curta de arquivos PHP que não vêm com o WordPress.

Verificar, em laranja: linhas dentro do bloco do WordPress que não fazem parte das regras padrão dele, condições voltadas só para robôs ou referenciadores, a flag [P], uma página de erro hospedada em outro domínio, listagem de diretórios ligada, erros de PHP exibidos aos visitantes, um firewall de aplicação desativado, linhas com mais de 400 caracteres ou cheias de base64 ou de caracteres codificados, e caracteres invisíveis.

Dois erros de estrutura também são apontados, já que os dois causam um 500: um bloco como <IfModule> que nunca é fechado, e diretivas que só são permitidas na configuração principal do servidor, como DocumentRoot ou <VirtualHost>.

Se uma linha foi sinalizada e não foi você quem a escreveu

1. Baixe uma cópia do arquivo como prova antes de mexer em qualquer coisa.
2. Veja a data de modificação do arquivo e procure outros arquivos alterados no mesmo momento, sobretudo arquivos PHP em pastas de upload e os nomes citados nas regras sinalizadas.
3. Remova as linhas hostis e recarregue o arquivo alguns minutos depois. Se elas voltaram, um script no servidor está reescrevendo o arquivo e apagar linhas não vai bastar.
4. Troque as senhas da hospedagem, do FTP ou SSH, do banco de dados e do administrador do CMS, e atualize o CMS com todos os plugins e temas.
5. Use a consulta de site perigoso para ver se o site já está numa lista de bloqueio de navegador, e o rastreador de redirecionamentos para confirmar que os visitantes chegam onde deveriam.