⚡ SSD NVMe · cPanel · SSL Grátis

Alojamento Web rápido
e seguro

Servidores NVMe, suporte em português e migração incluída.
Desde os Açores para o Mundo.

.pt .com .eu .net .org

O seu domínio
começa aqui

Registe a sua marca na Internet. Gestão de DNS incluída
e transferências .pt sem custos.

🚀 Novo · AMD EPYC · KVM · Gestão Completa

VPS Linux Gerida
de alto desempenho

A nossa equipa trata de tudo: atualizações, segurança
e monitorização 24x7. Foque-se no seu projeto.

SQL injection: como proteger o seu site

O SQL injection ocorre quando um atacante insere código SQL malicioso em inputs do site (formulários, URLs, parâmetros) que é executado diretamente na base de dados. Se bem-sucedido, o atacante pode ler toda a base de dados (incluindo credenciais), modificar ou eliminar dados, e em casos extremos, executar comandos no servidor.

Como funciona

Uma consulta construída por concatenação de valores externos pode permitir que dados sejam interpretados como SQL. A defesa principal é parametrizar consultas, além de validar formatos e limitar permissões. Não use sanitização genérica como substituto dessa separação.

WordPress e SQL injection

O WordPress core é robusto contra SQL injection graças ao uso de prepared statements via a classe $wpdb: $wpdb->prepare() parametriza as consultas, separando código SQL de dados. Isto torna a injecção impossível para consultas que usam prepare().

O problema são plugins e temas que fazem consultas à base de dados sem usar $wpdb->prepare(): constroem consultas concatenando inputs diretamente. Esta é a causa mais comum de vulnerabilidades SQL injection em WordPress.

Como proteger

Atualize plugins e temas: vulnerabilidades descobertas são corrigidas em atualizações. Use apenas plugins de fontes fidedignas com manutenção ativa.

Consulte as condições atuais do serviço da Lusitec para confirmar funcionalidades, limites e procedimentos disponíveis na sua conta. Se precisa de uma configuração específica, podemos avaliar o projeto e esclarecer o âmbito antes da alteração.

Princípio do menor privilégio: o utilizador MySQL usado pelo WordPress deve ter apenas os privilégios necessários (Select, INSERT, UPDATE, DELETE). Não conceda FILE, GRANT ou acesso a outras bases de dados.

Monitorizar: o Wordfence regista tentativas de SQL injection bloqueadas. O Imunify360 mostra ataques bloqueados a nível de servidor.

Separar a instrução SQL dos valores

Use consultas parametrizadas e funções documentadas da aplicação. Não monte uma consulta por concatenação de texto recebido. Validação de formato e autorização continuam importantes, mas não substituem a parametrização.

No WordPress, utilize as APIs apropriadas e prepare consultas personalizadas com cuidado. Placeholders de valores não são um método genérico para nomes de tabela e colunas. Um WAF pode filtrar certos pedidos, mas a defesa principal deve estar no código e no acesso da conta à base de dados.

Como verificar a proteção sem criar uma falsa sensação de segurança

Uma instalação protegida combina medidas no servidor com medidas na aplicação. Atualize os componentes mantidos pelos respetivos fabricantes, elimine extensões que já não utiliza, aplique permissões adequadas e proteja as contas de administração. Uma firewall pode bloquear determinadas tentativas, mas não corrige vulnerabilidades de um plugin desatualizado.

Registe os eventos relevantes e confirme a existência de backups recuperáveis antes de intervenções de maior risco. Se houver suspeita de comprometimento, preservar registos e identificar o ponto de entrada é tão importante como repor os ficheiros. Limpar apenas a página afetada pode deixar contas fraudulentas ou tarefas maliciosas ativas. A resposta deve distinguir contenção, análise, recuperação e prevenção de reincidência.

Como agir nas primeiras horas depois de um alerta

Identifique o sistema afetado, limite acessos desnecessários e preserve registos. Não elimine ficheiros ou reinstale tudo sem compreender o alcance do incidente. Se suspeita que houve exposição de passwords, substitua-as a partir de um dispositivo de confiança e reveja os administradores existentes.

Depois da contenção, analise a origem e teste a recuperação. Restaurar um backup contaminado pode reproduzir a falha. Distinga factos confirmados de hipóteses para que a resposta não seja orientada por suposições.

Camadas de proteção com funções diferentes

SSL, firewall, proteção contra malware e backups têm objetivos distintos. O HTTPS cifra a comunicação, mas não elimina vulnerabilidades de plugins. Uma cópia de segurança apoia a recuperação, mas não substitui prevenção. A firewall pode bloquear padrões de ataque sem impedir que uma password roubada seja utilizada.

Reveja periodicamente versões, utilizadores e permissões. A empresa deve saber o que é responsabilidade do alojamento e o que pertence à manutenção da aplicação. Esta distinção facilita a resposta quando surge um incidente.

Proteger as operações sobre os dados

Confirme consultas e permissões na aplicação, sem atribuir toda a responsabilidade ao servidor.

Podemos avaliar uma funcionalidade específica através do nosso desenvolvimento de plugins WordPress à medida. Peça uma avaliação do projeto, indicando o objetivo, as funções necessárias e o que já existe.

Referências oficiais

Artigos relacionados