← Todas as verificações
SegurançaSeveridade típica: Crítico

Scanner de backups descarregáveis

Procura cópias comprimidas do site e dumps SQL descarregáveis que expõem o teu código e os teus dados.

O que verifica

Este scanner procura cópias de segurança acessíveis publicamente no teu site, como arquivos comprimidos do site ou volcados de base de dados descarregáveis. Deteta quando esses ficheiros ficaram no servidor ao alcance de qualquer pessoa.

Porque importa

Um backup descarregável pode conter todo o teu código-fonte e, pior ainda, um volcado de base de dados com dados de utilizadores, palavras-passe e segredos de configuração. É uma das filtrações mais graves porque entrega o teu site e os teus dados completos de uma só vez.

Como se corrige

Remove da pasta pública qualquer ficheiro de backup ou volcado SQL e guarda-os num sítio privado fora do alcance do site. Configura o teu processo de cópias para que nunca escreva dentro do diretório servido pelo servidor web.

Como funciona esta verificação

O Scanaris pede nove nomes de ficheiro que as pessoas usam vezes sem conta para guardar cópias de segurança na raiz do site: backup.zip, backup.tar.gz, website.zip, www.zip, public_html.zip, site.zip, database.sql, dump.sql e db.sql. Para cada um confirma que a resposta é um ficheiro real e não a página genérica do teu site: olha para o tipo de conteúdo e, no caso dos despejos SQL, para se o texto parece SQL. Todos os achados são de severidade crítica, porque um ficheiro assim contém ou o código completo do site ou a base de dados inteira.

Porque importa

Um backup.zip acessível é o teu projeto completo: código, configuração, as chaves que houvesse nos ficheiros e, muitas vezes, uma cópia da base de dados lá dentro. Um dump.sql é a base de dados tal e qual: utilizadores, emails, palavras-passe cifradas (que se podem atacar sem pressa), encomendas, mensagens. Não é precisa nenhuma técnica: é um download. E os scanners automáticos testam exatamente estes nomes contra todos os domínios que encontram, por isso "ninguém conhece o URL" não é uma proteção.

Porque acontece

Por comodidade num mau momento: antes de uma migração ou de uma atualização comprime-se a pasta do site "por precaução" e deixa-se ali mesmo. Ou um plugin de cópias de segurança escreve numa pasta pública. Ou uma exportação da base de dados é guardada junto ao código para a passar a alguém. Num servidor que serve a raiz do projeto, qualquer ficheiro que caia ali é público no instante.

Como corrigir

  • Apaga o ficheiro agora e age como se tivesse sido descarregado: roda todas as chaves e palavras-passe que continha e, se havia dados pessoais, pondera a obrigação de notificar.
  • Move as cópias para fora do diretório público. As cópias de segurança vão para um armazenamento à parte (um bucket privado, outro servidor), nunca para uma pasta que o servidor web sirva.
  • Configura a ferramenta de cópias para escrever fora da raiz web. Os plugins do WordPress costumam permitir escolher a pasta ou enviar para um serviço externo.
  • Bloqueia as extensões no servidor como segunda barreira. Em nginx: location ~* \.(zip|tar|gz|sql|bak)$ { deny all; }. Em Apache, um FilesMatch equivalente com Require all denied. Se ofereces legitimamente downloads comprimidos, limita-os a uma pasta concreta.
  • Revê os registos de acesso à procura de pedidos com 200 a estes nomes: dir-te-ão se alguém chegou antes.

Confirma que está corrigido

for p in backup.zip backup.tar.gz website.zip www.zip public_html.zip site.zip database.sql dump.sql db.sql; do
  printf "%-18s " "$p"; curl -s -o /dev/null -w "%{http_code} %{content_type}\n" "https://oteudominio.com/$p"
done

O esperado é 404 ou 403. Um 200 com text/html numa aplicação de página única é o seu HTML genérico; um 200 com application/zip, application/octet-stream ou text/plain é o ficheiro real.

Perguntas frequentes

A minha cópia tem um nome que ninguém adivinharia.

As ferramentas de ataque testam milhares de nomes e combinações com o domínio, a data e palavras como "old" ou "bak". Um nome raro reduz o risco mas não o elimina; a solução é que não esteja numa pasta pública.

E se o ficheiro estiver protegido com palavra-passe?

Um ZIP com palavra-passe descarrega-se na mesma e ataca-se sem limite de tentativas no computador do atacante. Continua a ser um achado crítico.

O check só olha para a raiz. E as subpastas?

Correto, estes nove nomes testam-se na raiz. As listagens de diretório abertas, que outro check mede, são a forma habitual de encontrar cópias em subpastas; fechá-las e bloquear as extensões cobre o resto.

Verifica-o no teu site

Analisa o teu site grátis e vê se esta e outras 44 verificações passam, com um fix prompt por cada problema.

Analisar o meu site grátis

Verificações relacionadas