As 25 fraquezas de software mais perigosas

Principais conclusões:

Atualmente, as fraquezas de software mais perigosas são as classes de falhas que os invasores exploram repetidamente em sistemas reais, principalmente falhas de injeção, bugs de corrupção de memória e falhas no controle de acesso.
Os pontos fracos da injeção, como scripts entre sites e injeção de SQL, permanecem altamente predominantes porque são fáceis de acionar e aplicar em muitos aplicativos modernos.
Os problemas de segurança de memória continuam causando o impacto técnico mais severo, incluindo falhas e execução remota de código, especialmente em bases de código nativas e antigas.
Erros de autorização e autenticação geralmente levam a grandes violações ao permitir que os usuários acessem dados ou funções além das permissões pretendidas.

Quais são os pontos fracos do software?

As fraquezas do software são falhas no design, no código ou na configuração do software que permitem a ocorrência de problemas de segurança. Essas fraquezas descrevem formas comuns pelas quais o software falha, e é por isso que os mesmos tipos de problemas de segurança aparecem em diferentes aplicativos e sistemas.

Como essas fraquezas se repetem, os atacantes se concentram em explorar os padrões subjacentes em vez de bugs individuais. Corrigir uma única vulnerabilidade não evita problemas futuros se a mesma fraqueza ainda existir em outro lugar na base de código.

Para resolver esse problema, o MITRE documenta e padroniza esses problemas recorrentes por meio da Common Weakness Enumeration. A análise da MITRE mostra que muitas vulnerabilidades do mundo real se originam de um conjunto relativamente pequeno de tipos conhecidos de fraquezas de software.

O que é o CWE e por que ele existe?

A Common Weakness Enumeration (CWE) existe para padronizar como as fraquezas do software são identificadas, nomeadas e rastreadas em todo o setor. Ele fornece uma referência comum para que ferramentas, relatórios e equipes de segurança descrevam o mesmo problema da mesma forma.

Antes do CWE, a mesma fraqueza podia aparecer com nomes diferentes em recomendações, scanners e documentação interna. Isso tornou difícil comparar riscos, medir tendências ou entender se problemas diferentes compartilhavam a mesma causa raiz.

O CWE é mantido pela MITRE como parte de seu trabalho para melhorar a segurança do software e do sistema. Ao mapear as vulnerabilidades de volta aos tipos de fraqueza padronizados, o MITRE permite que as organizações priorizem correções sistêmicas em vez de reagir a descobertas isoladas.

Como os rankings são determinados?

As classificações são criadas usando um processo baseado em dados que reflete como as fraquezas do software aparecem e são exploradas em sistemas do mundo real.

Fontes de dados: A análise é baseada em grandes volumes de vulnerabilidades relatadas que são mapeadas para tipos de fraqueza padronizados. Isso permite que padrões sejam identificados em diferentes produtos, fornecedores e tecnologias.
Mapeamento de pontos fracos: Cada vulnerabilidade relatada está vinculada a uma entrada na Common Weakness Enumeration, que possibilita agrupar problemas individuais por sua causa subjacente, em vez de tratá-los isoladamente.
Ponderação da prevalência: Os pontos fracos que aparecem com frequência nos dados de vulnerabilidade têm um peso mais alto na classificação. Isso destaca os problemas que afetam consistentemente muitos sistemas, em vez de casos extremos raros.
Pontuação de impacto: A gravidade é considerada analisando as consequências típicas da exploração, como exposição de dados, aumento de privilégios ou execução remota de código. As fraquezas que levam a resultados de maior impacto têm uma classificação mais alta.
Atualizações contínuas: A lista é mantida pelo MITRE e atualizada à medida que novos dados são disponibilizados. Os rankings mudam com o tempo, à medida que as tendências de exploração e os padrões de ataque mudam.

Quais são as 25 fraquezas de software mais perigosas?

Rank	CWE ID	Weakness Name	Category	Score	CVEs in KEV	Rank Change vs 2024	Why It’s Dangerous	Typical Impact
1	CWE-79	Cross-Site Scripting (XSS)	Injection	60.38	7	0	Executes attacker scripts in victim browsers	Session hijacking, account takeover
2	CWE-89	SQL Injection	Injection	28.72	4	1	Manipulates database queries via user input	Data breach, authentication bypass
3	CWE-352	Cross-Site Request Forgery (CSRF)	Session Management	13.64	0	1	Forces actions using authenticated user sessions	Unauthorized actions, data changes
4	CWE-862	Missing Authorization	Access Control	13.28	0	5	Lacks permission checks on protected functions	Unauthorized access, data exposure
5	CWE-787	Out-of-Bounds Write	Memory Safety	12.68	12	−3	Writes outside allocated memory boundaries	Remote code execution, crashes
6	CWE-22	Path Traversal	File Handling	8.99	10	−1	Accesses files outside intended directories	Sensitive file disclosure
7	CWE-416	Use-After-Free	Memory Safety	8.47	14	1	Uses memory after it is freed	Code execution, instability
8	CWE-125	Out-of-Bounds Read	Memory Safety	7.88	3	−2	Reads memory outside allocated buffers	Secret leakage, exploit chaining
9	CWE-78	OS Command Injection	Injection	7.85	20	−2	Executes arbitrary system commands	Full system compromise
10	CWE-94	Code Injection	Injection	7.57	7	1	Executes attacker-controlled code	Application takeover
11	CWE-120	Classic Buffer Overflow	Memory Safety	6.96	0	N/A	Overwrites adjacent memory buffers	Code execution, crashes
12	CWE-434	Unrestricted File Upload	File Handling	6.87	4	−2	Uploads executable or malicious files	Web shells, malware
13	CWE-476	NULL Pointer Dereference	Memory Safety	6.41	0	8	Dereferences null pointers at runtime	Denial of service
14	CWE-121	Stack-Based Buffer Overflow	Memory Safety	5.75	4	N/A	Corrupts stack execution flow	Privilege escalation, RCE
15	CWE-502	Unsafe Deserialization	Design Flaw	5.23	11	1	Deserializes untrusted attacker input	Remote code execution
16	CWE-122	Heap-Based Buffer Overflow	Memory Safety	5.21	6	N/A	Corrupts heap memory structures	Reliable exploitation
17	CWE-863	Incorrect Authorization	Access Control	4.14	4	1	Authorization logic enforces rules incorrectly	IDOR, privilege escalation
18	CWE-20	Improper Input Validation	Input Handling	4.09	2	−6	Fails to validate untrusted input	Injection, logic bypass
19	CWE-284	Improper Access Control	Access Control	4.07	1	N/A	Weak enforcement of access restrictions	Unauthorized actions
20	CWE-200	Information Exposure	Information Disclosure	4.01	1	−3	Leaks sensitive system or user data	Credential and data exposure
21	CWE-306	Missing Authentication (Critical Function)	Authentication	3.47	11	4	Critical functions lack authentication checks	Unauthorized operations
22	CWE-918	Server-Side Request Forgery (SSRF)	Network Interaction	3.36	0	−3	Makes attacker-controlled internal requests	Cloud credential theft
23	CWE-77	Command Injection	Injection	3.15	2	−10	Injects parameters into system commands	Host compromise
24	CWE-639	Authorization Bypass (User-Controlled Key)	Access Control	2.62	0	6	Manipulates identifiers to bypass authorization	Cross-user data access
25	CWE-770	No Resource Limits or Throttling	Resource Management	2.54	0	1	Exhausts system resources	Denial of service

Como ler e usar esta tabela?

A tabela de pontos fracos de software mais perigosos explica como cada fraqueza é classificada, categorizada e avaliada com base nos padrões reais de risco e exploração.

Classificação

A classificação mostra o quão perigosa é cada fraqueza em relação às outras da lista. Uma classificação mais alta reflete uma combinação de ocorrência frequente e impacto severo no mundo real.

IDENTIFICAÇÃO DE VACA

O CWE ID vincula cada fraqueza à sua definição padronizada na Common Weakness Enumeration. Isso permite que a mesma fraqueza seja referenciada de forma consistente em ferramentas, relatórios e documentação de segurança.

Ponto

A pontuação representa uma medida combinada da frequência com que a fraqueza aparece e de quão prejudicial ela tende a ser quando explorada. Pontuações mais altas indicam tipos de fraqueza que contribuem repetidamente para graves incidentes de segurança.

CVEs em KEV

Essa coluna mostra quantas vulnerabilidades exploradas conhecidas estão associadas a cada fraqueza. Um número maior sugere uma exploração ativa e contínua em ataques do mundo real.

Categoria

A categoria agrupa os pontos fracos por sua natureza subjacente, como injeção, segurança de memória ou controle de acesso. Isso facilita a identificação de padrões e áreas problemáticas sistêmicas em todos os aplicativos.

Impacto típico

O impacto típico resume os resultados mais comuns quando a fraqueza é explorada. Esses impactos incluem exposição de dados, execução remota de código, escalonamento de privilégios ou negação de serviço.

Padrões e conclusões das fraquezas de software mais perigosas

Os pontos fracos mais perigosos do software se agrupam em um pequeno número de tipos de falhas recorrentes. Esses clusters explicam onde os controles de segurança geralmente são interrompidos em sistemas reais.

Fraquezas da injeção

As falhas de injeção permanecem dominantes porque entradas não confiáveis continuam atingindo intérpretes, bancos de dados e interfaces de comando. Pequenos erros de validação ou codificação são suficientes para permitir um comprometimento total.

Fraquezas de segurança de memória

Problemas de corrupção de memória aparecem com frequência porque o gerenciamento manual de memória ainda é comum em componentes críticos. Essas fraquezas geralmente levam diretamente a falhas ou execução remota de código.

Fraquezas do controle de acesso

As falhas de autorização e autenticação se expandem entre os aplicativos, em vez de afetar recursos individuais. Um erro lógico pode expor dados ou funcionalidades para todos os usuários.

Causas raiz persistentes

A maioria dos pontos fracos da lista são antigos e bem compreendidos. Eles persistem porque as práticas de desenvolvimento não os eliminam de forma consistente no momento do design.

Como as organizações devem usar as fraquezas de software mais perigosas?

As organizações devem usar as fraquezas de software mais perigosas como referência de priorização em vez de uma lista de verificação. A lista ajuda a identificar quais problemas subjacentes criam o maior risco em produtos, equipes e ambientes.

Priorização de riscos

A lista destaca os tipos de fraqueza que consistentemente levam a resultados graves. As organizações podem usar isso para concentrar os esforços de remediação em problemas com maior probabilidade de causar danos reais.

Avaliações de design seguro

Essas fraquezas devem ser analisadas durante as fases de arquitetura e design, não somente após a descoberta das vulnerabilidades. Resolvê-los precocemente reduz a chance de padrões de alto risco serem incorporados aos sistemas.

Padrões de desenvolvimento

Os padrões de segurança e as diretrizes de codificação podem ser alinhados com as categorias de pontos fracos da lista. Isso garante que os desenvolvedores estejam se protegendo de forma consistente contra os modos de falha mais comuns.

Foco nos testes de segurança

Atividades de teste, como análises de código, modelagem de ameaças e varredura automatizada, podem ser mapeadas para esses tipos de fraqueza. Isso melhora a cobertura e reduz o tempo gasto em descobertas de baixo impacto.

Como os desenvolvedores podem reduzir a exposição a essas fraquezas

Os desenvolvedores reduzem a exposição às fraquezas mais perigosas do software concentrando-se em um pequeno conjunto de práticas que abordam as causas básicas, não os bugs individuais. O objetivo é evitar que padrões de alto risco entrem na base de código em primeiro lugar.

Tratamento de entradas

Todas as entradas externas devem ser tratadas como não confiáveis e validadas com limites de confiança claros. A validação e a codificação consistentes evitam a formação de muitas fraquezas relacionadas à injeção.

Autorização por design

As decisões de controle de acesso devem ser explícitas, centralizadas e aplicadas em todas as operações confidenciais. Confiar em suposições sobre funções de usuário ou fluxo de solicitações é uma fonte comum de falhas de autorização.

Segurança de memória

Sempre que possível, os desenvolvedores devem preferir linguagens seguras para memória ou abstrações bem testadas. Em ambientes em que o gerenciamento manual da memória é necessário, a verificação rigorosa dos limites e a codificação defensiva são essenciais.

Padrões seguros

Os aplicativos devem começar em um estado seguro, sem a necessidade de endurecimento manual. Configurações padrão inseguras geralmente transformam fraquezas menores em vulnerabilidades graves.

Foco na revisão de código

As revisões de código devem procurar ativamente padrões fracos, não apenas problemas de sintaxe ou estilo. Analisar as mudanças com base em categorias conhecidas de fraqueza de alto risco melhora a detecção antes do lançamento.

Os 10 melhores do CWE vs OWASP

Aspect	CWE	OWASP Top 10
Focus	Software weakness root causes	Application security risks
Scope	Broad weakness classification system	Curated list of common risks
Purpose	Prevent vulnerabilities at design and code level	Raise awareness of frequent attack patterns
Level	Conceptual and structural	Application and implementation
Usage	Secure design, code reviews, tooling	Security testing, training, risk communication
Maintained by	MITRE	OWASP

Considerações finais

Os pontos fracos mais perigosos do software não são problemas raros ou desconhecidos, mas falhas recorrentes no design e na implementação que os invasores exploram de forma consistente. O foco nessas classes de fraqueza ajuda as organizações a reduzir o risco na origem, em vez de reagir a incidentes individuais.

Ao usar estruturas padronizadas, como a Common Weakness Enumeration, as equipes podem alinhar os esforços de desenvolvimento, teste e segurança em torno das causas básicas compartilhadas. Essa abordagem leva a um software mais resiliente e a menos falhas de segurança de alto impacto ao longo do tempo.

‍