Questão de Segurança da Informação — Práticas de Segurança e Ameaças em Programação — VUNESP 2023

Práticas de Programação Web Segura: Tratamento de Erros e Logs

Gabarito: letra A. A prática correta é centralizar as operações de log em uma rotina única, garantindo consistência, controle e segurança no registro de eventos. As demais alternativas violam princípios fundamentais de segurança: expor detalhes de depuração, assumir acesso por padrão, registrar apenas algumas exceções ou usar páginas de erro padrão do servidor são práticas inseguras.

O tratamento de erros e a geração de logs são componentes críticos da segurança de aplicações web. O objetivo é duplo: prevenir vazamento de informações sensíveis (como stack traces, caminhos de arquivos, consultas SQL) e permitir auditoria e detecção de incidentes (quem acessou, quando, de onde, com quais parâmetros). Uma rotina centralizada de log é a prática recomendada porque ela garante que todas as operações de registro sigam o mesmo padrão, com o mesmo nível de detalhe, o mesmo formato e as mesmas políticas de retenção. Isso facilita a análise forense, a correlação de eventos e a detecção de anomalias. Além disso, uma rotina centralizada permite aplicar filtros de dados sensíveis (como senhas, tokens e números de cartão) antes de gravar, evitando que informações críticas vazem para os logs.

A centralização também simplifica a gestão de configuração: se for necessário alterar o nível de log (de INFO para DEBUG, por exemplo) ou adicionar um novo destino (como um SIEM), a mudança é feita em um único ponto. Em contraste, logs espalhados pelo código dificultam a manutenção, aumentam o risco de inconsistências e tornam a auditoria ineficaz. A prática de centralizar logs é amplamente reconhecida em guias de desenvolvimento seguro, como o OWASP, e em normas como a ISO/IEC 27002, que recomenda o registro e monitoramento de eventos de segurança.

A pegadinha desta questão está em inverter o que é seguro: a banca apresenta práticas que parecem "convenientes" ou "funcionais" (como exibir erros detalhados para facilitar a depuração) mas que são, na verdade, vetores de ataque. O candidato que pensa apenas na funcionalidade, e não na segurança, tende a marcar a alternativa B. A regra de ouro é: nunca exponha detalhes internos do sistema ao usuário final; registre-os em logs seguros, acessíveis apenas a administradores autorizados.

Guarde a fronteira entre "registrar tudo de forma centralizada e segura" e "expor ou omitir informações de forma inadequada": é exatamente nela que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A centralização das operações de log em uma rotina única é uma prática de segurança recomendada. Ela garante que todos os eventos sejam registrados de forma consistente, com o mesmo formato e nível de detalhe, facilitando a auditoria, a detecção de incidentes e a aplicação de políticas de retenção e proteção de dados sensíveis. É uma prática alinhada com as boas práticas de desenvolvimento seguro e com normas como a ISO/IEC 27002.

Alternativa B — ❌ Incorreta

Exibir mensagens de erro detalhadas, com informações de depuração, é uma prática insegura. Isso expõe detalhes internos do sistema (como stack traces, caminhos de arquivos, versões de bibliotecas e consultas SQL) que podem ser explorados por atacantes para mapear vulnerabilidades. A prática correta é exibir mensagens de erro genéricas ao usuário e registrar os detalhes técnicos em logs seguros, acessíveis apenas a administradores.

Alternativa C — ❌ Incorreta

Assumir que o usuário possui acesso ao recurso pretendido por padrão, em caso de erro na checagem de controle de acesso, é uma falha grave de segurança. O princípio do fail-safe (falha segura) determina que, em caso de erro ou ambiguidade, o sistema deve negar o acesso por padrão, não concedê-lo. Assumir acesso por padrão pode permitir que usuários não autorizados acessem recursos restritos, comprometendo a confidencialidade e a integridade dos dados.

Alternativa D — ❌ Incorreta

Registrar em log apenas alguns tipos de exceções é uma prática insegura e incompleta. A omissão de logs pode impedir a detecção de ataques ou falhas críticas. A prática correta é registrar todas as exceções e eventos relevantes, com níveis de severidade adequados, e implementar políticas de rotação e retenção de logs para gerenciar o espaço de armazenamento. A preocupação com o crescimento do log deve ser resolvida com gerenciamento de logs (rotação, compressão, arquivamento), não com a omissão seletiva de eventos.

Alternativa E — ❌ Incorreta

Usar páginas de erro padrão do servidor web é uma prática insegura, pois essas páginas frequentemente expõem informações detalhadas sobre o servidor, a versão do software e a stack trace. A prática correta é usar páginas de erro personalizadas, que exibem mensagens genéricas e amigáveis ao usuário, sem revelar detalhes internos. Isso evita o vazamento de informações que podem ser usadas em ataques.

Gabarito: letra A