Uma auditoria de segurança é uma revisão escrita do seu site WordPress. Olho para os plugins e temas, para as contas de utilizador, para a configuração do wp-config.php e do servidor, para os cabeçalhos HTTP, para as cópias de segurança e para os registos. No fim recebe um documento com o que encontrei, ordenado por prioridade, e com a forma de corrigir cada ponto.
Faço a revisão uma vez, com âmbito fechado. Não ofereço vigilância contínua nem testes de intrusão: leio código WordPress desde 2006 e é isso que a auditoria aproveita.
Quem faz a auditoria?
A WPPoland é Mariusz Szatkowski, programador WordPress desde 2006, com sede em Gdynia, na Polónia. Trabalho sozinho: faço cada auditoria pessoalmente e não passo os seus acessos a ninguém. Mantenho 30 plugins gratuitos no WordPress.org, por isso conheço bem o lado de quem escreve os plugins que depois audito.
O que inclui a auditoria?
- Plugins e temas: versões, vulnerabilidades publicadas, plugins abandonados e leitura do código dos plugins personalizados.
- Contas: administradores, Application Passwords, segundo fator e contas que ninguém reconhece.
- Configuração: constantes do
wp-config.php, permissões de ficheiros, execução de PHP emuploads, XML-RPC e REST. - Servidor: cabeçalhos de segurança HTTP, TLS e versão do PHP.
- Cópias de segurança: onde estão, há quanto tempo e se alguém já testou uma restauração.
- Registos: vestígios de tentativas de acesso, quando o alojamento os guarda.
Como decorre o trabalho?
Remotamente, a partir de Gdynia, uma hora à frente de Lisboa. Tudo fica por escrito: e-mail, documento e, quando há código, repositório. Antes do primeiro acesso assinamos um acordo de subcontratação nos termos do artigo 28.º do RGPD.
Quanto custa?
O preço é individual e depende do tamanho do site, do número de plugins, de haver uma loja WooCommerce e de existir ou não uma infeção ativa. Recebe uma proposta escrita depois de me descrever o site. A remoção de malware e as correções são orçamentadas à parte.
Como são atacados os sites WordPress
O núcleo do WordPress raramente é a porta de entrada. As intrusões chegam pelos plugins e temas, e quase sempre com os mesmos padrões.
Vulnerabilidades em plugins
- Endpoints REST registados com
permission_callback => '__return_true', acessíveis sem sessão. - XSS armazenado através de shortcodes que imprimem
$_GETou post meta semwp_kses_post(). - Upload de ficheiros por handlers AJAX que saltam
wp_check_filetype_and_ext(). - Escalada de privilégios num formulário de definições que grava opções sem verificar
current_user_can().
Cruzo os plugins instalados com as bases públicas da WPScan e da Patchstack e depois leio o código dos que recebem dados dos visitantes. Uma base de CVE só lista o que já foi reportado. O código gerado por ferramentas de IA tende a ter exatamente estas falhas, nonces em falta e $_GET sem sanitização; se o seu site foi construído assim, veja também a recuperação de sites feitos por IA.
Enumeração de utilizadores
?author=1 redireciona para /author/<slug>/ e revela o nome de login. O endpoint /wp-json/wp/v2/users faz o mesmo em instalações que nunca o restringiram. Num site revisto, ambos devolvem 404 ou uma lista vazia para quem não tem sessão.
XML-RPC e system.multicall
/xmlrpc.php aceita system.multicall, que permite testar muitas palavras-passe num só pedido POST. Se o site não usa a app móvel do WordPress nem o Jetpack, desativo o XML-RPC; se usa, restrinjo-o no servidor ou na firewall do alojamento.
O que verifico, passo a passo
| Passo | O que faço | Ferramentas |
|---|---|---|
| 1. Verificação externa | Listas negras (Google Safe Browsing), cabeçalhos HTTP, TLS, versão exposta do WordPress | Sucuri SiteCheck, curl |
| 2. Integridade dos ficheiros | Comparação do núcleo e dos plugins com os checksums oficiais, procura de backdoors | WP-CLI (wp core verify-checksums, wp plugin verify-checksums) |
| 3. Plugins e temas | Plugins abandonados, vulnerabilidades publicadas, leitura do código personalizado | WPScan, Patchstack, leitura manual |
| 4. Base de dados | Administradores a mais, opções alteradas, links de spam injetados | WP-CLI, SQL |
| 5. Registos do servidor | access.log e error.log à procura de tentativas e acessos com sucesso | SSH, grep |
| 6. Cópias de segurança | Localização, retenção e um teste de restauração numa cópia | Painel do alojamento, WP-CLI |
Infeções que encontro com mais frequência
Spam SEO em japonês ou de farmácia. Milhares de páginas injetadas aparecem nos resultados do Google com caracteres estranhos. O Google pode marcar o site e a recuperação nos resultados demora semanas depois da limpeza.
Redirecionamentos maliciosos. O visitante é enviado para sites de apostas ou pornografia, muitas vezes só em telemóveis ou a partir de certos países, o que torna o problema difícil de ver para quem gere o site. A alteração costuma estar no header.php do tema ou no .htaccess.
Backdoors PHP. Ficheiros escondidos em wp-content/uploads ou com nomes parecidos com os do núcleo, que devolvem o acesso ao atacante mesmo depois de mudar as palavras-passe.
O administrador persistente. Um plugin vulnerável permite criar uma conta com a função administrator e um nome inocente como «Suporte». Restaurar a cópia da semana passada não resolve se a conta já lá estava. Por isso comparo wp_users e wp_usermeta com a última cópia limpa em vez de confiar na lista do painel.
Chaves num repositório público. Um .env com credenciais de SMTP ou de um gateway de pagamento publicado no GitHub. Verifico .env, .env.backup e qualquer ficheiro dentro da raiz web que contenha DB_PASSWORD ou padrões _KEY.
Plugins de IA que executam código
Há uma classe de risco que um scanner de vulnerabilidades não vê: plugins que dão de propósito a um agente de IA a execução de PHP, consultas à base de dados ou operações em ficheiros, através de MCP, CLI ou webhook. Não há CVE para registar, porque a função está documentada. O risco passa para a autenticação e para quem guarda as chaves.
Em cada auditoria acrescento cinco verificações:
- Inventário dos plugins que declaram execução de código, acesso à base de dados ou operações em ficheiros por IA.
- Para cada um: se o endpoint exige autenticação e se está acessível a partir da Internet.
- Onde estão as credenciais (
wp-config.php, tabela de opções, variáveis de ambiente) e quem as consegue ler. - Se as operações ficam registadas de forma que permita reconstruir o que aconteceu.
- A minha recomendação por omissão: fora da produção; em staging só com allowlist de IP.
Classifico estes achados ao lado das backdoors em uploads, porque o efeito prático é o mesmo: alguém de fora pode alterar ficheiros e dados.
Hardening que recomendo no relatório
Cada recomendação do documento traz o motivo e o comando ou a linha de configuração. As mais frequentes:
wp-config.php:DISALLOW_FILE_EDITpara desligar o editor de código no painel,FORCE_SSL_ADMIN, ficheiro com permissões restritas e, quando o alojamento o permite, fora da raiz web. As chaves de API de pagamentos (Stripe, ifthenpay, Easypay) ficam em variáveis de ambiente, não no código.- Segredos: renovação dos oito salts com o gerador do WordPress.org, que termina todas as sessões, e revogação das Application Passwords que não pertencem a uma integração conhecida.
- Login: segundo fator com TOTP para todos os administradores e limite de tentativas em
/wp-login.phpao nível do servidor ou da firewall do alojamento. - Ficheiros: execução de PHP bloqueada em
wp-content/uploads(.htaccessou blocolocationno nginx), listagem de diretórios desligada,xmlrpc.phpfechado quando não é usado. - Verificação de integridade:
wp core verify-checksumsewp plugin verify-checksums --allcomo rotina, para que uma alteração num ficheiro do núcleo não passe despercebida.
Aplicar estas medidas é trabalho à parte. Pode fazê-lo o seu programador a partir do documento, ou posso fazê-lo eu dentro da manutenção WordPress, com as atualizações testadas primeiro em staging.
O que recebe no fim
- Documento com os achados, cada um com prioridade (crítica, alta, média, baixa), a prova (excerto de registo, linha de código, cabeçalho HTTP) e a referência CVE quando existe.
- Instrução de correção para cada achado, escrita para que o seu programador a aplique sem rondas de perguntas.
- Lista do que não consegui verificar, por exemplo registos que o alojamento não guarda, para que saiba onde ficou um ponto cego.
Se encomendar também as correções, volto a verificar cada ponto do documento depois de aplicadas. Não prometo um site que nunca mais seja atacado.
Site atacado: o que fazer na primeira hora
- Não apague nada. Faça uma cópia dos ficheiros e da base de dados tal como estão. Os ficheiros infetados mostram por onde o atacante entrou.
- Mude as palavras-passe a partir de um dispositivo limpo: painel WordPress, alojamento, SFTP, base de dados, chaves de API de pagamentos e de e-mail. Termine todas as sessões.
- Ponha o site em manutenção se estiver a servir malware, a redirecionar visitantes ou a recolher dados de formulários e pagamentos.
- Peça ao alojamento o
access.loge oerror.loge pergunte durante quanto tempo os guarda. - Abra o Google Search Console. Um proprietário desconhecido é sinal comum de intrusão; remova-o depois de ter a cópia.
- Anote a hora em que confirmou a intrusão. É daí que contam os prazos do RGPD.
Como decorre a limpeza?
Trabalho numa cópia. Primeiro procuro o ponto de entrada (registos, checksums do núcleo e dos plugins), depois removo o malware e as backdoors dos ficheiros e da base de dados, verifico as contas de administrador e as tarefas cron, reinstalo o núcleo e os plugins a partir de fontes limpas e renovo todos os segredos. Se o Google tiver marcado o site, peço a revisão na Search Console. A duração depende do número de ficheiros infetados e de haver registos, por isso só a estimo depois de ver o site.
É obrigatório comunicar uma violação de dados?
Quem decide é o responsável pelo tratamento, ou seja, a sua empresa, não quem faz a limpeza. O artigo 33.º do RGPD obriga a notificar a autoridade de controlo, em Portugal a CNPD, sem demora injustificada e, sempre que possível, até 72 horas depois de ter conhecimento da violação, a menos que esta não seja suscetível de resultar num risco para os direitos e liberdades das pessoas. Quando o risco é elevado, o artigo 34.º exige também comunicar aos titulares dos dados. Toda a violação, notificada ou não, tem de ficar documentada internamente (artigo 33.º, n.º 5). Da minha parte recebe os factos de que o seu jurista precisa: se havia dados pessoais na base de dados, se houve acesso a eles e desde quando.
Fontes: texto do RGPD no EUR-Lex, orientações 9/2022 do CEPD sobre notificação de violações, CNPD.
Que acessos são necessários
- Uma conta de administrador WordPress temporária, com segundo fator, criada para a auditoria e apagada no fim.
- Acesso SSH ou SFTP ao servidor, de preferência só de leitura. Sem ele não consigo verificar checksums com WP-CLI, permissões nem registos, e parte do site fica por ver.
- Uma lista curta das integrações: nome do plugin ou serviço e para que serve. Ajuda-me a decidir que código ler primeiro.
Ajudam ainda o acesso à Google Search Console e os alertas antigos do Wordfence, do Sucuri ou do Patchstack, se os tiver. Se faltar algum acesso, o documento diz o que ficou por verificar.
Pedir uma auditoria
Escreva-me pelo formulário de contacto com o endereço do site, o alojamento e o motivo: suspeita de intrusão, relançamento, mudança de quem gere o site. Recebe por escrito o âmbito e uma proposta. Um exemplo de como analiso plugins desatualizados com CVE publicadas está no caso de auditoria de segurança WordPress.
Antes disso pode ver o site por si: a verificação de site WordPress carrega a versão pública de um endereço e mostra números medidos, incluindo os cabeçalhos e os pedidos que bloqueiam a primeira pintura. O resultado é imediato e não pede e-mail.
