A10:2025 – Tratamento Incorreto de Condições Excepcionais

Contexto

Tratamento Incorreto de Condições Excepcionais (Mishandling of Exceptional Conditions) é uma categoria nova para 2025. Esta categoria contém 24 CWEs e foca em tratamento de erros inadequado, erros lógicos, falhas abertas (failing open) e outros cenários relacionados decorrentes de condições anormais que os sistemas podem encontrar. Esta categoria possui algumas CWEs que anteriormente eram associadas à má qualidade de código. Isso era geral demais para nós; em nossa opinião, esta categoria mais específica fornece uma orientação melhor.

CWEs notáveis incluídas nesta categoria: CWE-209 Geração de Mensagem de Erro Contendo Informações Sensíveis, CWE-234 Falha ao Tratar Parâmetro Ausente, CWE-274 Tratamento Incorreto de Privilégios Insuficientes, CWE-476 Desreferência de Ponteiro NULO e CWE-636 Falha em Falhar de Forma Segura ('Failing Open').

Tabela de Pontuação

CWEs Mapeadas	Taxa Máx. de Incidência	Taxa Média de Incidência	Cobertura Máxima	Cobertura Média	Exploit Médio Ponderado	Impacto Médio Ponderado	Total de Ocorrências	Total de CVEs
24	20,67%	2,95%	100,00%	37,95%	7,11	3,81	769.581	3.416

Descrição

O tratamento incorreto de condições excepcionais em software acontece quando os programas falham em prevenir, detectar e responder a situações incomuns e imprevisíveis, o que leva a travamentos (crashes), comportamentos inesperados e, às vezes, vulnerabilidades. Isso pode envolver uma ou mais das três falhas a seguir: a aplicação não evita que uma situação incomum aconteça, não identifica a situação enquanto ela ocorre e/ou responde mal ou não responde de forma alguma à situação posteriormente.

Condições excepcionais podem ser causadas por validação de entrada ausente, fraca ou incompleta; tratamento de erros de alto nível tardio em vez de ocorrer nas funções onde eles surgem; estados ambientais inesperados, como problemas de memória, privilégio ou rede; tratamento de exceções inconsistente; ou exceções que não são tratadas de forma alguma, permitindo que o sistema caia em um estado desconhecido e imprevisível. Sempre que uma aplicação não tem certeza de sua próxima instrução, uma condição excepcional foi tratada incorretamente. Erros e exceções difíceis de encontrar podem ameaçar a segurança de toda a aplicação por um longo tempo.

Muitas vulnerabilidades de segurança diferentes podem ocorrer quando tratamos incorretamente condições excepcionais, como bugs de lógica, overflows, condições de corrida (race conditions), transações fraudulentas ou problemas com memória, estado, recurso, tempo, autenticação e autorização. Esses tipos de vulnerabilidades podem afetar negativamente a confidencialidade, disponibilidade e/ou integridade de um sistema ou de seus dados. Atacantes manipulam o tratamento de erros falho de uma aplicação para explorar essa vulnerabilidade.

Como Prevenir

Para tratar uma condição excepcional adequadamente, devemos planejar para tais situações (esperar o pior). Devemos "capturar" (catch) cada erro de sistema possível diretamente no local onde ocorrem e, então, tratá-lo (o que significa fazer algo significativo para resolver o problema e garantir a recuperação da falha). Como parte do tratamento, devemos incluir o lançamento de um erro (para informar o usuário de forma compreensível), o registro do evento (log), bem como a emissão de um alerta se considerarmos justificado. Também devemos ter um manipulador de exceções global para o caso de algo ter passado despercebido. Idealmente, também teríamos ferramentas ou funcionalidades de monitoramento e/ou observabilidade que vigiam erros repetidos ou padrões que indiquem um ataque em andamento, podendo emitir uma resposta, defesa ou bloqueio de algum tipo. Isso pode nos ajudar a bloquear e responder a scripts e bots que focam em nossas fraquezas de tratamento de erros.

Capturar e tratar condições excepcionais garante que a infraestrutura subjacente de nossos programas não seja deixada para lidar com situações imprevisíveis. Se você estiver no meio de uma transação de qualquer tipo, é extremamente importante realizar o rollback de cada parte da transação e começar de novo (também conhecido como falha segura ou failing closed). Tentar recuperar uma transação pela metade é frequentemente onde criamos erros irrecuperáveis.

Sempre que possível, adicione limites de taxa (rate limiting), cotas de recursos, throttling e outras restrições para prevenir condições excepcionais antes de tudo. Nada em tecnologia da informação deve ser ilimitado, pois isso leva à falta de resiliência da aplicação, negação de serviço, ataques de força bruta bem-sucedidos e faturas de nuvem extraordinárias.

Considere se erros repetidos idênticos, acima de uma certa taxa, devem ser exibidos apenas como estatísticas mostrando a frequência com que ocorreram e em qual período. Esta informação deve ser anexada à mensagem original para não interferir no registro e monitoramento automatizados, veja A09:2025 Falhas de Registro e Monitoramento de Segurança.

Além disso, queremos incluir uma validação de entrada rigorosa (com sanitização ou escaping para caracteres potencialmente perigosos que precisamos aceitar) e um tratamento de erros, registro, monitoramento e alerta centralizados, além de um manipulador de exceções global. Uma aplicação não deve ter múltiplas funções para tratar condições excepcionais; isso deve ser realizado em um único lugar, da mesma forma todas as vezes. Também devemos criar requisitos de segurança de projeto para todos os conselhos desta seção, realizar atividades de modelagem de ameaças e/ou revisão de design seguro na fase de design de nossos projetos, realizar revisão de código ou análise estática, bem como executar testes de estresse, desempenho e invasão do sistema final.

Se possível, toda a sua organização deve tratar condições excepcionais da mesma maneira, pois isso facilita a revisão e a auditoria de código em busca de erros neste importante controle de segurança.

Cenários de Exemplo de Ataque

Cenário 1: Exaustão de recursos via tratamento incorreto de condições excepcionais (Negação de Serviço) poderia ser causada se a aplicação captura exceções quando arquivos são carregados, mas não libera adequadamente os recursos depois. Cada nova exceção deixa recursos bloqueados ou indisponíveis, até que todos os recursos sejam esgotados.

Cenário 2: Exposição de dados sensíveis via tratamento inadequado ou erros de banco de dados que revelam o erro completo do sistema ao usuário. O atacante continua a forçar erros para usar as informações sensíveis do sistema para criar um ataque de SQL injection melhor. Os dados sensíveis nas mensagens de erro do usuário servem como reconhecimento (reconnaissance).

Cenário 3: Corrupção de estado em transações financeiras poderia ser causada por um atacante interrompendo uma transação de múltiplas etapas via interrupções de rede. Imagine que a ordem da transação fosse: debitar conta do usuário, creditar conta de destino, registrar transação. Se o sistema não realizar o rollback adequadamente de toda a transação (falha segura) quando houver um erro no meio do caminho, o atacante poderia potencialmente esvaziar a conta do usuário, ou possivelmente gerar uma condição de corrida que permita ao atacante enviar dinheiro para o destino várias vezes.

Referências

OWASP MASVS‑RESILIENCE