Exposição de Informação Sensível: riscos e como corrigir

Muitos sites deixam, sem se aperceberem, ficheiros e diretorias com informação sensível acessíveis publicamente. Neste artigo explicamos os casos mais comuns de exposição de informação e como corrigi-los.

O que é a exposição de informação sensível

A exposição de informação sensível ocorre quando ficheiros, diretorias ou mensagens do seu site tornam acessível publicamente informação que deveria estar protegida – desde ficheiros de configuração com credenciais, a cópias de segurança, código-fonte, ou até mensagens de erro que revelam detalhes internos da infraestrutura.

Porque é importante

Ao contrário de uma vulnerabilidade que exige exploração ativa, a exposição de informação sensível é muitas vezes a forma mais direta e simples de um atacante obter acesso a dados críticos – por vezes bastando aceder diretamente a um URL previsível. Os riscos incluem:

Ficheiros de configuração expostos: ficheiros como .env, config.php ou wp-config.php podem conter credenciais de base de dados, chaves de API ou outras credenciais sensíveis.
Repositório .git exposto: a diretoria .git acessível publicamente pode permitir a um atacante descarregar todo o histórico do código-fonte do site, incluindo versões antigas com credenciais que já possam ter sido removidas do código atual.
Cópias de segurança acessíveis: ficheiros de backup (.zip, .sql, .bak) deixados na raiz do site podem conter uma cópia completa da base de dados ou do código.
Listagem de diretorias ativa: quando o servidor lista automaticamente o conteúdo de uma pasta sem um ficheiro índice, expondo a estrutura de ficheiros do site.
Mensagens de erro detalhadas: erros que revelam caminhos do servidor, versões de software, ou consultas de base de dados, facilitando a um atacante o reconhecimento da infraestrutura.
Ficheiros de administração ou instalação esquecidos: páginas de instalação, painéis administrativos de teste, ou ficheiros de exemplo deixados acessíveis após o desenvolvimento do site.
Divulgação do tipo e versão do servidor web: o cabeçalho Server, enviado por defeito por muitos servidores, pode revelar se o site corre em Apache, Nginx, LiteSpeed ou outro, e até a versão exata instalada – informação valiosa para um atacante direcionar ataques a vulnerabilidades conhecidas dessa versão específica.

Boas práticas

Nunca guardar credenciais diretamente em ficheiros acessíveis pela raiz pública do site – usar variáveis de ambiente ou ficheiros fora da diretoria pública sempre que possível.
Bloquear explicitamente o acesso a diretorias como .git, .svn ou .env ao nível da configuração do servidor.
Nunca deixar cópias de segurança na diretoria pública do site – guardar backups num local separado e sem acesso via web.
Desativar a listagem automática de diretorias no servidor.
Configurar o ambiente de produção para nunca mostrar mensagens de erro detalhadas aos visitantes – usar páginas de erro genéricas e registar os detalhes apenas em logs internos.
Remover ficheiros de instalação, exemplo ou administração de teste assim que o desenvolvimento do site estiver concluído.
Ocultar ou reduzir a informação enviada no cabeçalho Server, evitando divulgar o tipo e a versão exata do servidor web (Apache, Nginx, LiteSpeed, etc.).
Fazer uma auditoria periódica ao site, verificando se algum ficheiro ou diretoria sensível ficou acessível publicamente.

Como corrigir

Identifique se existem ficheiros ou diretorias sensíveis acessíveis publicamente, testando o acesso direto a caminhos comuns (ex: /.git/, /.env, /backup.zip, /wp-config.php.bak).
Bloqueie o acesso a estes caminhos ao nível do servidor. Em servidores Apache, por exemplo, pode adicionar ao .htaccess:

RedirectMatch 404 /\.git
Mova quaisquer ficheiros de configuração com credenciais para fora da diretoria pública do site, ou restrinja o seu acesso diretamente na configuração do servidor.
Remova imediatamente quaisquer cópias de segurança, ficheiros de instalação ou ficheiros de exemplo deixados na diretoria pública.
Desative a listagem automática de diretorias no servidor (em Apache, por exemplo, com a diretiva Options -Indexes).
Configure o ambiente de produção da aplicação para não mostrar mensagens de erro detalhadas publicamente, direcionando-as apenas para logs internos.
Configure o servidor para ocultar ou reduzir a informação enviada no cabeçalho Server. Por exemplo, em Apache, com as diretivas ServerTokens Prod e ServerSignature Off; em Nginx, com server_tokens off;; em LiteSpeed, através da opção equivalente no painel de configuração.
Reveja periodicamente o site, especialmente após alterações de desenvolvimento, para confirmar que nenhum ficheiro sensível ficou exposto.

Um único ficheiro de configuração ou uma cópia de segurança esquecida pode dar a um atacante acesso direto à sua base de dados – e este tipo de erro é surpreendentemente comum, mesmo em sites geridos por profissionais. A maioria dos fornecedores de alojamento genéricos não verifica isto por si. Na WebDig Host, incluímos verificações regulares de exposição de informação sensível como parte da gestão de alojamento, para identificar e corrigir estes problemas antes que sejam explorados.

Conhecer os serviços de alojamento e gestão de domínios da WebDig Host

Perguntas frequentes sobre exposição de informação sensível

Como posso saber se o meu site tem informação sensível exposta?

Pode testar manualmente o acesso a caminhos comuns como /.git/, /.env ou ficheiros de backup, ou usar uma ferramenta que automatize esta verificação, como o Secure Check.

Porque é a diretoria .git particularmente perigosa se ficar exposta?

Porque contém todo o histórico de alterações ao código do site, incluindo versões antigas que podem conter credenciais ou informação sensível já removida do código atual, mas ainda recuperável através do histórico.

É seguro deixar mensagens de erro detalhadas ativas durante o desenvolvimento?

Durante o desenvolvimento, em ambiente controlado, pode ser útil para depuração. O essencial é garantir que estas mensagens detalhadas nunca ficam ativas no ambiente de produção, acessível ao público.

Basta remover o link para um ficheiro sensível para o proteger?

Não. Remover o link visível não impede que alguém aceda diretamente ao ficheiro se souber ou adivinhar o caminho. É necessário bloquear efetivamente o acesso ao nível do servidor, ou remover o ficheiro por completo.

Saber que servidor web eu uso (Apache, Nginx, LiteSpeed) é assim tão grave?

Por si só, não é um risco crítico – mas facilita significativamente o trabalho de um atacante, que passa a poder pesquisar diretamente por vulnerabilidades conhecidas dessa versão específica, em vez de ter de testar várias hipóteses às cegas. Reduzir esta informação não elimina o risco, mas dificulta o reconhecimento inicial do seu servidor.

Verifique agora se o seu site expõe informação sensível

Com o Secure Check, pode confirmar gratuitamente se o seu domínio expõe ficheiros ou diretorias sensíveis, em poucos segundos.