Wp Auditory: Quais possíveis problemas encontrados em sites wordpress?

O que é?

Arquivos como wp-config.php, .env ou backups (.zip, .sql) estão acessíveis publicamente.

Por que pode ocorrer?

Configurações de servidor que não bloqueiam acesso direto a esses arquivos.
Risco de ataque hacker: Vazamento de credenciais de banco de dados, chaves secretas e código-fonte, permitindo takeover completo do site (invasão, roubo de dados).

Por que corrigir?

Sem correção, um atacante pode baixar esses arquivos e comprometer todo o sistema, levando a perda de dados, defacement ou ransomware. É uma brecha básica e comum explorada por bots automatizados.

O que é?

O servidor exibe o conteúdo de pastas (ex: /wp-content/uploads/) quando não há arquivo index.

Por que pode ocorrer?

Configuração padrão do servidor sem bloqueio (Options +Indexes no Apache).

Risco de ataque hacker:

Enumeração de arquivos sensíveis, backups ou configs escondidos, facilitando ataques direcionados.

Por que corrigir?

Revela a estrutura do site, permitindo que hackers encontrem pontos fracos para exploração (ex: upload de shell via diretórios expostos). É uma porta aberta para reconnaissance.

O que é?

A pasta .git (com histórico de código) está acessível publicamente.

Por que pode ocorrer?

Deploy incorreto ou falta de bloqueio no servidor.
Risco de ataque hacker: Download completo do código-fonte, incluindo senhas hardcoded, chaves API e commits antigos.

Por que corrigir?

Expõe todo o código do site, permitindo reverse engineering e exploits customizados. Pode levar a vazamento de dados sensíveis ou backdoors.

O que é?

Falta proteção contra o site ser carregado em iframe de outro domínio.

Por que pode ocorrer?

Cabeçalhos de segurança não configurados no servidor.
Risco de ataque hacker: Clickjacking (sobreposição de iframes para roubar cliques, como login ou pagamentos).

Por que corrigir?

Protege usuários de phishing avançado onde o site real é usado para enganar ações. É uma medida básica contra UI redressing.

O que é?

Não força o navegador a usar apenas HTTPS em conexões futuras.

Por que pode ocorrer?

Cabeçalho não adicionado no servidor HTTPS.
Risco de ataque hacker: Downgrade attacks (forçar HTTP para interceptar tráfego em redes Wi-Fi públicas).

Por que corrigir?

Garante que o tráfego permaneça criptografado, prevenindo man-in-the-middle (MITM) e roubo de dados sensíveis como senhas.

O que é?

Não impede o navegador de adivinhar o tipo de arquivo (MIME-sniffing).

Por que pode ocorrer?

Cabeçalho não configurado.
Risco de ataque hacker: Ataques XSS via arquivos uploadados interpretados incorretamente (ex: imagem como script).

Por que corrigir?

Evita exploração de uploads maliciosos, reduzindo risco de injeção de código em navegadores.

O que é?

Não controla o envio de informações de origem (referrer) para outros sites.

Por que pode ocorrer?

Cabeçalho padrão não definido.
Risco de ataque hacker: Vazamento de URLs sensíveis (ex: com tokens) para terceiros.

Por que corrigir?

Protege privacidade e previne tracking ou exploração de links internos vazados.

O que é?

Não define regras para carregamento de recursos (scripts, estilos), ou permite ‘unsafe-inline’.

Por que pode ocorrer?

Cabeçalho não implementado ou mal configurado.

Risco de ataque hacker:

Alta exposição a XSS (injeção de scripts maliciosos).

Por que corrigir?

Reduz drasticamente ataques de injeção, protegendo usuários de roubo de dados via JS malicioso.

O que é?

Header Server revela nome/versão do servidor (ex: Apache/2.4).

Por que pode ocorrer?

Configuração padrão do servidor.

Risco de ataque hacker:

Facilita exploits conhecidos para versões específicas.

Por que corrigir?

Reduz fingerprinting, tornando mais difícil para hackers escolher ataques direcionados.

O que é?

Servidor permite métodos como TRACE ou PUT além de GET/POST.

Por que pode ocorrer?

Configuração padrão sem restrições.

Risco de ataque hacker:

Leak de headers (TRACE) ou upload malicioso (PUT).

Por que corrigir?

Evita abuso de métodos não necessários, reduzindo superfície de ataque.

O que é?

Meta tags ou query strings revelam a versão do WP.

Por que pode ocorrer?

Funcionalidade padrão do WP.

Risco de ataque hacker:

Ataques direcionados a vulnerabilidades conhecidas daquela versão.

Por que corrigir?

Dificulta reconnaissance, dando tempo para atualizar o WP sem ser alvo imediato.

O que é?

API REST expõe usuários sem autenticação.

Por que pode ocorrer?

WP REST API ativa por padrão.

Risco de ataque hacker:

Brute-force em logins reais (ex: admin).

Por que corrigir?

Protege contra ataques automatizados de credenciais, reduzindo risco de invasão.

O que é?

Endpoint xmlrpc.php permite chamadas remotas.

Por que pode ocorrer?

Ativo por padrão no WP.

Risco de ataque hacker:

Brute-force massivo e DDoS via pingback.

Por que corrigir?

Fecha uma porta comum para ataques amplificados, melhorando desempenho e segurança.

O que é?

Arquivos padrão do WP acessíveis, revelando versão.

Por que pode ocorrer?

Não removidos ou bloqueados após instalação.

Risco de ataque hacker:

Facilita identificação de versões vulneráveis.

Por que corrigir?

Reduz fingerprinting do WP, tornando mais difícil para scanners automáticos.

O que é?

Tráfego enviado sem criptografia.

Por que pode ocorrer?

Certificado SSL não instalado ou configurado.

Risco de ataque hacker:

Interceptação de dados (senhas, cookies) via MITM.

Por que corrigir?

Protege dados em trânsito, melhora SEO e evita warnings no navegador.

O que é?

Usuários podem acessar via HTTP sem redirect.

Por que pode ocorrer?

Falta de regra de rewrite.

Risco de ataque hacker:

Downgrade para HTTP inseguro.

Por que corrigir?

Garante criptografia sempre, prevenindo MITM em redes públicas.

O que é?

Parâmetros de URL redirecionam para sites externos arbitrários.

Por que pode ocorrer?

Validação fraca em códigos de redirect.

Risco de ataque hacker:

Phishing ou roubo de tokens via redirects maliciosos.

Por que corrigir?

Evita que o site seja usado como vetor para scams ou ataques de credenciais.

O que é?

Servidor responde a TRACE, ecoando headers.

Por que pode ocorrer?

Configuração padrão sem desabilitação.

Risco de ataque hacker:

Leak de cookies via XST (Cross-Site Tracing).

Por que corrigir?

Fecha brecha para roubo de dados protegidos (HttpOnly cookies).

O que é?

Permite acesso cross-origin amplo com credenciais.

Por que pode ocorrer?

Headers CORS mal configurados.

Risco de ataque hacker:

Roubo de dados via JS de outros sites.

Por que corrigir?

Protege APIs e dados sensíveis de leitura não autorizada.

O que é?

Sem SPF ou sem -all (hard fail).

Por que pode ocorrer?

DNS não configurado para e-mails.

Risco de ataque hacker:

Spoofing de e-mails (phishing como se fosse do seu domínio).

Por que corrigir?

Evita abuso do domínio para spam/phishing, melhorando entregabilidade e conformidade LGPD.

O que é?

Sem DMARC ou com p=none/quarantine (não rejeita).

Por que pode ocorrer?

Falta de configuração DNS avançada.

Risco de ataque hacker:

E-mails falsos enviados como se fossem seus.

Por que corrigir?

Bloqueia spoofing, protegendo reputação e usuários de fraudes.

O que é?

Sem assinatura digital para e-mails.

Por que pode ocorrer?

Provedor de e-mail não configurado.

Risco de ataque hacker:

E-mails alterados em trânsito sem detecção.

Por que corrigir?

Garante integridade dos e-mails, reduzindo spam e spoofing.

O que é?

Arquivos ou diretórios com permissões excessivas (ex: 777, 666).

Por que pode ocorrer?

Deploy manual, hospedagem compartilhada mal configurada.

Risco de ataque hacker:

Permite escrita não autorizada → upload de backdoor ou webshell.

Por que corrigir?

Permissões incorretas facilitam modificação maliciosa do código.

O que é?

Área administrativa acessível publicamente sem camada adicional.

Risco de ataque hacker:

Brute-force direcionado.

Por que corrigir?

Mesmo com senha forte, reduz ataque automatizado.

O que é?

Não controla recursos como câmera, microfone, geolocalização.

Risco de ataque hacker:

Abuso de APIs modernas do navegador.

O que é?

Cookies sem Secure, HttpOnly e SameSite.

Risco de ataque hacker:

Roubo de sessão via XSS ou MITM.

O que verificar:

/wp-json/

Rotas customizadas

Plugins expondo endpoints inseguros

Risco de ataque hacker:

Exposição de dados sensíveis via endpoints custom.

O que é?

wp-cron.php acessível externamente.

Risco de ataque hacker:

Abuso para sobrecarregar servidor.

O que é?

Servidor executa .php dentro de /uploads.

Risco de ataque hacker:

Webshell remoto.

Além de verificar arquivos no root, pode testar:

/backup/

/old/

/dev/

/test/

Bots procuram essas pastas.

O que é?

Subdomínio apontando para serviço inexistente (ex: antigo Heroku).

Risco de ataque hacker:

Atacante registra serviço e assume subdomínio.

O que é?

DNS não protegido contra spoofing.

Risco de ataque hacker:

Hijack de domínio.

O que é?

Servidor aceita requisições ilimitadas.

Risco de ataque hacker:

Brute force e DDoS leve.

O que é?

Páginas logadas sendo armazenadas em cache público.

Risco de ataque hacker:

Vazamento de sessão.

O que é?

Arquivo phpinfo.php acessível.

Risco de ataque hacker:

Exposição total da configuração do servidor.

O que é?

Servidor aceita TLS 1.0 ou 1.1.

Risco de ataque hacker:

Ataques de downgrade e criptografia fraca.

O que é?

Cifras inseguras habilitadas.

Risco de ataque hacker:

Ataques de descriptografia.

O que é?

Certificado com menos de 15 dias restantes.

Risco de ataque hacker:

Site cai inesperadamente.

O que é?

Página HTTPS carregando recursos HTTP.

Risco de ataque hacker:

MITM via assets inseguros.

O que é?

O site possui um usuário com login exatamente “admin”, que é o nome padrão do WordPress em instalações antigas.

Risco de ataque hacker:

Facilita ataques de brute force e credential stuffing, pois o atacante já conhece metade da credencial (o login). Bots automatizados tentam milhares de combinações partindo do usuário “admin”.

Por que corrigir?

Reduz significativamente ataques automatizados. Quando o login é previsível, basta quebrar a senha. Alterar o usuário remove um vetor comum explorado por scanners massivos.

O que é?

Usuários com senhas fracas (ex: 123456, admin123, nome+ano).

Risco de ataque hacker:

Ataques de dicionário e credential stuffing conseguem acesso rapidamente, especialmente se combinados com vazamentos anteriores.

Por que corrigir?

Mesmo com firewall e bloqueios, senhas fracas são o principal vetor de invasão em WordPress. A maioria dos sites invadidos sofre por credenciais fracas — não por falhas técnicas avançadas.

O que é?

Plugin instalado sem atualização há mais de 2 anos ou removido do repositório oficial.

Risco de ataque hacker:

Vulnerabilidades conhecidas podem ser exploradas publicamente. Exploits automatizados frequentemente miram plugins descontinuados.

Por que corrigir?

Plugins abandonados não recebem patches de segurança. Manter um plugin assim é manter uma porta aberta permanente para invasão futura.

O que é?

Temas instalados, porém não ativos.

Risco de ataque hacker:

Mesmo desativados, arquivos continuam acessíveis no servidor. Vulnerabilidades no tema podem ser exploradas diretamente via URL.

Por que corrigir?

Reduz superfície de ataque. Se não está em uso, não deve permanecer no ambiente de produção.

O que é?

Modo de depuração ativado em ambiente público.

Risco de ataque hacker:

Exposição de mensagens de erro com:

• Caminhos absolutos

• Queries SQL

• Estrutura interna do sistema

• Informações de plugins

Por que corrigir?

Facilita engenharia reversa e exploração direcionada. Informações internas ajudam o atacante a mapear vulnerabilidades com precisão.

O que é?

Erros PHP revelam o caminho completo do servidor.

Risco de ataque hacker:

Ajuda na construção de payloads personalizados, exploração de LFI (Local File Inclusion) e outras técnicas avançadas.

Por que corrigir?

Reduz fingerprinting e impede que atacantes obtenham informações internas do ambiente.

O que é?

Tabelas usam o prefixo padrão wp_.

Risco de ataque hacker:

Facilita scripts automatizados de SQL Injection que assumem nomes padrão de tabelas.

Por que corrigir?

Não impede SQLi, mas dificulta ataques automatizados massivos que dependem de estrutura previsível.

O que é?

Usuário do banco com permissões como GRANT ALL ou acesso administrativo completo.

Risco de ataque hacker:

Se houver SQL Injection, o atacante pode:

Criar novos usuários

Apagar banco

Executar operações destrutivas

Por que corrigir?

Aplicar princípio do menor privilégio limita o impacto de uma eventual falha.

O que é?

Porta 3306 aberta para acesso externo.

Risco de ataque hacker:

Tentativas de brute force direto no MySQL ou exploração de falhas do serviço.

Por que corrigir?

Banco de dados deve aceitar conexões apenas localmente ou por IP restrito.

O que é?

Ausência de camada de filtragem entre o visitante e o servidor.

Risco de ataque hacker:

Ataques como:

• SQL Injection

• XSS

• Exploits automatizados

• DDoS leve

Por que corrigir?

WAF bloqueia ataques antes de atingirem o WordPress, reduzindo drasticamente risco e carga no servidor.

O que é?

Sistema aceita tentativas ilimitadas de login.

Risco de ataque hacker:

Brute force massivo até encontrar senha correta.

Por que corrigir?

Limitar tentativas impede que ataques automatizados testem milhares de combinações.

O que é?

Login depende apenas de senha.

Risco de ataque hacker:

Se a senha vazar, acesso é imediato.

Por que corrigir?

2FA adiciona camada adicional, bloqueando invasões mesmo com senha comprometida.

O que é?

Parâmetros da URL são exibidos sem sanitização.

Risco de ataque hacker:

Execução de scripts maliciosos no navegador da vítima, podendo roubar cookies ou redirecionar para phishing.

Por que corrigir?

Protege usuários contra roubo de sessão e manipulação de conteúdo.

O que é?

Entradas do usuário não validadas antes de consulta ao banco.

Risco de ataque hacker:

Extração ou alteração de dados do banco.

Por que corrigir?

SQL Injection é uma das falhas mais críticas da OWASP, podendo comprometer totalmente o site.

O que é?

IP real do servidor é facilmente descoberto.

Risco de ataque hacker:

Bypass de firewall CDN e ataques diretos ao servidor.

Por que corrigir?

Ocultar IP protege contra ataques diretos e DDoS.

O que é?

cPanel, Plesk ou painel acessível publicamente.

Risco de ataque hacker:

Brute force administrativo.

Por que corrigir?

Painel é porta crítica — deve ter IP restrito ou 2FA obrigatório.

O que é?

Porta 22 aberta sem rate limit ou fail2ban.

Risco de ataque hacker:

Brute force em credenciais SSH.

Por que corrigir?

SSH comprometido significa controle total do servidor.

O que é?

Sem sistema que detecte alteração de arquivos.

Risco de ataque hacker:

Backdoors podem permanecer ocultos por meses.

Por que corrigir?

Permite detectar invasões rapidamente.

O que é?

Backups manuais ou inexistentes.

Risco de ataque hacker:

Ransomware ou falha técnica pode causar perda total.

Por que corrigir?

Backup é última linha de defesa.

O que é?

Logs não armazenados ou analisados.

Risco de ataque hacker:

Ataques passam despercebidos.

Por que corrigir?

Logs permitem auditoria, investigação e conformidade LGPD.

O que é?

Scripts externos carregados sem hash de verificação.

Risco de ataque hacker:

Se CDN for comprometida, script malicioso é executado.

Por que corrigir?

SRI garante integridade do recurso carregado.

O que é?

Headers modernos de isolamento de contexto.

Risco de ataque hacker:

Possibilidade de ataques cross-origin avançados.

Por que corrigir?

Melhora isolamento e segurança em aplicações modernas.

O que é?

Links externos abertos com target=”_blank” sem proteção.

Risco de ataque hacker:

Página externa pode alterar aba original.

Por que corrigir?

Protege usuários contra phishing indireto.

O que é?

HSTS ativo, mas não incluído na lista global preload.

Risco de ataque hacker:

Primeiro acesso pode ocorrer via HTTP.

Por que corrigir?

Garante HTTPS mesmo antes da primeira conexão.

O que é?

Headers permitem cache público de conteúdo sensível.

Risco de ataque hacker:

Dados privados podem ser armazenados indevidamente.

Por que corrigir?

Evita vazamento de dados via proxy/cache.

O que é?

Endpoints AJAX ou REST expostos sem autenticação.

Risco de ataque hacker:

Extração de dados ou execução de ações indevidas.

Por que corrigir?

Toda API deve exigir autenticação e validação adequada.