diff --git a/2025/docs/pt-BR/0x00_2025-Introduction.md b/2025/docs/pt-BR/0x00_2025-Introduction.md new file mode 100644 index 000000000..6f34b617d --- /dev/null +++ b/2025/docs/pt-BR/0x00_2025-Introduction.md @@ -0,0 +1,106 @@ +![OWASP Logo](../assets/TOP_10_logo_Final_Logo_Colour.png) + +# Os Dez Riscos de Segurança mais Críticos para Aplicações Web + +# Introdução + +Bem-vindo à 8ª edição da OWASP Top Ten! + +Um enorme agradecimento a todos que contribuíram com dados e perspectivas na pesquisa. Sem vocês, esta edição não seria possível. **MUITO OBRIGADO!** + +## Apresentando OWASP Top 10:2025 + +- [A01:2025 - Controle de Acesso Quebrado](A01_2025-Broken_Access_Control.md) +- [A02:2025 - Configuração Insegura](A02_2025-Security_Misconfiguration.md) +- [A03:2025 - Falhas na Cadeia de Suprimentos de Software](A03_2025-Software_Supply_Chain_Failures.md) +- [A04:2025 - Falhas Criptográficas](A04_2025-Cryptographic_Failures.md) +- [A05:2025 - Injeção](A05_2025-Injection.md) +- [A06:2025 - Design Inseguro](A06_2025-Insecure_Design.md) +- [A07:2025 - Falhas de Autenticação](A07_2025-Authentication_Failures.md) +- [A08:2025 - Falhas de Integridade de Software e Dados](A08_2025-Software_or_Data_Integrity_Failures.md) +- [A09:2025 - Falhas de Registro e Alerta de Segurança](A09_2025-Security_Logging_and_Alerting_Failures.md) +- [A10:2025 - Manuseio Incorreto de Condições Excepcionais](A10_2025-Mishandling_of_Exceptional_Conditions.md) + +## Mudanças da Top 10 para 2025 + +Há duas novas categorias e uma consolidação no Top Ten de 2025. Trabalhamos para manter nosso foco na raiz do problema em vez do sintoma, tanto quanto possível. Dada a complexidade da engenharia e segurança de software, é basicamente impossível criar 10 categorias sem algum nível de sobreposição. + +![Mapping](../assets/2025-mappings.png) + +- **[A01:2025 - Controle de Acesso Quebrado](A01_2025-Broken_Access_Control.md)** mantém sua posição em #1 como o risco mais sério; os dados indicam que, em média, 3,73% das aplicações testadas apresentavam uma ou mais das 40 Common Weakness Enumerations (CWEs) desta categoria. Como indicado pela linha pontilhada, o Server-Side Request Forgery (SSRF) foi incorporado a esta categoria. +- **[A02:2025 - Configuração Insegura](A02_2025-Security_Misconfiguration.md)** subiu da 5ª posição em 2021 para a 2ª em 2025. Configurações incorretas estão mais prevalentes; 3,00% das aplicações testadas tinham uma ou mais das 16 CWEs aqui listadas. Isso não surpreende, visto que o comportamento das aplicações depende cada vez mais de configurações. +- **[A03:2025 - Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md)** (Falhas na Cadeia de Suprimentos de Software) é uma expansão de [A06:2021-Componentes Vulneráveis e Desatualizados](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) para incluir um escopo mais amplo de comprometimentos que ocorrem dentro ou através de todo o ecossistema de dependências de software, sistemas de build e infraestrutura de distribuição. Esta categoria foi votada massivamente como uma das principais preocupações na pesquisa com a comunidade. A categoria possui 5 CWEs e uma presença limitada nos dados coletados, mas acreditamos que isso se deve a desafios nos testes e esperamos que os testes evoluam nesta área. Esta categoria possui o menor número de ocorrências nos dados, mas também as maiores pontuações médias de explorabilidade (exploit) e impacto vindas de CVEs. +- **[A04:2025 - Falhas Criptográficas](A04_2025-Cryptographic_Failures.md)** caiu duas posições, de #2 para #4 no ranking. Os dados contribuídos indicam que, em média, 3,80% das aplicações possuem uma ou mais das 32 CWEs nesta categoria. Esta categoria frequentemente leva à exposição de dados sensíveis ou ao comprometimento do sistema. +- **[A05:2025 - Injeção](A05_2025-Injection.md)** caiu duas posições, de #3 para #5 no ranking, mantendo sua posição relativa a Falhas Criptográficas e Design Inseguro. Injeção é uma das categorias mais testadas, com o maior número de CVEs associados às 38 CWEs nesta categoria. Injeção inclui uma gama de problemas, desde Cross-Site Scripting (alta frequência/baixo impacto) até vulnerabilidades de SQL Injection (baixa frequência/alto impacto). +- **[A06:2025 - Design Inseguro](A06_2025-Insecure_Design.md)** caiu duas posições, de #4 para #6 no ranking, conforme Configuração Insegura e Falhas na Cadeia de Suprimentos de Software a ultrapassaram. Esta categoria foi introduzida em 2021 e observamos melhorias notáveis na indústria relacionadas à modelagem de ameaças (threat modeling) e uma maior ênfase em design seguro. +- **[A07:2025 - Falhas de Autenticação](A07_2025-Authentication_Failures.md)** mantém sua posição em #7 com uma leve mudança no nome (anteriormente era "[Falhas de Identificação e Autenticação](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)") para refletir com mais precisão as 36 CWEs nesta categoria. Esta categoria continua importante, mas o aumento do uso de frameworks padronizados para autenticação parece estar gerando efeitos benéficos nas ocorrências de falhas de autenticação. +- **[A08:2025 - Falhas de Integridade de Software e Dados](A08_2025-Software_or_Data_Integrity_Failures.md)** continua em #8 na lista. Esta categoria foca na falha em manter perímetros de confiança (trust boundaries) e verificar a integridade de artefatos de software, código e dados em um nível inferior às Falhas na Cadeia de Suprimentos de Software. +- **[A09:2025 - Falhas de Registro e Alerta de Segurança](A09_2025-Security_Logging_and_Alerting_Failures.md)** mantém sua posição em #9. Esta categoria teve uma leve mudança no nome (anteriormente "[Falhas de Registro e Monitoramento de Segurança](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/)") para enfatizar a importância da funcionalidade de alerta necessária para induzir a ação apropriada diante de eventos de log relevantes. Um excelente registro de log sem alertas possui valor mínimo na identificação de incidentes de segurança. Esta categoria estará sempre sub-representada nos dados e foi novamente votada para uma posição na lista pelos participantes da pesquisa da comunidade. +- **[A10:2025 - Manuseio Incorreto de Condições Excepcionais](A10_2025-Mishandling_of_Exceptional_Conditions.md)** é uma nova categoria para 2025. Esta categoria contém 24 CWEs focadas em tratamento de erros inadequado, erros lógicos, falha aberta (failing open) e outros cenários relacionados decorrentes de condições anormais que os sistemas podem encontrar. + +## Metodologia + +Esta edição do Top Ten permanece informada por dados, mas não é cegamente impulsionada por eles. Classificamos 12 categorias com base nos dados contribuídos e permitimos que duas fossem promovidas ou destacadas por meio das respostas da pesquisa com a comunidade. Fazemos isso por uma razão fundamental: examinar os dados contribuídos é, essencialmente, olhar para o passado. Pesquisadores de Segurança de Aplicações dedicam tempo para identificar novas vulnerabilidades e desenvolver novos métodos de teste. Leva de semanas a anos para integrar esses testes em ferramentas e processos. No momento em que podemos testar confiavelmente uma fraqueza em escala, anos podem ter se passado. Também existem riscos importantes que talvez nunca possamos testar de forma confiável para que apareçam nos dados. Para equilibrar essa visão, utilizamos uma pesquisa com a comunidade para perguntar aos profissionais de segurança e desenvolvedores que estão na linha de frente o que eles veem como riscos essenciais que podem estar sub-representados nos dados de teste. + +## Como as Categorias são Estruturadas + +Algumas categorias mudaram em relação à edição anterior do OWASP Top Ten. Aqui está um resumo de alto nível das mudanças nas categorias. + +Nesta iteração, solicitamos dados sem restrição de CWEs, como fizemos na edição de 2021. Perguntamos o número de aplicações testadas em um determinado ano (começando em 2021) e o número de aplicações com pelo menos uma instância de uma CWE encontrada nos testes. Este formato nos permite rastrear quão prevalente cada CWE é dentro da população de aplicações. Ignoramos a frequência para nossos propósitos; embora ela possa ser necessária em outras situações, ela apenas oculta a prevalência real na população de aplicações. Se uma aplicação possui quatro instâncias de uma CWE ou 4.000 instâncias, isso não faz parte do cálculo para o Top Ten. Especialmente porque testadores manuais tendem a listar uma vulnerabilidade apenas uma vez, não importa quantas vezes ela se repita em uma aplicação, enquanto frameworks de testes automatizados listam cada instância de uma vulnerabilidade como única. Passamos de aproximadamente 30 CWEs em 2017 para quase 400 em 2021 e para 589 CWEs nesta edição para análise no conjunto de dados. Planejamos realizar análises de dados adicionais como complemento no futuro. Este aumento significativo no número de CWEs exige mudanças na forma como as categorias são estruturadas. + +Passamos vários meses agrupando e categorizando CWEs e poderíamos ter continuado por meses adicionais. Tivemos que parar em algum momento. Existem CWEs do tipo causa raiz e do tipo sintoma, onde as de causa raiz são como "Falha Criptográfica" e "Configuração Incorreta", em contraste com tipos de sintoma como "Exposição de Dados Sensíveis" e "Negação de Serviço". Decidimos focar na causa raiz sempre que possível, pois é mais lógico para fornecer orientações de identificação e remediação. Focar na causa raiz em vez do sintoma não é um conceito novo; o Top Ten tem sido uma mistura de sintoma e causa raiz. As CWEs também são uma mistura de sintoma e causa raiz; estamos simplesmente sendo mais deliberados ao apontar isso. Há uma média de 25 CWEs por categoria nesta edição, com limites inferiores de 5 CWEs para A03:2025-Software Supply Chain Failures e A09:2025 Security Logging and Alerting Failures, até 40 CWEs em A01:2025-Broken Access Control. Tomamos a decisão de limitar o número de CWEs em uma categoria a 40. Esta estrutura de categorias atualizada oferece benefícios adicionais de treinamento, pois as empresas podem focar em CWEs que façam sentido para uma linguagem/framework. + +Perguntaram-nos por que não mudar para uma lista de 10 CWEs como um Top 10, similar ao MITRE Top 25 Most Dangerous Software Weaknesses. Existem duas razões principais pelas quais usamos múltiplas CWEs em categorias. Primeiro, nem todas as CWEs existem em todas as linguagens de programação ou frameworks. Isso causa problemas para ferramentas e programas de treinamento/conscientização, já que parte do Top Ten poderia não ser aplicável. A segunda razão é que existem múltiplas CWEs para vulnerabilidades comuns. Por exemplo, existem múltiplas CWEs para Injeção geral, Command Injection, Cross-Site Scripting, Senhas Hardcoded, Falta de Validação, Buffer Overflows, Armazenamento de Informações Sensíveis em Texto Simples e muitas outras. Dependendo da organização ou do testador, diferentes CWEs podem ser usadas. Ao usar uma categoria com múltiplas CWEs, podemos ajudar a elevar a base de referência e a conscientização sobre os diferentes tipos de fraquezas que podem ocorrer sob um nome de categoria comum. Nesta edição do Top Ten 2025, existem 248 CWEs dentro das 10 categorias. Há um total de 968 CWEs no [dicionário para download do MITRE](https://cwe.mitre.org) no momento deste lançamento. + +## Como os dados são usados para selecionar as categorias + +De forma semelhante ao que fizemos para a edição de 2021, aproveitamos os dados de CVE para _Explorabilidade_ (Exploitability) e _Impacto (Técnico)_. Baixamos o OWASP Dependency Check e extraímos as pontuações de Exploit e Impact do CVSS, agrupando-as pelas CWEs relevantes listadas com as CVEs. Isso exigiu uma boa dose de pesquisa e esforço, pois todas as CVEs possuem pontuações CVSSv2, mas há falhas no CVSSv2 que o CVSSv3 deveria corrigir. Após um certo ponto no tempo, todas as CVEs recebem também uma pontuação CVSSv3. Além disso, as faixas de pontuação e fórmulas foram atualizadas entre o CVSSv2 e o CVSSv3. + +No CVSSv2, tanto a Explorabilidade quanto o Impacto (Técnico) podiam chegar a 10.0, mas a fórmula os reduzia para 60% para Explorabilidade e 40% para Impacto. No CVSSv3, o máximo teórico foi limitado a 6.0 para Explorabilidade e 4.0 para Impacto. Com o peso considerado, a pontuação de Impacto subiu quase um ponto e meio em média no CVSSv3, e a explorabilidade caiu quase meio ponto em média. + +Existem aproximadamente 175 mil registros (contra 125 mil em 2021) de CVEs mapeadas para CWEs no National Vulnerability Database (NVD), extraídos do OWASP Dependency Check. Além disso, há 643 CWEs únicas mapeadas para CVEs (contra 241 em 2021). Dentro das quase 220 mil CVEs extraídas, 160 mil tinham pontuações CVSS v2, 156 mil tinham pontuações CVSS v3 e 6 mil tinham pontuações CVSS v4. Muitas CVEs possuem múltiplas pontuações, por isso o total ultrapassa 220 mil. + +Para o Top Ten 2025, calculamos as pontuações médias de explorabilidade e impacto da seguinte maneira: agrupamos todas as CVEs com pontuações CVSS por CWE e ponderamos as pontuações de explorabilidade e impacto pela porcentagem da população que possuía CVSSv3, bem como a população restante com pontuações CVSSv2, para obter uma média geral. Mapeamos essas médias para as CWEs no conjunto de dados para usar como pontuação de Explorabilidade e Impacto (Técnico) para a outra metade da equação de risco. + +Por que não usar o CVSS v4.0, você pode perguntar? Isso ocorre porque o algoritmo de pontuação foi fundamentalmente alterado e não fornece mais facilmente as pontuações de _Exploit_ ou _Impact_ como o CVSS v2 e o CVSSv3 fazem. Tentaremos descobrir uma maneira de usar a pontuação CVSS v4.0 para versões futuras do Top Ten, mas não conseguimos determinar uma forma oportuna de fazê-lo para a edição de 2025. + +## Por que usamos uma pesquisa com a comunidade + +Os resultados nos dados são amplamente limitados ao que a indústria consegue testar de forma automatizada. Fale com um profissional experiente em AppSec e ele lhe contará sobre coisas que encontra e tendências que vê que ainda não estão nos dados. Leva tempo para as pessoas desenvolverem metodologias de teste para certos tipos de vulnerabilidade e mais tempo ainda para que esses testes sejam automatizados e executados contra uma grande população de aplicações. Tudo o que encontramos é um olhar para o passado e pode estar perdendo tendências do último ano que não estão presentes nos dados. + +Portanto, selecionamos apenas oito das dez categorias a partir dos dados porque eles são incompletos. As outras duas categorias vêm da pesquisa com a comunidade Top 10. Isso permite que os profissionais que estão na linha de frente votem no que veem como os riscos mais altos que podem não estar nos dados (e que talvez nunca sejam expressos em dados). + +## Obrigado aos nossos contribuidores de dados + +As seguintes organizações (juntamente com vários doadores anônimos) gentilmente doaram dados de mais de 2,8 milhões de aplicações para tornar este o maior e mais abrangente conjunto de dados de segurança de aplicações. Sem vocês, isso não seria possível. + +- Accenture (Prague) +- Anônimo (múltiplos) +- Bugcrowd +- Contrast Security +- CryptoNet Labs +- Intuitor SoftTech Services +- Orca Security +- Probely +- Semgrep +- Sonar +- usd AG +- Veracode +- Wallarm + +## Autores Principais + +- Andrew van der Stock - X: [@vanderaj](https://x.com/vanderaj) +- Brian Glas - X: [@infosecdad](https://x.com/infosecdad) +- Neil Smithline - X: [@appsecneil](https://x.com/appsecneil) +- Tanya Janca - X: [@shehackspurple](https://x.com/shehackspurple) +- Torsten Gigler - Mastodon: [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) + +## Registro de problemas e pull requests + +Por favor, registre quaisquer correções ou problemas: + +### Links do projeto: + +- [Página Inicial](https://owasp.org/www-project-top-ten/) +- [Repositório GitHub](https://github.com/OWASP/Top10) diff --git a/2025/docs/pt-BR/0x01_2025-About_OWASP.md b/2025/docs/pt-BR/0x01_2025-About_OWASP.md new file mode 100644 index 000000000..2a1087829 --- /dev/null +++ b/2025/docs/pt-BR/0x01_2025-About_OWASP.md @@ -0,0 +1,35 @@ +# Sobre a OWASP + +O Open Worldwide Application Security Project (OWASP) é uma comunidade aberta dedicada a capacitar organizações a desenvolver, adquirir e manter aplicações e APIs confiáveis. + +Na OWASP, você encontrará, de forma gratuita e aberta: + +- Ferramentas e padrões de segurança de aplicações +- Pesquisas de ponta +- Controles e bibliotecas de segurança padrão +- Livros completos sobre testes de segurança de aplicações, desenvolvimento de código seguro e revisão de código seguro +- Apresentações e [vídeos](https://www.youtube.com/user/OWASPGLOBAL) +- [Cheat sheets](https://cheatsheetseries.owasp.org/) sobre diversos temas comuns +- Reuniões de [Chapters](https://owasp.org/chapters/) (Capítulos) realizadas em todo o mundo e online +- [Eventos, treinamentos e conferências](https://owasp.org/events/) +- [Google Groups](https://groups.google.com/g/owasp) + +Saiba mais em: [https://owasp.org](https://owasp.org). + +Todas as ferramentas, documentos, vídeos, apresentações e chapters da OWASP são gratuitos e abertos a qualquer pessoa interessada em melhorar a segurança de aplicações. + +Defendemos a abordagem da segurança de aplicações como um problema de pessoas, processos e tecnologia, pois as abordagens mais eficazes para a segurança de aplicações exigem melhorias em todas essas áreas. + +A OWASP é um tipo diferente de organização. Nossa isenção de pressões comerciais nos permite fornecer informações imparciais, práticas e econômicas sobre segurança de aplicações. + +A OWASP não é afiliada a nenhuma empresa de tecnologia, embora apoiemos o uso consciente de tecnologia de segurança comercial. A OWASP produz diversos tipos de materiais de maneira colaborativa, transparente e aberta. + +A OWASP Foundation é a entidade sem fins lucrativos que garante o sucesso do projeto a longo prazo. Quase todos os associados à OWASP são voluntários, incluindo o conselho da OWASP, líderes de chapters, líderes de projetos e membros de projetos. Apoiamos pesquisas de segurança inovadoras por meio de subsídios e infraestrutura. + +Junte-se a nós! + +## Direitos Autorais e Licença + +![License](../assets/license.png) + +Copyright © 2003-2025 The OWASP® Foundation, Inc. Este documento é liberado sob a licença Creative Commons Attribution Share-Alike 4.0. Para qualquer reutilização ou distribuição, você deve deixar claro para outros os termos de licença deste trabalho. diff --git a/2025/docs/pt-BR/0x02_2025-What_are_Application_Security_Risks.md b/2025/docs/pt-BR/0x02_2025-What_are_Application_Security_Risks.md new file mode 100644 index 000000000..4822075f1 --- /dev/null +++ b/2025/docs/pt-BR/0x02_2025-What_are_Application_Security_Risks.md @@ -0,0 +1,112 @@ +# O que são Riscos de Segurança de Aplicações? + +Atacantes podem usar diversos caminhos diferentes através de sua aplicação para causar danos ao seu negócio ou organização. Cada um desses caminhos representa um risco potencial que precisa ser investigado. + +![Diagrama de cálculo](../assets/2025-algorithm-diagram.png) + + + + + + + + + + + + + + + + + + +
+ Agentes de Ameaça + + Vetores de \ +Ataque + + Explorabilidade + + Probabilidade de Ausência de Controles +

+ + de Segurança + +

+ Impactos +

+ + Técnicos + +

+ Impactos de +

+ + Negócio + +

+ Por ambiente, dinâmico por cenário situacional + + Por exposição da aplicação (por ambiente) + + Média Ponderada de Exploit + + Controles Ausentes por taxa de Incidência média ponderada pela cobertura + + Média Ponderada de Impacto + + Por Negócio +
+ +Em nossa Classificação de Risco, levamos em conta os parâmetros universais de explorabilidade, a probabilidade média de ausência de controles de segurança para uma fraqueza e seus impactos técnicos. + +Cada organização é única, assim como os agentes de ameaça para essa organização, seus objetivos e o impacto de qualquer violação. Se uma organização de interesse público utiliza um sistema de gerenciamento de conteúdo (CMS) para informações públicas e um sistema de saúde utiliza exatamente o mesmo CMS para registros de saúde sensíveis, os agentes de ameaça e os impactos de negócio podem ser muito diferentes para o mesmo software. É crítico entender o risco para sua organização com base na exposição da aplicação, nos agentes de ameaça aplicáveis por cenário situacional (para ataques direcionados e não direcionados por negócio e localização) e nos impactos de negócio individuais. + +## Como os dados são usados para selecionar e ranquear as categorias + +Em 2017, selecionamos as categorias pela taxa de incidência para determinar a probabilidade e, em seguida, as ranqueamos por meio de discussões da equipe baseadas em décadas de experiência em Explorabilidade, Detectabilidade (também uma probabilidade) e Impacto Técnico. Para 2021, utilizamos dados de Explorabilidade e Impacto (Técnico) das pontuações CVSSv2 e CVSSv3 no National Vulnerability Database (NVD). Para 2025, continuamos com a mesma metodologia criada em 2021. + +Baixamos o OWASP Dependency Check e extraímos as pontuações de Exploit e Impact do CVSS, agrupadas por CWEs relacionadas. Isso exigiu bastante pesquisa e esforço, pois todas as CVEs possuem pontuações CVSSv2, mas há falhas no CVSSv2 que o CVSSv3 deveria corrigir. Após um certo ponto no tempo, todas as CVEs recebem também uma pontuação CVSSv3. Além disso, as faixas de pontuação e fórmulas foram atualizadas entre o CVSSv2 e o CVSSv3. + +No CVSSv2, tanto o Exploit quanto o Impacto (Técnico) podiam chegar a 10.0, mas a fórmula os reduzia para 60% para Exploit e 40% para Impacto. No CVSSv3, o máximo teórico foi limitado a 6.0 para Exploit e 4.0 para Impacto. Com a ponderação considerada, a pontuação de Impacto deslocou-se para cima — quase um ponto e meio em média no CVSSv3 — e a explorabilidade moveu-se quase meio ponto para baixo em média quando realizamos a análise para o Top Ten de 2021. + +Existem aproximadamente 175 mil registros (contra 125 mil em 2021) de CVEs mapeadas para CWEs no National Vulnerability Database (NVD), extraídos do OWASP Dependency Check. Além disso, há 643 CWEs únicas mapeadas para CVEs (contra 241 em 2021). Dentro das quase 220 mil CVEs extraídas, 160 mil tinham pontuações CVSS v2, 156 mil tinham pontuações CVSS v3 e 6 mil tinham pontuações CVSS v4. Muitas CVEs possuem múltiplas pontuações, por isso o total ultrapassa 220 mil. + +Para o Top Ten 2025, calculamos as pontuações médias de exploit e impacto da seguinte maneira: agrupamos todas as CVEs com pontuações CVSS por CWE e ponderamos as pontuações de exploit e impacto pela porcentagem da população que possuía CVSSv3, bem como a população restante com pontuações CVSSv2, para obter uma média geral. Mapeamos essas médias para as CWEs no conjunto de dados para usar como pontuação de Exploit e Impacto (Técnico) para a outra metade da equação de risco. + +Por que não usar o CVSS v4.0? Porque o algoritmo de pontuação foi fundamentalmente alterado e não fornece mais facilmente as pontuações de _Exploit_ ou _Impact_ como o CVSSv2 e o CVSSv3 fazem. Tentaremos descobrir uma maneira de usar a pontuação CVSS v4.0 para versões futuras do Top Ten, mas não conseguimos determinar uma forma oportuna de fazê-lo para a edição de 2025. + +Para a taxa de incidência, calculamos a porcentagem de aplicações vulneráveis a cada CWE a partir da população testada por uma organização durante um período. Como lembrete, não estamos usando a frequência (ou quantas vezes um problema aparece em uma aplicação); estamos interessados em qual porcentagem da população de aplicações apresentou cada CWE. + +Para a cobertura, analisamos a porcentagem de aplicações testadas por todas as organizações para uma determinada CWE. Quanto maior a cobertura calculada, maior a garantia de que a taxa de incidência é precisa, pois o tamanho da amostra é mais representativo da população. + +A fórmula que utilizamos para esta iteração é semelhante à de 2021, com algumas mudanças na ponderação: +(Taxa de Incidência Máxima % _ 1000) + (Cobertura Máxima % _ 100) + (Média de Exploit _ 10) + (Média de Impacto _ 20) + (Soma de Ocorrências / 10000) = Pontuação de Risco + +As pontuações calculadas variaram de 621,60 para a categoria de Controle de Acesso Quebrado a 271,08 para Erros de Gerenciamento de Memória. + +Este não é um sistema perfeito, mas é valioso para ranquear categorias de risco. + +Um desafio adicional crescente é a definição de "aplicação". À medida que a indústria muda para diferentes arquiteturas compostas por microsserviços e outras implementações menores que uma aplicação tradicional, os cálculos tornam-se mais difíceis. Por exemplo, se uma organização está testando repositórios de código, o que ela considera uma aplicação? Semelhante ao crescimento do CVSSv4, a próxima edição do Top Ten pode precisar ajustar a análise e a pontuação para dar conta de uma indústria em constante mudança. + +## Fatores de Dados + +Existem fatores de dados listados para cada uma das categorias do Top Ten; aqui está o que eles significam: + +**CWEs Mapeadas:** O número de CWEs mapeadas para uma categoria pela equipe do Top Ten. + +**Taxa de Incidência:** A taxa de incidência é a porcentagem de aplicações vulneráveis àquela CWE dentro da população testada por aquela organização para aquele ano. + +**Exploit Ponderado:** A subpontuação de Exploit dos scores CVSSv2 e CVSSv3 atribuídos a CVEs mapeadas para CWEs, normalizada e colocada em uma escala de 10 pontos. + +**Impacto Ponderado:** A subpontuação de Impacto dos scores CVSSv2 e CVSSv3 atribuídos a CVEs mapeadas para CWEs, normalizada e colocada em uma escala de 10 pontos. + +**Cobertura (de Teste):** A porcentagem de aplicações testadas por todas as organizações para uma determinada CWE. + +**Total de Ocorrências:** Número total de aplicações em que foram encontradas as CWEs mapeadas para uma categoria. + +**Total de CVEs:** Número total de CVEs no banco de dados do NVD que foram mapeadas para as CWEs de uma categoria. + +**Fórmula:** (Taxa de Incidência Máxima % _ 1000) + (Cobertura Máxima % _ 100) + (Média de Exploit _ 10) + (Média de Impacto _ 20) + (Soma de Ocorrências / 10000) = Pontuação de Risco diff --git a/2025/docs/pt-BR/0x03_2025-Establishing_a_Modern_Application_Security_Program.md b/2025/docs/pt-BR/0x03_2025-Establishing_a_Modern_Application_Security_Program.md new file mode 100644 index 000000000..663be48c0 --- /dev/null +++ b/2025/docs/pt-BR/0x03_2025-Establishing_a_Modern_Application_Security_Program.md @@ -0,0 +1,147 @@ +# Estabelecendo um Programa Moderno de Segurança de Aplicações + +As listas OWASP Top Ten são documentos de conscientização, destinados a dar visibilidade aos riscos mais críticos de cada tópico que abordam. Elas não pretendem ser uma lista completa, mas apenas um ponto de partida. Em versões anteriores desta lista, prescrevemos o início de um programa de segurança de aplicações como a melhor forma de evitar esses riscos e muitos outros. Nesta seção, abordaremos como iniciar e construir um programa moderno de segurança de aplicações. + +Se você já possui um programa de segurança de aplicações, considere realizar uma avaliação de maturidade utilizando o [OWASP SAMM (Software Assurance Maturity Model)](https://owasp.org/www-project-samm/) ou o DSOMM (DevSecOps Maturity Model). Esses modelos de maturidade são abrangentes e exaustivos, podendo ser usados para ajudá-lo a entender onde focar melhor seus esforços para expandir e amadurecer seu programa. **Observação:** você não precisa fazer tudo o que está no OWASP SAMM ou no DSOMM para realizar um bom trabalho; eles servem para guiá-lo e oferecer diversas opções. Não foram feitos para oferecer padrões inalcançáveis ou descrever programas inacessíveis financeiramente. Eles são amplos para oferecer a você muitas ideias e opções. + +Se você está começando um programa do zero, ou se considera o OWASP SAMM ou o DSOMM "demais" para o seu time no momento, revise os conselhos a seguir. + +### 1. Estabeleça uma Abordagem de Portfólio Baseada em Risco: + +- Identifique as necessidades de proteção do seu portfólio de aplicações sob uma perspectiva de negócio. Isso deve ser impulsionado, em parte, por leis de privacidade e outras regulamentações relevantes para o ativo de dados que está sendo protegido. +- Estabeleça um [modelo comum de classificação de risco](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) com um conjunto consistente de fatores de probabilidade e impacto que reflitam a tolerância ao risco da sua organização. +- Meça e priorize todas as suas aplicações e APIs adequadamente. Adicione os resultados ao seu [Configuration Management Database (CMDB)](https://de.wikipedia.org/wiki/Configuration_Management_Database). +- Estabeleça diretrizes de garantia para definir adequadamente a cobertura e o nível de rigor exigido. + +### 2. Viabilize com uma Fundação Forte: + +- Estabeleça um conjunto de políticas e padrões focados que forneçam uma linha de base (_baseline_) de segurança de aplicações para todas as equipes de desenvolvimento seguirem. +- Defina um conjunto comum de controles de segurança reutilizáveis que complementem essas políticas e padrões, fornecendo orientações de design e desenvolvimento sobre seu uso. +- Estabeleça um currículo de treinamento em segurança de aplicações que seja obrigatório e direcionado a diferentes funções e tópicos de desenvolvimento. + +### 3. Integre a Segurança aos Processos Existentes: + +- Defina e integre atividades de implementação e verificação segura aos processos operacionais e de desenvolvimento existentes. +- As atividades incluem modelagem de ameaças (_threat modeling_), design seguro e revisão de design, codificação segura e revisão de código, testes de intrusão (_penetration testing_) e remediação. +- Forneça especialistas no assunto (_SMEs_) e serviços de suporte para que as equipes de desenvolvimento e de projeto tenham sucesso. +- Revise seu ciclo de vida de desenvolvimento de sistemas (_SDLC_) atual e todas as atividades, ferramentas, políticas e processos de segurança de software e, em seguida, documente-os. +- Para novos softwares, adicione uma ou mais atividades de segurança a cada fase do _SDLC_. Abaixo, oferecemos sugestões do que pode ser feito. Garanta que essas novas atividades sejam realizadas em cada novo projeto ou iniciativa de software; dessa forma, você saberá que cada novo pedaço de software será entregue com uma postura de segurança aceitável para sua organização. +- Selecione suas atividades para garantir que seu produto final atenda a um nível de risco aceitável para sua organização. +- Para softwares existentes (às vezes chamados de legado), você desejará ter um plano de manutenção formal; procure ideias de como manter aplicações seguras na seção chamada 'Operações e Gerenciamento de Mudanças'. + +### 4. Educação em Segurança de Aplicações: + +- Considere iniciar um programa de _security champions_ ou um programa de educação geral em segurança para seus desenvolvedores (às vezes chamado de programa de _advocacy_ ou conscientização de segurança) para ensiná-los tudo o que você gostaria que eles soubessem. Isso os manterá atualizados, ajudará a saber como realizar seu trabalho de forma segura e tornará a cultura de segurança onde você trabalha mais positiva. Frequentemente, isso também melhora a confiança entre as equipes e cria uma relação de trabalho mais feliz. A OWASP apoia você nisso com o [OWASP Security Champions Guide](https://securitychampions.owasp.org/), que está sendo expandido passo a passo. +- O Projeto de Educação da OWASP fornece materiais de treinamento para ajudar a educar desenvolvedores em segurança de aplicações web. Para aprendizado prático sobre vulnerabilidades, experimente o [OWASP Juice Shop Project](https://owasp.org/www-project-juice-shop/) ou o [OWASP WebGoat](https://owasp.org/www-project-webgoat/). Para manter-se atualizado, participe de uma [Conferência OWASP AppSec](https://owasp.org/events/), treinamentos em conferências ou reuniões de um [Chapter OWASP](https://owasp.org/chapters/) local. + +### 5. Forneça Visibilidade para a Gestão: + +- Gerencie com métricas. Direcione melhorias e decisões de financiamento com base em métricas e dados de análise capturados. As métricas incluem a adesão a práticas e atividades de segurança, vulnerabilidades introduzidas, vulnerabilidades mitigadas, cobertura de aplicações, densidade de defeitos por tipo e contagem de instâncias, etc. +- Analise dados das atividades de implementação e verificação para procurar a causa raiz e padrões de vulnerabilidade, visando impulsionar melhorias estratégicas e sistêmicas em toda a empresa. Aprenda com os erros e ofereça incentivos positivos para promover melhorias. + +--- + +## Estabeleça e Use Processos de Segurança Repetíveis e Controles de Segurança Padrão + +### Fase de Requisitos e Gerenciamento de Recursos: + +- Colete e negocie os requisitos de negócio para uma aplicação com a área de negócios, incluindo os requisitos de proteção em relação à confidencialidade, autenticidade, integridade e disponibilidade de todos os ativos de dados, além da lógica de negócio esperada. +- Compile os requisitos técnicos, incluindo requisitos de segurança funcionais e não funcionais. A OWASP recomenda o uso do [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) como guia para definir os requisitos de segurança de sua(s) aplicação(ões). +- Planeje e negocie o orçamento que cubra todos os aspectos de design, construção, testes e operação, incluindo atividades de segurança. +- Adicione atividades de segurança ao cronograma do seu projeto. +- Apresente-se como o representante de segurança no _kick-off_ do projeto, para que saibam com quem falar. + +### Solicitação de Propostas (RFP) e Contratação: + +- Negocie os requisitos com desenvolvedores internos ou externos, incluindo diretrizes e requisitos de segurança em relação ao seu programa de segurança, por exemplo: _SDLC_, melhores práticas. +- Avalie o cumprimento de todos os requisitos técnicos, incluindo uma fase de planejamento e design. +- Negocie todos os requisitos técnicos, incluindo design, segurança e acordos de nível de serviço (_SLA_). +- Adote modelos e checklists, como o [OWASP Secure Software Contract Annex](https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex).
**Nota:** _O anexo é baseado na lei de contratos dos EUA, portanto, consulte assessoria jurídica qualificada antes de usar o modelo._ + +### Fase de Planejamento e Design: + +- Negocie o planejamento e o design com os desenvolvedores e partes interessadas internas, como especialistas em segurança. +- Defina a arquitetura de segurança, controles, contramedidas e revisões de design apropriadas às necessidades de proteção e ao nível de ameaça esperado. Isso deve ser apoiado por especialistas em segurança. +- Em vez de adaptar a segurança em suas aplicações e APIs posteriormente, é muito mais econômico projetar a segurança desde o início. A OWASP recomenda os [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) e os [OWASP Proactive Controls](https://top10proactive.owasp.org/) como um bom ponto de partida para orientações sobre como projetar a segurança incluída desde o princípio. +- Realize modelagem de ameaças (_threat modeling_); veja [OWASP Cheat Sheet: Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). +- Ensine conceitos e padrões de design seguro aos seus arquitetos de software e peça que os adicionem aos seus projetos sempre que possível. +- Examine os fluxos de dados com seus desenvolvedores. +- Adicione _user stories_ de segurança ao lado de todas as suas outras _user stories_. + +### Ciclo de Vida de Desenvolvimento Seguro: + +- Para melhorar o processo que sua organização segue ao construir aplicações e APIs, a OWASP recomenda o [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/). Este modelo ajuda as organizações a formular e implementar uma estratégia para segurança de software adaptada aos riscos específicos enfrentados pela organização. +- Forneça treinamento de codificação segura para seus desenvolvedores de software e qualquer outro treinamento que você considere útil para criar aplicações mais robustas e seguras. +- Revisão de código; veja [OWASP Cheat Sheet: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). +- Dê ferramentas de segurança aos seus desenvolvedores e ensine-os a usá-las, especialmente scanners de análise estática (_SAST_), análise de composição de software (_SCA_), segredos (_secrets_) e [Infraestrutura como Código (IaC)](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html). +- Crie _guardrails_ para seus desenvolvedores, se possível (salvaguardas técnicas para direcioná-los a escolhas mais seguras). +- Construir controles de segurança fortes e utilizáveis é difícil. Ofereça padrões seguros (_secure defaults_) sempre que possível e crie "_paved roads_" (tornar o caminho mais fácil também o caminho mais seguro para fazer algo, a escolha preferencial óbvia) sempre que possível. Os [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) são um bom ponto de partida para desenvolvedores, e muitos frameworks modernos já vêm com controles de segurança padrão e eficazes para autorização, validação, prevenção de CSRF, etc. +- Forneça plugins de _IDE_ relacionados à segurança para seus desenvolvedores e incentive seu uso. +- Forneça uma ferramenta de gerenciamento de segredos (_secret management_), licenças e documentação sobre como usá-la. +- Forneça uma IA privada para uso, idealmente configurada com um servidor RAG repleto de documentação de segurança útil, _prompts_ que sua equipe escreveu para melhores resultados e um servidor MCP que chame as ferramentas de segurança escolhidas por sua organização. Ensine-os a usar a IA de forma segura, porque eles vão usá-la de qualquer maneira. + +### Estabeleça Testes Contínuos de Segurança de Aplicações: + +- Teste as funções técnicas e a integração com a arquitetura de TI e coordene os testes de negócio. +- Crie casos de teste de "uso" e "abuso" sob perspectivas técnicas e de negócio. +- Gerencie os testes de segurança de acordo com os processos internos, as necessidades de proteção e o nível de ameaça assumido pela aplicação. +- Forneça ferramentas de teste de segurança (_fuzzers_, _DAST_, etc.), um local seguro para testar e treinamento sobre como usá-las, OU realize os testes por eles OU contrate um testador. +- Se você exigir um alto nível de garantia, considere um teste de intrusão formal, bem como testes de estresse e testes de desempenho. +- Trabalhe com seus desenvolvedores para ajudá-los a decidir o que precisam corrigir nos relatórios de bugs e garanta que seus gestores deem tempo para que isso seja feito. + +### Implantação (_Rollout_): + +- Coloque a aplicação em operação e migre de aplicações usadas anteriormente, se necessário. +- Finalize toda a documentação, incluindo o banco de dados de gerenciamento de mudanças (CMDB) e a arquitetura de segurança. + +### Operações e Gerenciamento de Mudanças: + +- As operações devem incluir diretrizes para a gestão de segurança da aplicação (ex: gestão de patches). +- Aumente a conscientização de segurança dos usuários e gerencie conflitos entre usabilidade vs. segurança. +- Planeje e gerencie mudanças, ex: migrar para novas versões da aplicação ou outros componentes como SO, _middleware_ e bibliotecas. +- Garanta que todas as aplicações estejam em seu inventário, com todos os detalhes importantes documentados. Atualize toda a documentação, incluindo no CMDB e na arquitetura de segurança, controles e contramedidas, incluindo quaisquer _runbooks_ ou documentação de projeto. +- Execute registro de logs, monitoramento e alertas para todas as aplicações. Adicione se estiver faltando. +- Crie processos para atualizações e correções (_patching_) eficazes e eficientes. +- Crie cronogramas de varredura regular (idealmente dinâmica, estática, segredos, IaC e análise de composição de software). +- _SLAs_ para correção de bugs de segurança. +- Forneça uma maneira para funcionários (e idealmente também seus clientes) reportarem bugs. +- Estabeleça uma equipe treinada de resposta a incidentes que entenda como são os ataques de software e utilize ferramentas de observabilidade. +- Execute ferramentas de bloqueio ou blindagem para deter ataques automatizados. +- Endurecimento (_hardening_) anual (ou mais frequente) de configurações. +- Teste de intrusão pelo menos anual (dependendo do nível de garantia exigido para sua aplicação). +- Estabeleça processos e ferramentas para o endurecimento e proteção de sua cadeia de suprimentos de software. +- Estabeleça e atualize o planejamento de continuidade de negócios e recuperação de desastres que inclua suas aplicações mais importantes e as ferramentas usadas para mantê-las. + +### Desativação de Sistemas: + +- Quaisquer dados exigidos devem ser arquivados. Todos os outros dados devem ser apagados de forma segura. +- Desative a aplicação com segurança, incluindo a exclusão de contas, funções e permissões não utilizadas. +- Defina o estado de sua aplicação como "desativada" no CMDB. + +--- + +## Usando o OWASP Top 10 como um Padrão + +O OWASP Top 10 é prioritariamente um documento de conscientização. No entanto, isso não impediu as organizações de usá-lo como um padrão _de facto_ de AppSec da indústria desde sua criação em 2003. Se você deseja usar o OWASP Top 10 como um padrão de codificação ou teste, saiba que ele é o mínimo indispensável e apenas um ponto de partida. + +Uma das dificuldades de usar o OWASP Top 10 como padrão é que documentamos riscos de AppSec, e não necessariamente problemas facilmente testáveis. Por exemplo, [A06:2025-Design Inseguro](A06_2025-Insecure_Design.md) está além do escopo da maioria das formas de teste. Outro exemplo é testar se o registro de logs e o monitoramento eficazes estão implementados e em uso, o que só pode ser feito com entrevistas e solicitando uma amostragem de respostas a incidentes eficazes. Uma ferramenta de análise de código estática pode procurar pela ausência de logs, mas pode ser impossível determinar se a lógica de negócio ou o controle de acesso está registrando violações de segurança críticas. Testadores de intrusão podem apenas ser capazes de determinar que invocaram a resposta a incidentes em um ambiente de teste, o qual raramente é monitorado da mesma forma que a produção. + +Aqui estão nossas recomendações para quando é apropriado usar o OWASP Top 10: + +| Caso de Uso | OWASP Top 10 2025 | OWASP Application Security Verification Standard | +| :----------------------------- | :------------------- | :----------------------------------------------- | +| Conscientização | Sim | | +| Treinamento | Nível de entrada | Abrangente | +| Design e arquitetura | Ocasionalmente | Sim | +| Padrão de codificação | Mínimo indispensável | Sim | +| Revisão de Código Seguro | Mínimo indispensável | Sim | +| Checklist de revisão por pares | Mínimo indispensável | Sim | +| Teste de unidade | Ocasionalmente | Sim | +| Teste de integração | Ocasionalmente | Sim | +| Teste de intrusão | Mínimo indispensável | Sim | +| Suporte de ferramentas | Mínimo indispensável | Sim | +| Cadeia de Suprimentos Segura | Ocasionalmente | Sim | + +Encorajamos qualquer pessoa que queira adotar um padrão de segurança de aplicações a usar o [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) (ASVS), pois ele foi projetado para ser verificável e testável, podendo ser usado em todas as partes de um ciclo de vida de desenvolvimento seguro. + +O ASVS é a única escolha aceitável para fornecedores de ferramentas. Ferramentas não podem detectar, testar ou proteger de forma abrangente contra o OWASP Top 10 devido à natureza de vários dos riscos presentes, com referência ao [A06:2025-Design Inseguro](A06_2025-Insecure_Design.md). A OWASP desestimula quaisquer alegações de cobertura total do OWASP Top 10, porque isso é simplesmente falso. diff --git a/2025/docs/pt-BR/A01_2025-Broken_Access_Control.md b/2025/docs/pt-BR/A01_2025-Broken_Access_Control.md new file mode 100644 index 000000000..cd0069914 --- /dev/null +++ b/2025/docs/pt-BR/A01_2025-Broken_Access_Control.md @@ -0,0 +1,163 @@ +# A01:2025 – Controle de Acesso Quebrado (Broken Access Control) ![icon](../assets/TOP_10_Icons_Final_Broken_Access_Control.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +Mantendo sua posição nº 1 no Top 10, foi constatado que 100% das aplicações testadas apresentavam alguma forma de controle de acesso quebrado. As CWEs notáveis incluídas são _CWE-200: Exposure of Sensitive Information to an Unauthorized Actor_, _CWE-201: Exposure of Sensitive Information Through Sent Data_, _CWE-918 Server-Side Request Forgery (SSRF)_ e _CWE-352: Cross-Site Request Forgery (CSRF)_. Esta categoria possui o maior número de ocorrências nos dados contribuídos e o segundo maior número de CVEs relacionadas. + +## 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 +
40 + 20.15% + 3.74% + 100.00% + 42.93% + 7.04 + 3.84 + 1,839,701 + 32,654 +
+ +## Descrição + +O controle de acesso aplica políticas para que os usuários não possam agir fora de suas permissões pretendidas. As falhas normalmente levam à divulgação não autorizada de informações, modificação ou destruição de todos os dados, ou à execução de uma função de negócio fora dos limites do usuário. Vulnerabilidades comuns de controle de acesso incluem: + +- Violação do princípio do menor privilégio (least privilege), comumente conhecido como "negar por padrão" (deny by default), onde o acesso deveria ser concedido apenas para capacidades, papéis ou usuários específicos, mas está disponível para qualquer pessoa. +- **Bypass** de verificações de controle de acesso ao modificar a URL (manipulação de parâmetros ou navegação forçada), o estado interno da aplicação ou a página HTML, ou ao utilizar uma ferramenta de ataque que modifica requisições de **API**. +- Permitir a visualização ou edição da conta de outra pessoa ao fornecer seu identificador exclusivo (**IDOR** – _Insecure Direct Object References_). +- Uma **API** acessível com falta de controles de acesso para POST, PUT e DELETE. +- Elevação de privilégio. Agir como um usuário sem estar logado ou obter privilégios além dos esperados para o usuário logado (ex: acesso de administrador). +- Manipulação de **metadados**, como o reuso (_replaying_) ou adulteração de um **token** de controle de acesso **JWT** (_JSON Web Token_), um **cookie** ou campo oculto manipulado para elevar privilégios, ou abuso da invalidação de **JWT**. +- Configuração incorreta de **CORS** que permite acesso à **API** a partir de origens não autorizadas ou não confiáveis. +- Navegação forçada (_force browsing_ ou adivinhação de URLs) para páginas autenticadas como um usuário não autenticado ou para páginas privilegiadas como um usuário comum. + +## Como Prevenir + +O controle de acesso só é eficaz quando implementado em código confiável no lado do servidor ou em **APIs** _serverless_, onde o **atacante** não pode modificar a verificação de controle de acesso ou os **metadados**. + +- Exceto para recursos públicos, negue por padrão (_deny by default_). +- Implemente mecanismos de controle de acesso uma única vez e reutilize-os em toda a aplicação, incluindo a minimização do uso de _Cross-Origin Resource Sharing_ (**CORS**). +- Os modelos de controle de acesso devem reforçar a propriedade do registro, em vez de permitir que os usuários criem, leiam, atualizem ou excluam qualquer registro. +- Requisitos exclusivos de limites de negócio da aplicação devem ser impostos por modelos de domínio. +- Desative a listagem de diretórios do servidor web e garanta que **metadados** de arquivos (ex: `.git`) e arquivos de backup não estejam presentes nas raízes web (_web roots_). +- Registre (**log**) falhas de controle de acesso e alerte os administradores quando apropriado (ex: falhas repetidas). +- Implemente limites de taxa (_rate limits_) no acesso a **APIs** e controladores para minimizar o dano causado por ferramentas de ataque automatizadas. +- Identificadores de sessão com estado (_stateful_) devem ser invalidados no servidor após o logout. **Tokens JWT** sem estado (_stateless_) devem ter vida curta para minimizar a janela de oportunidade para um **atacante**. Para **JWTs** de longa duração, considere o uso de _refresh tokens_ e siga os padrões OAuth para revogar o acesso. +- Utilize conjuntos de ferramentas (_toolkits_) ou padrões bem estabelecidos que forneçam controles de acesso simples e declarativos. + +Desenvolvedores e equipes de QA devem incluir testes funcionais de controle de acesso em seus testes unitários e de integração. + +## Exemplos de Cenários de Ataque + +**Cenário #1:** A aplicação utiliza dados não verificados em uma chamada SQL que acessa informações da conta: + +```java +pstmt.setString(1, request.getParameter("acct")); +ResultSet results = pstmt.executeQuery( ); +``` + +Um **atacante** pode simplesmente modificar o parâmetro 'acct' no navegador para enviar qualquer número de conta desejado. Se não for corretamente verificado, o **atacante** pode acessar a conta de qualquer usuário. + +``` +https://example.com/app/accountInfo?acct=notmyacct +``` + +**Cenário #2:** Um **atacante** simplesmente força a navegação para URLs alvo. Direitos de administrador são necessários para acessar a página administrativa. + +``` +https://example.com/app/getappInfo +https://example.com/app/admin_getappInfo +``` + +Se um usuário não autenticado conseguir acessar qualquer uma das páginas, trata-se de uma falha. Se um não-administrador conseguir acessar a página de administração, isso também é uma falha. + +**Cenário #3:** Uma aplicação coloca todo o seu controle de acesso no front-end. Embora o **atacante** não consiga chegar a `[https://example.com/app/admin_getappInfo](https://example.com/app/admin_getappInfo)` devido ao código JavaScript executado no navegador, ele pode simplesmente executar: + +```bash +$ curl https://example.com/app/admin_getappInfo +``` + +a partir da linha de comando. + +## Referências + +- [OWASP Proactive Controls: C1: Implement Access Control](https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/) +- [OWASP Application Security Verification Standard: V8 Authorization](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) +- [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) +- [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) +- [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) +- [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) + +## Lista de CWEs Mapeadas + +- [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) +- [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) +- [CWE-36 Absolute Path Traversal](https://cwe.mitre.org/data/definitions/36.html) +- [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) +- [CWE-61 UNIX Symbolic Link (Symlink) Following](https://cwe.mitre.org/data/definitions/61.html) +- [CWE-65 Windows Hard Link](https://cwe.mitre.org/data/definitions/65.html) +- [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) +- [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) +- [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) +- [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) +- [CWE-281 Improper Preservation of Permissions](https://cwe.mitre.org/data/definitions/281.html) +- [CWE-282 Improper Ownership Management](https://cwe.mitre.org/data/definitions/282.html) +- [CWE-283 Unverified Ownership](https://cwe.mitre.org/data/definitions/283.html) +- [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) +- [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) +- [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) +- [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) +- [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) +- [CWE-379 Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) +- [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) +- [CWE-424 Improper Protection of Alternate Path](https://cwe.mitre.org/data/definitions/424.html) +- [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) +- [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) +- [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) +- [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) +- [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) +- [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) +- [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) +- [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) +- [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) +- [CWE-615 Inclusion of Sensitive Information in Source Code Comments](https://cwe.mitre.org/data/definitions/615.html) +- [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) +- [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) +- [CWE-732 Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html) +- [CWE-749 Exposed Dangerous Method or Function](https://cwe.mitre.org/data/definitions/749.html) +- [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) +- [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) +- [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) +- [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) +- [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) diff --git a/2025/docs/pt-BR/A02_2025-Security_Misconfiguration.md b/2025/docs/pt-BR/A02_2025-Security_Misconfiguration.md new file mode 100644 index 000000000..c454ff6a4 --- /dev/null +++ b/2025/docs/pt-BR/A02_2025-Security_Misconfiguration.md @@ -0,0 +1,120 @@ +# A02:2025 – Configuração Insegura (Security Misconfiguration) ![icon](../assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +Subindo da 5ª posição na edição anterior, foi constatado que 100% das aplicações testadas apresentavam alguma forma de configuração incorreta, com uma taxa média de incidência de 3,00% e mais de 719 mil ocorrências de CWEs (_Common Weakness Enumeration_) nesta categoria de risco. Com a migração crescente para softwares altamente configuráveis, não é surpresa ver esta categoria subir no ranking. As CWEs notáveis incluídas são _CWE-16 Configuration_ e _CWE-611 Improper Restriction of XML External Entity Reference (XXE)_. + +## 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 +
16 + 27.70% + 3.00% + 100.00% + 52.35% + 7.96 + 3.97 + 719,084 + 1,375 +
+ +## Descrição + +A configuração insegura ocorre quando um sistema, aplicação ou serviço de nuvem é configurado incorretamente do ponto de vista de segurança, criando vulnerabilidades. + +A aplicação pode estar vulnerável se: + +- Faltar o endurecimento de segurança (_security hardening_) apropriado em qualquer parte da stack da aplicação ou se houver permissões configuradas incorretamente em serviços de nuvem. +- Recursos desnecessários estiverem habilitados ou instalados (ex: portas, serviços, páginas, contas, **frameworks** de teste ou privilégios desnecessários). +- Contas padrão e suas senhas ainda estiverem habilitadas e inalteradas. +- Houver falta de uma configuração centralizada para interceptar mensagens de erro excessivas. O tratamento de erros revela _stack traces_ ou outras mensagens de erro excessivamente informativas aos usuários. +- Para sistemas atualizados, os recursos de segurança mais recentes estiverem desativados ou não configurados com segurança. +- Houver priorização excessiva da compatibilidade reversa, levando a configurações inseguras. +- As configurações de segurança nos servidores de aplicação, **frameworks** (ex: Struts, Spring, ASP.NET), bibliotecas, bancos de dados, etc., não estiverem definidas com valores seguros. +- O servidor não enviar **headers** ou diretivas de segurança, ou se estes não estiverem configurados com valores seguros. + +Sem um processo de endurecimento (_hardening_) de configuração de segurança de aplicação concentrado e repetível, os sistemas correm um risco maior. + +## Como Prevenir + +Processos de instalação seguros devem ser implementados, incluindo: + +- Um processo de _hardening_ repetível que permita a implantação rápida e fácil de outro ambiente devidamente bloqueado. Os ambientes de desenvolvimento, QA e produção devem ser configurados de forma idêntica, com credenciais diferentes usadas em cada um. Este processo deve ser automatizado para minimizar o esforço necessário para configurar um novo ambiente seguro. +- Uma plataforma mínima, sem quaisquer recursos, componentes, documentação ou amostras desnecessárias. Remova ou não instale recursos e **frameworks** não utilizados. +- Uma tarefa para revisar e atualizar as configurações de acordo com todas as notas de segurança, atualizações e **patches** como parte do processo de gerenciamento de **patches** (veja [A03 Falhas na Cadeia de Suprimentos de Software](A03_2025-Software_Supply_Chain_Failures.md)). Revise as permissões de armazenamento em nuvem (ex: permissões de buckets S3). +- Uma arquitetura de aplicação segmentada que forneça separação eficaz e segura entre componentes ou usuários (_tenants_), com segmentação, conteinerização ou grupos de segurança de nuvem (ACLs). +- Envio de diretivas de segurança para os clientes, ex: **headers** de segurança. +- Um processo automatizado para verificar a eficácia das configurações e definições em todos os ambientes. +- Adição proativa de uma configuração central para interceptar mensagens de erro excessivas como reserva (_backup_). +- Se essas verificações não forem automatizadas, elas devem ser verificadas manualmente, no mínimo, anualmente. +- Utilize federação de identidade, credenciais de curta duração ou mecanismos de acesso baseados em funções (RBAC) fornecidos pela plataforma subjacente, em vez de incorporar chaves estáticas ou segredos (_secrets_) no código, arquivos de configuração ou **pipelines**. + +## Exemplos de Cenários de Ataque + +**Cenário #1:** O servidor de aplicação vem com aplicações de exemplo não removidas do servidor de produção. Essas aplicações de exemplo têm falhas de segurança conhecidas que os **atacantes** usam para comprometer o servidor. Suponha que uma dessas aplicações seja o console de administração e as contas padrão não foram alteradas. Nesse caso, o **atacante** faz o login com a senha padrão e assume o controle. + +**Cenário #2:** A listagem de diretórios não está desativada no servidor. Um **atacante** descobre que pode simplesmente listar os diretórios. O **atacante** encontra e baixa as classes Java compiladas, que ele descompila e faz engenharia reversa para visualizar o código. O **atacante**, então, encontra uma falha grave de controle de acesso na aplicação. + +**Cenário #3:** A configuração do servidor de aplicação permite que mensagens de erro detalhadas, como _stack traces_, sejam retornadas aos usuários. Isso potencialmente expõe informações sensíveis ou falhas subjacentes, como versões de componentes que são conhecidamente vulneráveis. + +**Cenário #4:** Um provedor de serviços de nuvem (CSP) define por padrão permissões de compartilhamento abertas para a Internet. Isso permite que dados sensíveis armazenados no armazenamento em nuvem sejam acessados. + +## Referências + +- [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) +- [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) +- [Application Security Verification Standard V13 Configuration](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V13-Configuration.md) +- [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) +- [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) +- [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) +- ScienceDirect: Security Misconfiguration + +## Lista de CWEs Mapeadas + +- [CWE-5 J2EE Misconfiguration: Data Transmission Without Encryption](https://cwe.mitre.org/data/definitions/5.html) +- [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) +- [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) +- [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) +- [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) +- [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) +- [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) +- [CWE-489 Active Debug Code](https://cwe.mitre.org/data/definitions/489.html) +- [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) +- [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) +- [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) +- [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) +- [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) +- [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) +- [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) +- [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) diff --git a/2025/docs/pt-BR/A03_2025-Software_Supply_Chain_Failures.md b/2025/docs/pt-BR/A03_2025-Software_Supply_Chain_Failures.md new file mode 100644 index 000000000..ccddd958a --- /dev/null +++ b/2025/docs/pt-BR/A03_2025-Software_Supply_Chain_Failures.md @@ -0,0 +1,152 @@ +# A03:2025 – Falhas na Cadeia de Suprimentos de Software ![icon](../assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +Esta categoria foi a mais votada na pesquisa da comunidade para o Top 10, com exatamente 50% dos entrevistados classificando-a como a nº 1. Desde sua aparição inicial no Top 10 de 2013 como "A9 – Utilização de Componentes com Vulnerabilidades Conhecidas", o risco cresceu em escopo para incluir todas as falhas na cadeia de suprimentos (_supply chain_), não apenas aquelas que envolvem vulnerabilidades conhecidas. Apesar desse aumento de escopo, as falhas na cadeia de suprimentos continuam sendo um desafio para identificação, com apenas 11 vulnerabilidades (CVEs) possuindo as CWEs relacionadas. No entanto, quando testada e reportada nos dados contribuídos, esta categoria apresenta a maior taxa média de incidência, de 5,19%. As CWEs relevantes são _CWE-477: Use of Obsolete Function_, _CWE-1104: Use of Unmaintained Third Party Components_, _CWE-1329: Reliance on Component That is Not Updateable_ e _CWE-1395: Dependency on Vulnerable Third-Party Component_. + +## 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 +
6 + 9.56% + 5.72% + 65.42% + 27.47% + 8.17 + 5.23 + 215,248 + 11 +
+ +## Descrição + +Falhas na cadeia de suprimentos de software são interrupções ou outros comprometimentos no processo de construção, distribuição ou atualização de software. Frequentemente, são causadas por vulnerabilidades ou alterações maliciosas em códigos de terceiros, ferramentas ou outras dependências das quais o sistema depende. + +Você provavelmente está **vulnerável** se: + +- Você não rastreia cuidadosamente as versões de todos os componentes que utiliza (tanto no lado do cliente quanto no servidor). Isso inclui componentes usados diretamente, bem como dependências aninhadas (transitivas). +- O software é vulnerável, sem suporte ou desatualizado. Isso inclui o sistema operacional, servidor web/aplicação, sistema de gerenciamento de banco de dados (DBMS), aplicações, **APIs** e todos os componentes, ambientes de **runtime** e bibliotecas. +- Você não realiza varreduras de vulnerabilidades regularmente e não assina boletins de segurança relacionados aos componentes que utiliza. +- Você não possui um processo de gerenciamento de mudanças ou rastreamento de alterações em sua cadeia de suprimentos, incluindo o rastreamento de IDEs, extensões e atualizações de IDE, alterações no repositório de código da sua organização, **sandboxes**, repositórios de imagens e bibliotecas, a forma como os artefatos são criados e armazenados, etc. Cada parte da sua cadeia de suprimentos deve ser documentada, especialmente as mudanças. +- Você não realizou o endurecimento (_hardening_) de cada parte da sua cadeia de suprimentos, com foco especial no controle de acesso e na aplicação do menor privilégio. +- Seus sistemas de cadeia de suprimentos não possuem separação de funções (_separation of duties_). Nenhuma pessoa sozinha deve ser capaz de escrever o código e promovê-lo até a produção sem a supervisão de outro ser humano. +- Componentes de fontes não confiáveis, em qualquer parte da stack tecnológica, são usados ou podem impactar ambientes de produção. +- Você não corrige ou atualiza a plataforma subjacente, **frameworks** e dependências de maneira oportuna e baseada em riscos. Isso acontece comumente em ambientes onde o **patching** é uma tarefa mensal ou trimestral sob controle de mudanças, deixando as organizações expostas por dias ou meses a riscos desnecessários antes de corrigir as vulnerabilidades. +- Os desenvolvedores de software não testam a compatibilidade de bibliotecas atualizadas ou corrigidas. +- Você não protege as configurações de cada parte do seu sistema (consulte [A02:2025 – Configuração Insegura](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/)). +- Seu **pipeline** de CI/CD possui segurança mais fraca do que os sistemas que ele constrói e implanta, especialmente se for complexo. + +## Como Prevenir + +Deve haver um processo de gerenciamento de **patches** para: + +- Gerar e gerenciar centralizadamente a Lista de Materiais de Software (**SBOM** – _Software Bill of Materials_) de todo o seu software. +- Rastrear não apenas suas dependências diretas, mas também as transitivas, e assim por diante. +- Reduzir a superfície de ataque removendo dependências não utilizadas, recursos desnecessários, componentes, arquivos e documentação. +- Inventariar continuamente as versões de componentes tanto do lado do cliente quanto do servidor (ex: **frameworks**, bibliotecas) e suas dependências usando ferramentas como OWASP Dependency Track, OWASP Dependency Check, retire.js, etc. +- Monitorar continuamente fontes como CVE (_Common Vulnerability and Exposures_), NVD (_National Vulnerability Database_) e [Open Source Vulnerabilities (OSV)](https://osv.dev/) em busca de vulnerabilidades nos componentes utilizados. Use ferramentas de análise de composição de software (SCA), cadeia de suprimentos ou ferramentas de **SBOM** focadas em segurança para automatizar o processo. Assine alertas de vulnerabilidades de segurança relacionadas aos componentes que você usa. +- Obter componentes apenas de fontes oficiais (confiáveis) através de links seguros. Prefira pacotes assinados para reduzir a chance de incluir um componente modificado ou malicioso (consulte [A08:2025 – Falhas de Integridade de Software e Dados](https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/)). +- Escolher deliberadamente qual versão de uma dependência utilizar e atualizar apenas quando houver necessidade. +- Monitorar bibliotecas e componentes que não possuem manutenção ou que não criam **patches** de segurança para versões antigas. Se a correção não for possível, considere migrar para uma alternativa. Caso não seja viável, considere implantar um **patch** virtual para monitorar, detectar ou proteger contra o problema descoberto. +- Atualizar regularmente seu CI/CD, IDE e qualquer outra ferramenta de desenvolvimento. +- Evitar a implantação de atualizações em todos os sistemas simultaneamente. Use implantações em estágios ou _canary deployments_ para limitar a exposição caso um fornecedor confiável seja comprometido. + +Deve haver um processo de gerenciamento de mudanças ou sistema de rastreamento para monitorar alterações em: + +- Configurações de CI/CD (todas as ferramentas de construção e **pipelines**) +- Repositórios de código +- Áreas de **sandbox** +- IDEs de desenvolvedores +- Ferramental de **SBOM** e artefatos criados +- Sistemas de registro (**logging**) e **logs** +- Integrações de terceiros, como SaaS +- Repositórios de artefatos +- Registros de contêineres + +Realize o _hardening_ dos seguintes sistemas, o que inclui habilitar MFA e restringir o IAM: + +- Seu repositório de código (o que inclui não armazenar segredos, proteger ramificações/_branches_ e realizar backups). +- Estações de trabalho de desenvolvedores (**patching** regular, MFA, monitoramento e mais). +- Seu servidor de build e CI/CD (separação de funções, controle de acesso, builds assinados, segredos com escopo de ambiente, **logs** à prova de adulteração, entre outros). +- Seus artefatos (garanta a integridade via proveniência, assinatura e carimbo de tempo; promova artefatos em vez de reconstruí-los para cada ambiente; garanta que os builds sejam imutáveis). +- Infraestrutura como código (gerenciada como qualquer código, incluindo o uso de PRs e controle de versão). + +Cada organização deve garantir um plano contínuo para monitoramento, triagem e aplicação de atualizações ou mudanças de configuração durante toda a vida útil da aplicação ou portfólio. + +## Exemplos de Cenários de Ataque + +**Cenário #1:** Um fornecedor confiável é comprometido com malware, levando ao comprometimento dos seus sistemas de computador quando você realiza a atualização. O exemplo mais famoso disso é provavelmente: + +- O comprometimento da SolarWinds em 2019, que levou ao comprometimento de aproximadamente 18.000 organizações. [https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) + +**Cenário #2:** Um fornecedor confiável é comprometido de tal forma que se comporta de maneira maliciosa apenas sob uma condição específica. + +- O roubo de US$ 1,5 bilhão da Bybit em 2025 foi causado por [um ataque à cadeia de suprimentos em um software de carteira (_wallet_)](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/) que só era executado quando a carteira alvo estava em uso. + +**Cenário #3:** O [ataque à cadeia de suprimentos `Shai-Hulud`](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) em 2025 foi o primeiro verme (_worm_) npm autopropagável bem-sucedido. Os ataques inseriram versões maliciosas de pacotes populares, que utilizavam um script pós-instalação para coletar e exfiltrar dados sensíveis para repositórios públicos do GitHub. O malware também detectava **tokens** npm no ambiente da vítima e os utilizava automaticamente para publicar versões maliciosas de qualquer pacote acessível. O verme atingiu mais de 500 versões de pacotes antes de ser interrompido pelo npm. Este ataque foi avançado, de rápida propagação e danoso; ao visar máquinas de desenvolvedores, demonstrou que os próprios desenvolvedores são agora alvos principais em ataques de cadeia de suprimentos. + +**Cenário #4:** Componentes normalmente rodam com os mesmos privilégios da própria aplicação, portanto, falhas em qualquer componente podem resultar em sério impacto. Tais falhas podem ser acidentais (ex: erro de codificação) ou intencionais (ex: um _backdoor_ em um componente). Alguns exemplos de vulnerabilidades exploráveis em componentes descobertos são: + +- CVE-2017-5638, uma vulnerabilidade de execução remota de código (RCE) no Struts 2 que permite a execução de código arbitrário no servidor, sendo responsabilizada por violações significativas. +- CVE-2021-44228 ("Log4Shell"), uma vulnerabilidade de dia zero de execução remota de código no Apache Log4j, responsabilizada por campanhas de ransomware, mineração de criptomoedas e outros ataques. + +## Referências + +- [OWASP Application Security Verification Standard: V15 Secure Coding and Architecture](https://owasp.org/www-project-application-security-verification-standard/) +- [OWASP Cheat Sheet Series: Dependency Graph SBOM](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) +- [OWASP Cheat Sheet Series: Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) +- [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) +- [OWASP CycloneDX](https://owasp.org/www-project-cyclonedx/) +- [OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling](https://owasp-aasvs.readthedocs.io/en/latest/v1.html) +- [OWASP Dependency Check (for Java and .NET libraries)](https://owasp.org/www-project-dependency-check/) +- OWASP Testing Guide - Map Application Architecture (OTG-INFO-010) +- [OWASP Virtual Patching Best Practices](https://owasp.org/www-community/Virtual_Patching_Best_Practices) +- [The Unfortunate Reality of Insecure Libraries](https://www.scribd.com/document/105692739/JeffWilliamsPreso-Sm) +- [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cve.org) +- [National Vulnerability Database (NVD)](https://nvd.nist.gov) +- [Retire.js for detecting known vulnerable JavaScript libraries](https://retirejs.github.io/retire.js/) +- [GitHub Advisory Database](https://github.com/advisories) +- Ruby Libraries Security Advisory Database and Tools +- [SAFECode Software Integrity Controls (PDF)](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +- [Glassworm supply chain attack](https://thehackernews.com/2025/10/self-spreading-glassworm-infects-vs.html) +- [PhantomRaven supply chain attack campaign](https://thehackernews.com/2025/10/phantomraven-malware-found-in-126-npm.html) + +## Lista de CWEs Mapeadas + +- [CWE-447 Use of Obsolete Function](https://cwe.mitre.org/data/definitions/447.html) +- [CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities](https://cwe.mitre.org/data/definitions/1035.html) +- [CWE-1104 Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html) +- [CWE-1329 Reliance on Component That is Not Updateable](https://cwe.mitre.org/data/definitions/1329.html) +- [CWE-1357 Reliance on Insufficiently Trustworthy Component](https://cwe.mitre.org/data/definitions/1357.html) +- [CWE-1395 Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html) diff --git a/2025/docs/pt-BR/A04_2025-Cryptographic_Failures.md b/2025/docs/pt-BR/A04_2025-Cryptographic_Failures.md new file mode 100644 index 000000000..7e5812033 --- /dev/null +++ b/2025/docs/pt-BR/A04_2025-Cryptographic_Failures.md @@ -0,0 +1,147 @@ +# A04:2025 – Falhas Criptográficas (Cryptographic Failures) ![icon](../assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +Descendo duas posições para o 4º lugar, esta fraqueza foca em falhas relacionadas à falta de criptografia, criptografia insuficientemente forte, vazamento de chaves criptográficas e erros correlatos. Três das CWEs (_Common Weakness Enumerations_) mais comuns neste risco envolveram o uso de geradores de números pseudoaleatórios fracos: _CWE-327 Use of a Broken or Risky Cryptographic Algorithm_, _CWE-331: Insufficient Entropy_, _CWE-1241: Use of Predictable Algorithm in Random Number Generator_ e _CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)_. + +## 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 +
32 + 13.77% + 3.80% + 100.00% + 47.74% + 7.23 + 3.90 + 1,665,348 + 2,185 +
+ +## Descrição + +De modo geral, todos os dados em trânsito devem ser criptografados na [camada de transporte](https://en.wikipedia.org/wiki/Transport_layer) ([camada OSI](https://en.wikipedia.org/wiki/OSI_model) 4). Obstáculos anteriores, como desempenho de CPU e gerenciamento de chaves privadas/certificados, são agora lidados por CPUs que possuem instruções projetadas para acelerar a criptografia (ex: [suporte a AES](https://en.wikipedia.org/wiki/AES_instruction_set)) e pelo gerenciamento de chaves e certificados simplificado por serviços como o [LetsEncrypt.org](https://LetsEncrypt.org), com grandes provedores de nuvem oferecendo serviços de gerenciamento ainda mais integrados para suas plataformas específicas. + +Além de proteger a camada de transporte, é importante determinar quais dados precisam de criptografia em repouso (_at rest_), bem como quais dados precisam de criptografia extra em trânsito (na [camada de aplicação](https://en.wikipedia.org/wiki/Application_layer), camada OSI 7). Por exemplo, senhas, números de cartão de crédito, registros de saúde, informações pessoais e segredos de negócio exigem proteção extra, especialmente se esses dados estiverem sujeitos a leis de privacidade, como a Lei Geral de Proteção de Dados (LGPD) no Brasil ou o GDPR na UE, ou regulamentações como o PCI Data Security Standard (PCI DSS). Para todos esses dados: + +- Algum algoritmo ou protocolo criptográfico antigo ou fraco é usado por padrão ou em código legado? +- Chaves criptográficas padrão estão em uso, chaves fracas são geradas, chaves são reutilizadas ou falta um gerenciamento e rotação de chaves adequados? +- Chaves criptográficas foram enviadas (_checked into_) para repositórios de código-fonte? +- A criptografia não é imposta? Por exemplo, faltam diretivas de segurança ou **headers** HTTP (no navegador)? +- O certificado do servidor recebido e a cadeia de confiança são validados corretamente? +- Vetores de inicialização (IVs) são ignorados, reutilizados ou não são gerados de forma suficientemente segura para o modo de operação criptográfico? Um modo de operação inseguro, como ECB, está em uso? A criptografia simples é usada quando a criptografia autenticada seria mais apropriada? +- Senhas estão sendo usadas como chaves criptográficas na ausência de uma função de derivação de chave baseada em senha (_password-based key derivation function_)? +- É utilizada aleatoriedade que não foi projetada para atender a requisitos criptográficos? Mesmo que a função correta seja escolhida, ela precisa de uma semente (_seed_) definida pelo desenvolvedor? E se não, o desenvolvedor sobrescreveu a funcionalidade de semente forte nativa por uma semente que carece de entropia/imprevisibilidade suficiente? +- Funções de **hash** obsoletas, como MD5 ou SHA1, estão em uso, ou funções de **hash** não criptográficas são usadas quando funções criptográficas são necessárias? +- Mensagens de erro criptográficas ou informações de canal lateral (_side channel_) são exploráveis, por exemplo, na forma de ataques de _padding oracle_? +- O algoritmo criptográfico pode sofrer _downgrade_ ou ser ignorado (_bypass_)? + +Veja as referências ASVS: Criptografia (V11), Comunicação Segura (V12) e Proteção de Dados (V14). + +## Como Prevenir + +Faça o seguinte, no mínimo, e consulte as referências: + +- Classifique e rotule os dados processados, armazenados ou transmitidos por uma aplicação. Identifique quais dados são sensíveis de acordo com as leis de privacidade, requisitos regulatórios ou necessidades de negócio. +- Armazene suas chaves mais sensíveis em um HSM (_Hardware Security Module_) físico ou baseado em nuvem. +- Use implementações bem confiáveis de algoritmos criptográficos sempre que possível. +- Não armazene dados sensíveis desnecessariamente. Descarte-os o mais rápido possível ou use **tokenização** compatível com PCI DSS ou mesmo truncamento. Dados que não são retidos não podem ser roubados. +- Certifique-se de criptografar todos os dados sensíveis em repouso. +- Garanta que algoritmos, protocolos e chaves padrão, fortes e atualizados estejam em vigor; utilize um gerenciamento de chaves adequado. +- Criptografe todos os dados em trânsito apenas com protocolos >= TLS 1.2, com cifras de sigilo direto (_forward secrecy_ - FS), descontinue o suporte a cifras CBC (_cipher block chaining_) e suporte algoritmos de troca de chaves quânticas. Para HTTPS, imponha a criptografia usando HSTS (_HTTP Strict Transport Security_). Verifique tudo com uma ferramenta. +- Desative o cache para respostas que contenham dados sensíveis. Isso inclui cache em sua CDN, servidor web e qualquer cache de aplicação (ex: Redis). +- Aplique os controles de segurança exigidos conforme a classificação de dados. +- Não utilize protocolos não criptografados, como FTP e STARTTLS. Evite usar SMTP para transmitir dados confidenciais. +- Armazene senhas usando funções de **hash** adaptativas e salgadas (_salted_) com um fator de trabalho (fator de atraso), como Argon2, yescrypt, scrypt ou PBKDF2-HMAC-SHA-512. Para sistemas legados que usam bcrypt, obtenha mais orientações no [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). +- Os vetores de inicialização (IVs) devem ser escolhidos de forma apropriada para o modo de operação. Isso pode significar o uso de um CSPRNG (_cryptographically secure pseudo-random number generator_). Para modos que exigem um _nonce_, o IV não precisa de um CSPRNG. Em todos os casos, o IV nunca deve ser usado duas vezes para uma chave fixa. +- Sempre use criptografia autenticada em vez de apenas criptografia. +- As chaves devem ser geradas de forma criptograficamente aleatória e armazenadas na memória como arrays de bytes. Se uma senha for usada, ela deve ser convertida em uma chave por meio de uma função de derivação de chave baseada em senha apropriada. +- Garanta que a aleatoriedade criptográfica seja usada onde apropriado e que não tenha sido semeada de forma previsível ou com baixa entropia. A maioria das **APIs** modernas não exige que o desenvolvedor semeie o CSPRNG para ser seguro. +- Evite funções criptográficas, métodos de construção de blocos e esquemas de preenchimento (_padding_) obsoletos, como MD5, SHA1, modo CBC e PKCS#1 v1.5. +- Garanta que as definições e configurações atendam aos requisitos de segurança, fazendo com que sejam revisadas por especialistas em segurança, ferramentas projetadas para esse fim, ou ambos. +- Você precisa se preparar agora para a criptografia pós-quântica (PQC), veja a referência (ENISA), para que sistemas de alto risco estejam seguros o mais tardar até o final de 2030. + +## Exemplos de Cenários de Ataque + +**Cenário #1**: Um site não usa ou não impõe TLS para todas as páginas ou suporta criptografia fraca. Um **atacante** monitora o tráfego de rede (ex: em uma rede sem fio insegura), rebaixa (_downgrade_) as conexões de HTTPS para HTTP, intercepta requisições e rouba o **cookie** de sessão do usuário. O **atacante**, então, replica esse **cookie** e sequestra a sessão (autenticada) do usuário, acessando ou modificando seus dados privados. Em vez disso, ele poderia alterar todos os dados transportados, como o destinatário de uma transferência de dinheiro. + +**Cenário #2**: O banco de dados de senhas usa **hashes** sem sal (_unsalted_) ou simples para armazenar as senhas de todos. Uma falha de upload de arquivos permite que um **atacante** recupere o banco de dados de senhas. Todos os **hashes** sem sal podem ser expostos com uma _rainbow table_ de **hashes** pré-calculados. **Hashes** gerados por funções simples ou rápidas podem ser quebrados por GPUs, mesmo que tenham sido salgados. + +## Referências + +- [OWASP Proactive Controls: C2: Use Cryptography to Protect Data](https://top10proactive.owasp.org/archive/2024/the-top-10/c2-crypto/) +- [OWASP Application Security Verification Standard (ASVS):](https://owasp.org/www-project-application-security-verification-standard) [V11,](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x20-V11-Cryptography.md) [12,](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x21-V12-Secure-Communication.md) [14](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x23-V14-Data-Protection.md) +- [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) +- [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +- [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +- [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +- [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) +- [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) +- [ENISA: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) +- [NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) + +## Lista de CWEs Mapeadas + +- [CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) +- [CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) +- [CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) +- [CWE-320 Key Management Errors (Prohibited)](https://cwe.mitre.org/data/definitions/320.html) +- [CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) +- [CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) +- [CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) +- [CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) +- [CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) +- [CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) +- [CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) +- [CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) +- [CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) +- [CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) +- [CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) +- [CWE-332 Insufficient Entropy in PRNG](https://cwe.mitre.org/data/definitions/332.html) +- [CWE-334 Small Space of Random Values](https://cwe.mitre.org/data/definitions/334.html) +- [CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) +- [CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) +- [CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) +- [CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) +- [CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) +- [CWE-342 Predictable Exact Value from Previous Values](https://cwe.mitre.org/data/definitions/342.html) +- [CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) +- [CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) +- [CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) +- [CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) +- [CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) +- [CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) +- [CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) +- [CWE-1240 Use of a Cryptographic Primitive with a Risky Implementation](https://cwe.mitre.org/data/definitions/1240.html) +- [CWE-1241 Use of Predictable Algorithm in Random Number Generator](https://cwe.mitre.org/data/definitions/1241.html) diff --git a/2025/docs/pt-BR/A05_2025-Injection.md b/2025/docs/pt-BR/A05_2025-Injection.md new file mode 100644 index 000000000..e7467abe8 --- /dev/null +++ b/2025/docs/pt-BR/A05_2025-Injection.md @@ -0,0 +1,166 @@ +# A05:2025 Injeção ![icon](../assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +A categoria Injeção caiu duas posições, passando de #3 para #5 no ranking, mantendo sua posição relativa a A04:2025-Falhas Criptográficas e A06:2025-Design Inseguro. Injeção é uma das categorias mais testadas, com 100% das aplicações testadas para alguma forma de injeção. Ela apresentou o maior número de CVEs entre todas as categorias, com 37 CWEs mapeadas. Injeção inclui _Cross-site Scripting_ (alta frequência/baixo impacto), com mais de 30 mil CVEs, e _SQL Injection_ (baixa frequência/alto impacto), com mais de 14 mil CVEs. O número massivo de CVEs relatados para a CWE-79 (_Improper Neutralization of Input During Web Page Generation_ ou 'Cross-site Scripting') reduz o impacto ponderado médio desta categoria. + +## Tabela de pontuação + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Taxa Máx. de Incidência + Taxa Méd. de Incidência + Cobertura Máxima + Cobertura Média + Exploit Ponderado Médio + Impacto Ponderado Médio + Total de Ocorrências + Total de CVEs +
37 + 13,77% + 3,08% + 100,00% + 42,93% + 7,15 + 4,32 + 1.404.249 + 62.445 +
+ +## Descrição + +Uma vulnerabilidade de injeção é uma falha na aplicação que permite que a entrada de um usuário não confiável seja enviada para um interpretador (ex: um navegador, banco de dados, linha de comando) e faz com que o interpretador execute partes dessa entrada como comandos. + +Uma aplicação é vulnerável a ataques quando: + +- Dados fornecidos pelo usuário não são validados, filtrados ou sanitizados pela aplicação. +- Consultas dinâmicas ou chamadas não parametrizadas sem escape sensível ao contexto são usadas diretamente no interpretador. +- Dados não sanitizados são usados em parâmetros de busca de mapeamento objeto-relacional (ORM) para extrair registros adicionais e sensíveis. +- Dados potencialmente hostis são usados diretamente ou concatenados. O SQL ou comando contém a estrutura e os dados maliciosos em consultas dinâmicas, comandos ou procedimentos armazenados (_stored procedures_). + +Algumas das injeções mais comuns são SQL, NoSQL, comandos de SO, Mapeamento Objeto-Relacional (ORM), LDAP e Expression Language (EL) ou Object Graph Navigation Library (OGNL). O conceito é idêntico entre todos os interpretadores. A detecção é melhor alcançada por uma combinação de revisão de código-fonte junto com testes automatizados (incluindo _fuzzing_) de todos os parâmetros, _headers_, URL, _cookies_, JSON, SOAP e entradas de dados XML. A adição de ferramentas de teste de segurança de aplicação estática (SAST), dinâmica (DAST) e interativa (IAST) no _pipeline_ de CI/CD também pode ser útil para identificar falhas de injeção antes da implantação em produção. + +Uma classe relacionada de vulnerabilidades de injeção tornou-se comum em LLMs. Estas são discutidas separadamente no [OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/), especificamente em [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). + +## Como prevenir + +A melhor maneira de prevenir a injeção requer manter os dados separados dos comandos e consultas: + +- A opção preferencial é usar uma API segura, que evita totalmente o uso do interpretador, fornece uma interface parametrizada ou migra para ferramentas de Mapeamento Objeto-Relacional (ORMs). + **Nota:** Mesmo quando parametrizadas, as _stored procedures_ ainda podem introduzir SQL Injection se o PL/SQL ou T-SQL concatenar consultas e dados ou executar dados hostis com `EXECUTE IMMEDIATE` ou `exec()`. + +Quando não for possível separar os dados dos comandos, você pode reduzir as ameaças usando as seguintes técnicas: + +- Use validação de entrada positiva no lado do servidor (_allow-list_). Esta não é uma defesa completa, pois muitas aplicações exigem caracteres especiais, como áreas de texto ou APIs para aplicações móveis. +- Para qualquer consulta dinâmica residual, use escape de caracteres especiais usando a sintaxe de escape específica para aquele interpretador. + **Nota:** Estruturas SQL, como nomes de tabelas, nomes de colunas e assim por diante, não podem sofrer escape e, portanto, nomes de estruturas fornecidos pelo usuário são perigosos. Este é um problema comum em softwares de geração de relatórios. + +**Aviso:** estas técnicas envolvem a análise (_parsing_) e o escape de strings complexas, o que as torna propensas a erros e pouco robustas diante de pequenas mudanças no sistema subjacente. + +## Exemplos de cenários de ataque + +**Cenário #1:** Uma aplicação usa dados não confiáveis na construção da seguinte chamada SQL vulnerável: + +```java +String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; +``` + +Um atacante modifica o valor do parâmetro 'id' em seu navegador para enviar: `' OR '1'='1`. Por exemplo: + +``` +http://example.com/app/accountView?id=' OR '1'='1 +``` + +Isso altera o significado da consulta para retornar todos os registros da tabela `accounts`. Ataques mais perigosos poderiam modificar ou excluir dados ou até mesmo invocar procedimentos armazenados. + +**Cenário #2:** A confiança cega de uma aplicação em _frameworks_ pode resultar em consultas que ainda são vulneráveis. Por exemplo, em Hibernate Query Language (HQL): + +```java +Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); +``` + +Um atacante fornece: `' OR custID IS NOT NULL OR custID='`. Isso ignora o filtro e retorna todas as contas. Embora o HQL tenha menos funções perigosas do que o SQL puro, ele ainda permite o acesso não autorizado a dados quando a entrada do usuário é concatenada em consultas. + +**Cenário #3:** Uma aplicação passa a entrada do usuário diretamente para um comando do sistema operacional: + +```java +String cmd = "nslookup " + request.getParameter("domain"); +Runtime.getRuntime().exec(cmd); +``` + +Um atacante fornece `example.com; cat /etc/passwd` para executar comandos arbitrários no servidor. + +## Referências + +- [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) +- [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) +- [OWASP Testing Guide: SQL Injection,](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Command Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection) e [ORM Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) +- [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) +- [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) +- [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) +- [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) +- [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) +- [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) +- [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) + +## Lista de CWEs Mapeadas + +- [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) +- [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) +- [CWE-76 Improper Neutralization of Equivalent Special Elements](https://cwe.mitre.org/data/definitions/76.html) +- [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) +- [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) +- [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) +- [CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)](https://cwe.mitre.org/data/definitions/80.html) +- [CWE-83 Improper Neutralization of Script in Attributes in a Web Page](https://cwe.mitre.org/data/definitions/83.html) +- [CWE-86 Improper Neutralization of Invalid Characters in Identifiers in Web Pages](https://cwe.mitre.org/data/definitions/86.html) +- [CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')](https://cwe.mitre.org/data/definitions/88.html) +- [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) +- [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) +- [CWE-91 XML Injection (aka Blind XPath Injection)](https://cwe.mitre.org/data/definitions/91.html) +- [CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) +- [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) +- [CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95.html) +- [CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')](https://cwe.mitre.org/data/definitions/96.html) +- [CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page](https://cwe.mitre.org/data/definitions/97.html) +- [CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')](https://cwe.mitre.org/data/definitions/98.html) +- [CWE-99 Improper Control of Resource Identifiers ('Resource Injection')](https://cwe.mitre.org/data/definitions/99.html) +- [CWE-103 Struts: Incomplete validate() Method Definition](https://cwe.mitre.org/data/definitions/103.html) +- [CWE-104 Struts: Form Bean Does Not Extend Validation Class](https://cwe.mitre.org/data/definitions/104.html) +- [CWE-112 Missing XML Validation](https://cwe.mitre.org/data/definitions/112.html) +- [CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')](https://cwe.mitre.org/data/definitions/113.html) +- [CWE-114 Process Control](https://cwe.mitre.org/data/definitions/114.html) +- [CWE-115 Misinterpretation of Output](https://cwe.mitre.org/data/definitions/115.html) +- [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) +- [CWE-129 Improper Validation of Array Index](https://cwe.mitre.org/data/definitions/129.html) +- [CWE-159 Improper Handling of Invalid Use of Special Elements](https://cwe.mitre.org/data/definitions/159.html) +- [CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')](https://cwe.mitre.org/data/definitions/470.html) +- [CWE-493 Critical Public Variable Without Final Modifier](https://cwe.mitre.org/data/definitions/493.html) +- [CWE-500 Public Static Field Not Marked Final](https://cwe.mitre.org/data/definitions/500.html) +- [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) +- [CWE-610 Externally Controlled Reference to a Resource in Another Sphere](https://cwe.mitre.org/data/definitions/610.html) +- [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) +- [CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax](https://cwe.mitre.org/data/definitions/644.html) +- [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) diff --git a/2025/docs/pt-BR/A06_2025-Insecure_Design.md b/2025/docs/pt-BR/A06_2025-Insecure_Design.md new file mode 100644 index 000000000..2ef3a0395 --- /dev/null +++ b/2025/docs/pt-BR/A06_2025-Insecure_Design.md @@ -0,0 +1,145 @@ +# A06:2025 Design Inseguro ![icon](../assets/TOP_10_Icons_Final_Insecure_Design.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +O Design Inseguro caiu duas posições, passando de #4 para #6 no ranking, sendo ultrapassado por **[A02:2025-Configuração Insegura](A02_2025-Security_Misconfiguration.md)** e **[A03:2025-Falhas na Cadeia de Suprimentos de Software](A03_2025-Software_Supply_Chain_Failures.md)**. Esta categoria foi introduzida em 2021 e temos observado melhorias notáveis na indústria em relação à modelagem de ameaças e uma maior ênfase em design seguro. Esta categoria foca em riscos relacionados a falhas de design e arquitetura, com um apelo para o maior uso de modelagem de ameaças, padrões de design seguro (_secure design patterns_) e arquiteturas de referência. Isso inclui falhas na lógica de negócio de uma aplicação, por exemplo, a falta de definição de mudanças de estado indesejadas ou inesperadas dentro de uma aplicação. Como comunidade, precisamos ir além do "shift-left" no espaço da codificação para atividades pré-código, como a escrita de requisitos e o design da aplicação, que são críticos para os princípios de _Secure by Design_ (veja, por exemplo, **[Estabelecendo um Programa de AppSec Moderno: Fase de Planejamento e Design](0x03_2025-Establishing_a_Modern_Application_Security_Program.md)**). Enumerações de Fraquezas Comuns (CWEs) notáveis incluem _CWE-256: Armazenamento Não Protegido de Credenciais, CWE-269 Gerenciamento Inadequado de Privilégios, CWE-434 Upload Irrestrito de Arquivo com Tipo Perigoso, CWE-501: Violação de Limite de Confiança e CWE-522: Credenciais Protegidas de Forma Insuficiente._ + +## Tabela de pontuação + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Taxa Máx. de Incidência + Taxa Méd. de Incidência + Cobertura Máxima + Cobertura Média + Exploit Ponderado Médio + Impacto Ponderado Médio + Total de Ocorrências + Total de CVEs +
39 + 22,18% + 1,86% + 88,76% + 35,18% + 6,96 + 4,05 + 729.882 + 7.647 +
+ +## Descrição + +O design inseguro é uma categoria ampla que representa diferentes fraquezas, expressas como "design de controle ausente ou ineficaz". O design inseguro não é a origem de todas as outras categorias de risco do Top Ten. Observe que existe uma diferença entre design inseguro e implementação insegura. Diferenciamos falhas de design de defeitos de implementação por um motivo: eles possuem causas raízes diferentes, ocorrem em momentos diferentes do processo de desenvolvimento e possuem remediações distintas. Um design seguro ainda pode apresentar defeitos de implementação que levam a vulnerabilidades passíveis de exploração. Já um design inseguro não pode ser corrigido por uma implementação perfeita, uma vez que os controles de segurança necessários para defender contra ataques específicos nunca foram criados. Um dos fatores que contribui para o design inseguro é a falta de perfil de risco de negócio (_business risk profiling_) inerente ao software ou sistema sendo desenvolvido e, consequentemente, a falha em determinar qual nível de design de segurança é necessário. + +Três partes fundamentais para ter um design seguro são: + +- Coleta de Requisitos e Gerenciamento de Recursos +- Criação de um Design Seguro +- Manutenção de um Ciclo de Vida de Desenvolvimento Seguro (SDLC) + +### Requisitos e Gerenciamento de Recursos + +Colete e negocie os requisitos de negócio para uma aplicação com as partes interessadas, incluindo os requisitos de proteção relativos à confidencialidade, integridade, disponibilidade e autenticidade de todos os ativos de dados e a lógica de negócio esperada. Leve em conta o quão exposta sua aplicação estará e se você precisa de segregação de instâncias (_tenants_) — além daquelas necessárias para o controle de acesso. Compile os requisitos técnicos, incluindo requisitos de segurança funcionais e não funcionais. Planeje e negocie o orçamento cobrindo todo o design, construção, testes e operação, incluindo atividades de segurança. + +### Design Seguro + +O design seguro é uma cultura e metodologia que avalia constantemente as ameaças e garante que o código seja projetado e testado de forma robusta para prevenir métodos de ataque conhecidos. A modelagem de ameaças deve ser integrada às sessões de refinamento (ou atividades similares); busque por mudanças nos fluxos de dados e no controle de acesso ou outros controles de segurança. No desenvolvimento da _user story_, determine o fluxo correto e os estados de falha, garantindo que sejam bem compreendidos e acordados pelas partes responsáveis e impactadas. Analise suposições e condições para fluxos esperados e de falha para garantir que permaneçam precisos e desejáveis. Determine como validar as suposições e impor as condições necessárias para comportamentos adequados. Garanta que os resultados sejam documentados na _user story_. Aprenda com os erros e ofereça incentivos positivos para promover melhorias. O design seguro não é um acessório nem uma ferramenta que você possa adicionar ao software. + +### Ciclo de Vida de Desenvolvimento Seguro + +Software seguro exige um ciclo de vida de desenvolvimento seguro, um padrão de design seguro, uma metodologia de "estrada pavimentada" (_paved road_), uma biblioteca de componentes seguros, ferramentas apropriadas, modelagem de ameaças e pós-mortems de incidentes que sejam usados para melhorar o processo. Entre em contato com seus especialistas em segurança no início de um projeto de software, ao longo de todo o projeto e para a manutenção contínua do software. Considere utilizar o [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/) para ajudar a estruturar seus esforços de desenvolvimento de software seguro. + +Frequentemente, a autorresponsabilidade dos desenvolvedores é subestimada. Promova uma cultura de conscientização, responsabilidade e mitigação proativa de riscos. Trocas regulares sobre segurança (ex: durante sessões de modelagem de ameaças) podem gerar uma mentalidade para incluir a segurança em todas as decisões importantes de design. + +## Como prevenir + +- Estabeleça e utilize um ciclo de vida de desenvolvimento seguro com profissionais de AppSec para ajudar a avaliar e projetar controles relacionados à segurança e privacidade. +- Estabeleça e utilize uma biblioteca de padrões de design seguro ou componentes de "estrada pavimentada" (_paved road_). +- Utilize a modelagem de ameaças para partes críticas da aplicação, como autenticação, controle de acesso, lógica de negócio e fluxos principais. +- Utilize a modelagem de ameaças como uma ferramenta educacional para gerar uma mentalidade de segurança. +- Integre linguagem e controles de segurança nas _user stories_. +- Integre verificações de plausibilidade em cada camada da sua aplicação (do frontend ao backend). +- Escreva testes de unidade e integração para validar que todos os fluxos críticos são resistentes ao modelo de ameaças. Compile casos de uso (_use-cases_) **e** casos de abuso (_misuse-cases_) para cada camada da sua aplicação. +- Segregue as camadas do sistema e da rede, dependendo da exposição e das necessidades de proteção. +- Segregue instâncias (_tenants_) de forma robusta por design em todas as camadas. + +## Exemplos de cenários de ataque + +**Cenário #1:** Um fluxo de recuperação de credenciais pode incluir "perguntas e respostas", o que é proibido pelo NIST 800-63b, pelo OWASP ASVS e pelo OWASP Top 10. Perguntas e respostas não podem ser confiáveis como prova de identidade, pois mais de uma pessoa pode saber as respostas. Tal funcionalidade deve ser removida e substituída por um design mais seguro. + +**Cenário #2:** Uma rede de cinemas permite descontos para reservas em grupo e possui um máximo de quinze participantes antes de exigir um depósito. Atacantes poderiam modelar as ameaças deste fluxo e testar se conseguem encontrar um vetor de ataque na lógica de negócio da aplicação, por exemplo, reservando seiscentos assentos em todos os cinemas de uma só vez em poucas requisições, causando uma perda massiva de receita. + +**Cenário #3:** O site de e-commerce de uma rede varejista não possui proteção contra _bots_ operados por cambistas (_scalpers_) que compram placas de vídeo de alto desempenho para revender em sites de leilão. Isso gera uma publicidade terrível para os fabricantes de placas de vídeo e para os proprietários da rede varejista, além de um rancor duradouro com os entusiastas que não conseguem obter essas placas por preço algum. Um design anti-bot cuidadoso e regras de lógica de domínio, como identificar compras feitas em poucos segundos após a disponibilidade, poderiam identificar compras inautênticas e rejeitar tais transações. + +## Referências + +- [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) +- [OWASP SAMM: Design | Secure Architecture](https://owaspsamm.org/model/design/secure-architecture/) +- [OWASP SAMM: Design | Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) +- [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) +- [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org/) +- [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) + +## Lista de CWEs Mapeadas + +- [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) +- [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) +- [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) +- [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) +- [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) +- [CWE-286 Incorrect User Management](https://cwe.mitre.org/data/definitions/286.html) +- [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) +- [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) +- [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) +- [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) +- [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html) +- [CWE-382 J2EE Bad Practices: Use of System.exit()](https://cwe.mitre.org/data/definitions/382.html) +- [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) +- [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) +- [CWE-436 Interpretation Conflict](https://cwe.mitre.org/data/definitions/436.html) +- [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) +- [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) +- [CWE-454 External Initialization of Trusted Variables or Data Stores](https://cwe.mitre.org/data/definitions/454.html) +- [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) +- [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) +- [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) +- [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) +- [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) +- [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) +- [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) +- [CWE-628 Function Call with Incorrectly Specified Arguments](https://cwe.mitre.org/data/definitions/628.html) +- [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) +- [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) +- [CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) +- [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) +- [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) +- [CWE-676 Use of Potentially Dangerous Function](https://cwe.mitre.org/data/definitions/676.html) +- [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) +- [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) +- [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) +- [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) +- [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) +- [CWE-1022 Use of Web Link to Untrusted Target with window.opener Access](https://cwe.mitre.org/data/definitions/1022.html) +- [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) diff --git a/2025/docs/pt-BR/A07_2025-Authentication_Failures.md b/2025/docs/pt-BR/A07_2025-Authentication_Failures.md new file mode 100644 index 000000000..d05d17aa7 --- /dev/null +++ b/2025/docs/pt-BR/A07_2025-Authentication_Failures.md @@ -0,0 +1,134 @@ +# A07:2025 Falhas de Autenticação ![icon](../assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +Falhas de Autenticação mantém sua posição em #7 com uma leve mudança no nome para refletir com mais precisão as 36 CWEs nesta categoria. Apesar dos benefícios de _frameworks_ padronizados, esta categoria manteve sua classificação de 2021. CWEs notáveis incluídas são _CWE-259 Use of Hard-coded Password_, _CWE-297: Improper Validation of Certificate with Host Mismatch_, _CWE-287: Improper Authentication_, _CWE-384: Session Fixation_ e _CWE-798 Use of Hard-coded Credentials_. + +## Tabela de pontuação + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Taxa Máx. de Incidência + Taxa Méd. de Incidência + Cobertura Máxima + Cobertura Média + Exploit Ponderado Médio + Impacto Ponderado Médio + Total de Ocorrências + Total de CVEs +
36 + 15,80% + 2,92% + 100,00% + 37,14% + 7,69 + 4,44 + 1.120.673 + 7.147 +
+ +## Descrição + +Esta vulnerabilidade está presente quando um atacante é capaz de enganar um sistema para reconhecer um usuário inválido ou incorreto como legítimo. Pode haver fraquezas de autenticação se a aplicação: + +- Permite ataques automatizados, como _credential stuffing_, onde o atacante possui uma lista vazada de nomes de usuário e senhas válidos. Recentemente, esse tipo de ataque foi expandido para incluir ataques de senha híbridos (também conhecidos como ataques de _password spray_), onde o atacante usa variações ou incrementos de credenciais vazadas para ganhar acesso — por exemplo, tentando Password1!, Password2!, Password3! e assim por diante. +- Permite _brute force_ ou outros ataques automatizados por scripts que não são bloqueados rapidamente. +- Permite senhas padrão, fracas ou bem conhecidas, como o nome de usuário "admin" com a senha "admin" ou a senha "Password1". +- Permite que usuários criem novas contas com credenciais que já se sabe terem sido comprometidas em vazamentos. +- Permite o uso de processos de recuperação de credenciais e "esqueci minha senha" fracos ou ineficazes, como "perguntas baseadas em conhecimento", que não podem ser tornadas seguras. +- Usa repositórios de dados de senhas em texto puro, criptografados ou com _hashes_ fracos (veja [A04:2025-Falhas Criptográficas](https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/)). +- Possui autenticação multifator (MFA) ausente ou ineficaz. +- Permite o uso de _fallbacks_ fracos ou ineficazes caso a autenticação multifator não esteja disponível. +- Expõe o identificador de sessão na URL, em um campo oculto ou em outro local inseguro que seja acessível ao cliente. +- Reutiliza o mesmo identificador de sessão após um login bem-sucedido. +- Não invalida corretamente as sessões de usuário ou _tokens_ de autenticação (principalmente _tokens_ de Single Sign-On (SSO)) durante o logout ou após um período de inatividade. +- Não valida corretamente o escopo e o público-alvo (_audience_) das credenciais fornecidas. + +## Como prevenir + +- Sempre que possível, implemente e force o uso de autenticação multifator (MFA) para prevenir _credential stuffing_ automatizado, _brute force_ e ataques de reutilização de credenciais roubadas. +- Sempre que possível, incentive e habilite o uso de gerenciadores de senhas para ajudar os usuários a fazerem escolhas melhores. +- Não envie ou implante o sistema com credenciais padrão, particularmente para usuários administradores. +- Implemente verificações de senhas fracas, como testar senhas novas ou alteradas contra uma lista das 10.000 piores senhas. +- Durante a criação de novas contas e alterações de senha, valide-as contra listas de credenciais conhecidas como vazadas (ex: usando [haveibeenpwned.com](https://haveibeenpwned.com)). +- Alinhe as políticas de comprimento, complexidade e rotação de senhas com as [diretrizes do National Institute of Standards and Technology (NIST) 800-63b, seção 5.1.1](https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=5.1.1%20Memorized%20Secrets) para Segredos Memorizados ou outras políticas de senha modernas baseadas em evidências. +- Não force seres humanos a rotacionar senhas, a menos que você suspeite de uma violação. Se suspeitar de violação, force a redefinição de senha imediatamente. +- Garanta que as rotas de registro, recuperação de credenciais e caminhos de API sejam endurecidos contra ataques de enumeração de contas, usando as mesmas mensagens para todos os resultados ("Nome de usuário ou senha inválidos."). +- Limite ou atrase progressivamente as tentativas de login malsucedidas, mas tome cuidado para não criar um cenário de negação de serviço (DoS). Registre todas as falhas em logs e alerte os administradores quando ataques de _credential stuffing_, _brute force_ ou outros forem detectados ou suspeitos. +- Use um gerenciador de sessão seguro e nativo no lado do servidor que gere um novo ID de sessão aleatório com alta entropia após o login. Identificadores de sessão não devem estar na URL, devem ser armazenados de forma segura em um _cookie_ seguro e invalidados após logout, inatividade e expiração absoluta (_timeout_). +- Idealmente, use um sistema pronto e bem estabelecido para lidar com autenticação, identidade e gerenciamento de sessão. Transfira esse risco sempre que possível, comprando e utilizando um sistema testado e endurecido. +- Verifique o uso pretendido das credenciais fornecidas; por exemplo, para JWTs, valide as _claims_ `aud`, `iss` e os escopos. + +## Exemplos de cenários de ataque + +**Cenário #1:** O _credential stuffing_ — o uso de listas de combinações conhecidas de nomes de usuário e senhas — é agora um ataque muito comum. Mais recentemente, descobriu-se que atacantes "incrementam" ou ajustam senhas com base no comportamento humano comum. Por exemplo, alterando 'Winter2025' para 'Winter2026', ou 'ILoveMyDog6' para 'ILoveMyDog7'. Esse ajuste de tentativas de senha é chamado de ataque de _credential stuffing_ híbrido ou ataque de _password spray_, e eles podem ser ainda mais eficazes do que a versão tradicional. Se uma aplicação não implementa defesas contra ameaças automatizadas (_brute force_, scripts ou _bots_) ou _credential stuffing_, a aplicação pode ser usada como um "oráculo de senhas" para determinar se as credenciais são válidas e obter acesso não autorizado. + +**Cenário #2:** A maioria dos ataques de autenticação bem-sucedidos ocorre devido ao uso contínuo de senhas como o único fator de autenticação. Outrora consideradas melhores práticas, as exigências de rotação e complexidade de senhas encorajam os usuários tanto a reutilizar senhas quanto a usar senhas fracas. Recomenda-se que as organizações interrompam essas práticas conforme a norma NIST 800-63 e forcem o uso de autenticação multifator em todos os sistemas importantes. + +**Cenário #3:** Os tempos de expiração de sessão (_timeouts_) da aplicação não estão implementados corretamente. Um usuário utiliza um computador público para acessar uma aplicação e, em vez de selecionar "logout", simplesmente fecha a aba do navegador e vai embora. Outro exemplo é quando uma sessão de Single Sign-On (SSO) não pode ser encerrada por um Single Logout (SLO). Ou seja, um único login autentica você no seu leitor de e-mails, sistema de documentos e sistema de chat, por exemplo. Mas o logout acontece apenas no sistema atual. Se um atacante usar o mesmo navegador após a vítima pensar que deslogou com sucesso, mas ainda estiver autenticada em algumas das aplicações, ele poderá acessar a conta da vítima. O mesmo problema pode ocorrer em escritórios e empresas quando uma aplicação sensível não foi devidamente encerrada e um colega tem acesso (temporário) ao computador desbloqueado. + +## Referências + +- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) +- [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-introduction/05-introduction) + +## Lista de CWEs Mapeadas + +- [CWE-258 Empty Password in Configuration File](https://cwe.mitre.org/data/definitions/258.html) +- [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) +- [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) +- [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) +- [CWE-289 Authentication Bypass by Alternate Name](https://cwe.mitre.org/data/definitions/289.html) +- [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) +- [CWE-291 Reliance on IP Address for Authentication](https://cwe.mitre.org/data/definitions/291.html) +- [CWE-293 Using Referer Field for Authentication](https://cwe.mitre.org/data/definitions/293.html) +- [CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) +- [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) +- [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) +- [CWE-298 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/298.html) +- [CWE-299 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/299.html) +- [CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) +- [CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) +- [CWE-303 Incorrect Implementation of Authentication Algorithm](https://cwe.mitre.org/data/definitions/303.html) +- [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) +- [CWE-305 Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html) +- [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) +- [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) +- [CWE-308 Use of Single-factor Authentication](https://cwe.mitre.org/data/definitions/308.html) +- [CWE-309 Use of Password System for Primary Authentication](https://cwe.mitre.org/data/definitions/309.html) +- [CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) +- [CWE-350 Reliance on Reverse DNS Resolution for a Security-Critical Action](https://cwe.mitre.org/data/definitions/350.html) +- [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) +- [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) +- [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) +- [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) +- [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) +- [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) +- [CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) +- [CWE-941 Incorrectly Specified Destination in a Communication Channel](https://cwe.mitre.org/data/definitions/941.html) +- [CWE-1390 Weak Authentication](https://cwe.mitre.org/data/definitions/1390.html) +- [CWE-1391 Use of Weak Credentials](https://cwe.mitre.org/data/definitions/1391.html) +- [CWE-1392 Use of Default Credentials](https://cwe.mitre.org/data/definitions/1392.html) +- [CWE-1393 Use of Default Password](https://cwe.mitre.org/data/definitions/1393.html) diff --git a/2025/docs/pt-BR/A08_2025-Software_or_Data_Integrity_Failures.md b/2025/docs/pt-BR/A08_2025-Software_or_Data_Integrity_Failures.md new file mode 100644 index 000000000..a795f9493 --- /dev/null +++ b/2025/docs/pt-BR/A08_2025-Software_or_Data_Integrity_Failures.md @@ -0,0 +1,100 @@ +# A08:2025 Falhas de Integridade de Software ou Dados ![icon](../assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +Falhas de Integridade de Software ou Dados continua em #8, com uma leve alteração esclarecedora no nome (de "Software _and_ Data..." para "Software _or_ Data..."). Esta categoria foca na falha em manter limites de confiança e verificar a integridade de artefatos de software, código e dados em um nível inferior às Falhas na Cadeia de Suprimentos de Software. Esta categoria foca em assumir pressupostos relacionados a atualizações de software e dados críticos sem verificar sua integridade. Enumerações de Fraquezas Comuns (CWEs) notáveis incluem _CWE-829: Inclusion of Functionality from Untrusted Control Sphere_, _CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes_ e _CWE-502: Deserialization of Untrusted Data_. + +## Tabela de pontuação + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Taxa Máx. de Incidência + Taxa Méd. de Incidência + Cobertura Máxima + Cobertura Média + Exploit Ponderado Médio + Impacto Ponderado Médio + Total de Ocorrências + Total de CVEs +
14 + 8,98% + 2,75% + 78,52% + 45,49% + 7,11 + 4,79 + 501.327 + 3.331 +
+ +## Descrição + +Falhas de integridade de software e dados referem-se a códigos e infraestruturas que não protegem contra códigos ou dados inválidos ou não confiáveis que são tratados como íntegros e válidos. Um exemplo disso ocorre quando uma aplicação depende de plugins, bibliotecas ou módulos de fontes, repositórios e redes de entrega de conteúdo (CDNs) não confiáveis. Um _pipeline_ de CI/CD inseguro, que não consome nem fornece verificações de integridade de software, pode introduzir o potencial de acesso não autorizado, código malicioso ou comprometimento do sistema. Outro exemplo é um CI/CD que extrai código ou artefatos de locais não confiáveis e/ou não os verifica antes do uso (através de assinatura digital ou mecanismo similar). Por fim, muitas aplicações agora incluem funcionalidade de atualização automática, onde atualizações são baixadas sem verificação de integridade suficiente e aplicadas à aplicação previamente confiável. Atacantes poderiam potencialmente fazer o _upload_ de suas próprias atualizações para serem distribuídas e executadas em todas as instalações. Outro exemplo ocorre quando objetos ou dados são codificados ou serializados em uma estrutura que um atacante pode visualizar e modificar, tornando a aplicação vulnerável à desserialização insegura. + +## Como prevenir + +- Utilize assinaturas digitais ou mecanismos similares para verificar se o software ou dado provém da fonte esperada e não foi alterado. +- Garanta que bibliotecas e dependências, como npm ou Maven, estejam consumindo apenas repositórios confiáveis. Se você tiver um perfil de risco mais elevado, considere hospedar um repositório interno de itens conhecidos e aprovados (_vetted_). +- Garanta que haja um processo de revisão para alterações de código e configuração para minimizar a chance de que códigos ou configurações maliciosas sejam introduzidos em seu _pipeline_ de software. +- Garanta que seu _pipeline_ de CI/CD possua segregação, configuração e controle de acesso adequados para assegurar a integridade do código que flui pelos processos de compilação (_build_) e implantação (_deploy_). +- Garanta que dados serializados não assinados ou não criptografados não sejam recebidos de clientes não confiáveis e usados posteriormente sem algum tipo de verificação de integridade ou assinatura digital para detectar adulteração ou repetição (_replay_) dos dados serializados. + +## Exemplos de cenários de ataque + +**Cenário #1 Inclusão de Funcionalidade Web de Fonte Não Confiável:** Uma empresa utiliza um provedor de serviços externo para fornecer funcionalidade de suporte. Por conveniência, possui um mapeamento de DNS de `minhaEmpresa.ProvedorSuporte.com` para `suporte.minhaEmpresa.com`. Isso significa que todos os _cookies_, incluindo _cookies_ de autenticação configurados no domínio `minhaEmpresa.com`, serão enviados para o provedor de suporte. Qualquer pessoa com acesso à infraestrutura do provedor de suporte pode roubar os _cookies_ de todos os seus usuários que visitaram `suporte.minhaEmpresa.com` e realizar um ataque de sequestro de sessão (_session hijacking_). + +**Cenário #2 Atualização sem assinatura:** Muitos roteadores domésticos, decodificadores de TV (_set-top boxes_), firmwares de dispositivos e outros não verificam atualizações via firmware assinado. Firmware não assinado é um alvo crescente para atacantes e a expectativa é que a situação piore. Esta é uma preocupação importante, pois muitas vezes não há mecanismo de remediação além de corrigir em uma versão futura e esperar que as versões anteriores deixem de ser usadas. + +**Cenário #3 Uso de Pacote de Fonte Não Confiável:** Um desenvolvedor tem dificuldade em encontrar a versão atualizada de um pacote que está procurando, então ele o baixa não do gerenciador de pacotes regular e confiável, mas de um site qualquer na internet. O pacote não está assinado e, portanto, não há oportunidade de garantir a integridade. O pacote inclui código malicioso. + +**Cenário #4 Desserialização Insegura:** Uma aplicação React chama um conjunto de microserviços Spring Boot. Sendo programadores funcionais, eles tentaram garantir que seu código fosse imutável. A solução encontrada foi serializar o estado do usuário e passá-lo de um lado para o outro em cada requisição. Um atacante percebe a assinatura de objeto Java "rO0" (em base64) e utiliza o [Java Deserialization Scanner](https://github.com/federicodotta/Java-Deserialization-Scanner) para obter execução remota de código (RCE) no servidor da aplicação. + +## Referências + +- [OWASP Cheat Sheet: Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) +- [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) +- [OWASP Cheat Sheet: Deserialization](https://wiki.owasp.org/index.php/Deserialization_Cheat_Sheet) +- [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +- [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) +- [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) +- [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) +- [Insecure Deserialization by Tenendo](https://tenendo.com/insecure-deserialization/) + +## Lista de CWEs Mapeadas + +- [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) +- [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) +- [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) +- [CWE-427 Uncontrolled Search Path Element](https://cwe.mitre.org/data/definitions/427.html) +- [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) +- [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) +- [CWE-506 Embedded Malicious Code](https://cwe.mitre.org/data/definitions/506.html) +- [CWE-509 Replicating Malicious Code (Virus or Worm)](https://cwe.mitre.org/data/definitions/509.html) +- [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) +- [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) +- [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) +- [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) +- [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) +- [CWE-926 Improper Export of Android Application Components](https://cwe.mitre.org/data/definitions/926.html) diff --git a/2025/docs/pt-BR/A09_2025-Security_Logging_and_Alerting_Failures.md b/2025/docs/pt-BR/A09_2025-Security_Logging_and_Alerting_Failures.md new file mode 100644 index 000000000..b087b31ec --- /dev/null +++ b/2025/docs/pt-BR/A09_2025-Security_Logging_and_Alerting_Failures.md @@ -0,0 +1,125 @@ +# A09:2025 – Falhas de Registro e Monitoramento de Segurança ![icon](../assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} + +## Contexto + +**Falhas de Registro e Monitoramento de Segurança** (Security Logging & Alerting Failures) mantém sua posição em 9º lugar. Esta categoria teve uma leve mudança de nome para enfatizar a função de alerta necessária para induzir ações em eventos de _log_ relevantes. Esta categoria estará sempre sub-representada nos dados e, pela terceira vez, foi votada para uma posição na lista pelos participantes da pesquisa da comunidade. É uma categoria incrivelmente difícil de testar e possui representação mínima nos dados de CVE/CVSS (apenas 723 CVEs); porém, pode ter um grande impacto na visibilidade, no alerta de incidentes e na perícia forense. Esta categoria inclui problemas com o _tratamento adequado da codificação de saída para arquivos de log (CWE-117), inserção de dados sensíveis em arquivos de log (CWE-532) e registros insuficientes (CWE-778)._ + +## 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 +
5 + 11,33% + 3,91% + 85,96% + 46,48% + 7,19 + 2,65 + 260.288 + 723 +
+ +## Descrição + +Sem registro e monitoramento, ataques e violações não podem ser detectados, e sem alertas é muito difícil responder de forma rápida e eficaz durante um incidente de segurança. Registro, monitoramento contínuo, detecção e alertas insuficientes para iniciar respostas ativas ocorrem sempre que: + +- Eventos auditáveis, como logins, falhas de login e transações de alto valor, não são registrados ou são registrados de forma inconsistente (por exemplo, registrando apenas logins bem-sucedidos, mas não tentativas falhas). +- Avisos e erros geram mensagens de _log_ inexistentes, inadequadas ou confusas. +- A integridade dos _logs_ não é devidamente protegida contra adulteração. +- _Logs_ de aplicações e APIs não são monitorados em busca de atividades suspeitas. +- Os _logs_ são armazenados apenas localmente e não possuem backup adequado. +- Limiares de alerta e processos de escalonamento de resposta apropriados não estão estabelecidos ou não são eficazes. Os alertas não são recebidos ou revisados em um tempo razoável. +- Testes de invasão (_penetration testing_) e varreduras por ferramentas de testes dinâmicos de segurança de aplicações (DAST), como Burp ou ZAP, não disparam alertas. +- A aplicação não consegue detectar, escalar ou alertar sobre ataques ativos em tempo real ou próximo ao tempo real. +- Você está vulnerável ao vazamento de informações sensíveis ao tornar eventos de registro e alerta visíveis para um usuário ou atacante (veja [A01:2025-Controle de Acesso Quebrado](A01_2025-Broken_Access_Control.md)), ou ao registrar informações sensíveis que não deveriam ser gravadas (como PII ou PHI). +- Você está vulnerável a injeções ou ataques nos sistemas de registro ou monitoramento se os dados de _log_ não forem codificados corretamente. +- A aplicação omite ou trata incorretamente erros e outras condições excepcionais, de modo que o sistema não percebe que houve um erro e, portanto, não consegue registrar que houve um problema. +- "Casos de uso" adequados para emissão de alertas estão ausentes ou desatualizados para reconhecer uma situação especial. +- O excesso de alertas falsos positivos impossibilita distinguir alertas importantes de irrelevantes, resultando em detecções tardias ou inexistentes (sobrecarga física da equipe do SOC). +- Alertas detectados não podem ser processados corretamente porque o _playbook_ para o caso de uso está incompleto, desatualizado ou ausente. + +## Como Prevenir + +Os desenvolvedores devem implementar alguns ou todos os seguintes controles, dependendo do risco da aplicação: + +- Garantir que todas as falhas de login, controle de acesso e validação de entrada no lado do servidor possam ser registradas com contexto de usuário suficiente para identificar contas suspeitas ou maliciosas, e mantidas por tempo suficiente para permitir análises forenses posteriores. +- Garantir que cada parte do seu app que contenha um controle de segurança gere um _log_, independentemente de sucesso ou falha. +- Garantir que os _logs_ sejam gerados em um formato que as soluções de gerenciamento de _logs_ possam consumir facilmente. +- Garantir que os dados de _log_ sejam codificados corretamente para evitar injeções ou ataques aos sistemas de registro ou monitoramento. +- Garantir que todas as transações tenham uma trilha de auditoria com controles de integridade para evitar adulteração ou exclusão, como tabelas de banco de dados do tipo _append-only_ ou similares. +- Garantir que todas as transações que lancem um erro sofram _rollback_ e sejam reiniciadas. Sempre utilize a falha segura (_fail closed_). +- Se sua aplicação ou seus usuários se comportarem de forma suspeita, emita um alerta. Crie diretrizes para seus desenvolvedores sobre este tema para que possam codificar prevendo isso ou adquira um sistema para este fim. +- As equipes de DevSecOps e segurança devem estabelecer casos de uso eficazes de monitoramento e alerta, incluindo _playbooks_, para que atividades suspeitas sejam detectadas e respondidas rapidamente pela equipe do Centro de Operações de Segurança (SOC). +- Adicione ‘honeytokens’ como armadilhas para atacantes em sua aplicação, ex: no banco de dados, nos dados, ou como identidades de usuários reais e/ou técnicas. Como não são usados no fluxo normal de negócio, qualquer acesso gera dados de _log_ que podem disparar alertas com quase zero falsos positivos. +- A análise de comportamento e o suporte de IA podem ser, opcionalmente, técnicas adicionais para apoiar baixas taxas de falsos positivos em alertas. +- Estabeleça ou adote um plano de resposta e recuperação de incidentes, como o NIST 800-61r2 ou posterior. Ensine seus desenvolvedores de software como são os ataques e incidentes em aplicações, para que saibam reportá-los. + +Existem produtos comerciais e de código aberto para proteção de aplicações, como o OWASP ModSecurity Core Rule Set, e softwares de correlação de _logs_ de código aberto, como a stack Elasticsearch, Logstash, Kibana (ELK), que apresentam painéis personalizados e alertas que podem ajudar a combater esses problemas. Também existem ferramentas comerciais de observabilidade que podem ajudar a responder ou bloquear ataques em tempo quase real. + +## Cenários de Exemplo de Ataque + +**Cenário 1:** O operador do site de um provedor de planos de saúde infantil não conseguiu detectar uma invasão devido à falta de monitoramento e registros. Uma parte externa informou ao provedor que um atacante havia acessado e modificado milhares de registros de saúde sensíveis de mais de 3,5 milhões de crianças. Uma revisão pós-incidente descobriu que os desenvolvedores do site não haviam corrigido vulnerabilidades significativas. Como não havia registro ou monitoramento do sistema, o vazamento de dados poderia estar em andamento desde 2013, um período de mais de sete anos. + +**Cenário 2:** Uma grande companhia aérea indiana sofreu um vazamento de dados envolvendo mais de dez anos de dados pessoais de milhões de passageiros, incluindo dados de passaporte e cartão de crédito. O vazamento ocorreu em um provedor de hospedagem em nuvem terceirizado, que notificou a companhia aérea sobre a violação após algum tempo. + +**Cenário 3:** Uma grande companhia aérea europeia sofreu uma violação passível de notificação pelo GDPR. O vazamento foi supostamente causado por vulnerabilidades de segurança em uma aplicação de pagamento exploradas por atacantes, que coletaram mais de 400.000 registros de pagamento de clientes. Como resultado, a companhia aérea foi multada em 20 milhões de libras pelo regulador de privacidade. + +## Referências + +- [OWASP Proactive Controls: C9: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) + +- [OWASP Application Security Verification Standard: V16 Security Logging and Error Handling](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md) + +- [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) + +- [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) + +- [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) + +- [Real world example of such failures in Snowflake Breach](https://www.huntress.com/threat-library/data-breach/snowflake-data-breach) + +## Lista de CWEs Mapeadas + +- [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) + +- [CWE-221 Information Loss of Omission](https://cwe.mitre.org/data/definitions/221.html) + +- [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) + +- [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) + +- [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) diff --git a/2025/docs/pt-BR/A10_2025-Mishandling_of_Exceptional_Conditions.md b/2025/docs/pt-BR/A10_2025-Mishandling_of_Exceptional_Conditions.md new file mode 100644 index 000000000..be3ee6c95 --- /dev/null +++ b/2025/docs/pt-BR/A10_2025-Mishandling_of_Exceptional_Conditions.md @@ -0,0 +1,129 @@ +# A10:2025 – Tratamento Incorreto de Condições Excepcionais ![icon](../assets/TOP_10_Icons_Final_Mishandling_of_Exceptional_Conditions.png){: style="height:80px;width:80px" align="right"} + +## 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](A09_2025-Security_Logging_and_Alerting_Failures.md). + +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 + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html) + +- [OWASP Application Security Verification Standard (ASVS): V16.5 Error Handling](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md#v165-error-handling) + +- [OWASP Testing Guide: 4.8.1 Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) + +* [Best practices for exceptions (Microsoft, .Net)](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) + +* [Clean Code and the Art of Exception Handling (Toptal)](https://www.toptal.com/developers/abap/clean-code-and-the-art-of-exception-handling) + +* [General error handling rules (Google for Developers)](https://developers.google.com/tech-writing/error-messages/error-handling) + +* [Example of real-world mishandling of an exceptional condition](https://www.firstreference.com/blog/human-error-and-internal-control-failures-cause-us62m-fine/) + +## Lista de CWEs Mapeadas + +- [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) +- [CWE-215 Insertion of Sensitive Information Into Debugging Code](https://cwe.mitre.org/data/definitions/215.html) +- [CWE-234 Failure to Handle Missing Parameter](https://cwe.mitre.org/data/definitions/234.html) +- [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) +- [CWE-248 Uncaught Exception](https://cwe.mitre.org/data/definitions/248.html) +- [CWE-252 Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html) +- [CWE-274 Improper Handling of Insufficient Privileges](https://cwe.mitre.org/data/definitions/274.html) +- [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) +- [CWE-369 Divide By Zero](https://cwe.mitre.org/data/definitions/369.html) +- [CWE-390 Detection of Error Condition Without Action](https://cwe.mitre.org/data/definitions/390.html) +- [CWE-391 Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html) +- [CWE-394 Unexpected Status Code or Return Value](https://cwe.mitre.org/data/definitions/394.html) +- [CWE-396 Declaration of Catch for Generic Exception](https://cwe.mitre.org/data/definitions/396.html) +- [CWE-397 Declaration of Throws for Generic Exception](https://cwe.mitre.org/data/definitions/397.html) +- [CWE-460 Improper Cleanup on Thrown Exception](https://cwe.mitre.org/data/definitions/460.html) +- [CWE-476 NULL Pointer Dereference](https://cwe.mitre.org/data/definitions/476.html) +- [CWE-478 Missing Default Case in Multiple Condition Expression](https://cwe.mitre.org/data/definitions/478.html) +- [CWE-484 Omitted Break Statement in Switch](https://cwe.mitre.org/data/definitions/484.html) +- [CWE-550 Server-generated Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/550.html) +- [CWE-636 Not Failing Securely ('Failing Open')](https://cwe.mitre.org/data/definitions/636.html) +- [CWE-703 Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html) +- [CWE-754 Improper Check for Unusual or Exceptional Conditions](https://cwe.mitre.org/data/definitions/754.html) +- [CWE-755 Improper Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/755.html) +- [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) diff --git a/2025/docs/pt-BR/X01_2025-Next_Steps.md b/2025/docs/pt-BR/X01_2025-Next_Steps.md new file mode 100644 index 000000000..f2796ecd1 --- /dev/null +++ b/2025/docs/pt-BR/X01_2025-Next_Steps.md @@ -0,0 +1,97 @@ +# Próximos Passos + +Por design, o OWASP Top 10 é inatamente limitado aos dez riscos mais significativos. Todo OWASP Top 10 possui riscos "no limiar" que são considerados extensivamente para inclusão, mas que, ao final, não entraram na lista. Os demais riscos eram mais prevalentes e impactantes. + +Os três problemas a seguir valem bem o esforço de identificação e remediação para organizações que buscam um programa de AppSec maduro, consultorias de segurança ou fornecedores de ferramentas que desejam expandir a cobertura de suas ofertas. + +--- + +## X01:2025 – Falta de Resiliência da Aplicação + +### Contexto + +Este é um renomeio do item Negação de Serviço (Denial of Service) de 2021. O nome foi alterado porque descrevia um sintoma em vez de uma causa raiz. Esta categoria foca em CWEs que descrevem fraquezas relacionadas a problemas de resiliência. A pontuação desta categoria foi muito próxima da [A10:2025-Tratamento Incorreto de Condições Excepcionais](A10_2025-Mishandling_of_Exceptional_Conditions.md). CWEs relevantes incluem: _CWE-400 Consumo Descontrolado de Recursos, CWE-409 Tratamento Incorreto de Dados Altamente Compactados (Amplificação de Dados), CWE-674 Recursão Descontrolada_ e _CWE-835 Loop com Condição de Saída Inalcançável ('Loop Infinito')._ + +### Tabela de Pontuação + +[Mesmos valores da tabela original: 16 CWEs, Incidência Média 4,55%, Total de Ocorrências 865.066, etc.] + +### Descrição + +Esta categoria representa uma fraqueza sistêmica na forma como as aplicações respondem ao estresse, falhas e casos extremos, resultando na incapacidade de se recuperar de uma falha. Quando uma aplicação não lida adequadamente, não resiste ou não se recupera de condições inesperadas, restrições de recursos e outros eventos adversos, isso pode facilmente resultar em problemas de disponibilidade (mais comum), mas também em corrupção de dados, divulgação de dados sensíveis, falhas em cascata e/ou _bypass_ de controles de segurança. + +Além disso, a categoria [X02:2025 Falhas de Gerenciamento de Memória](#x022025-falhas-de-gerenciamento-de-memória) também pode levar à falha da aplicação ou até de todo o sistema. + +### Como Prevenir + +Para prevenir este tipo de vulnerabilidade, você deve projetar seus sistemas prevendo falhas e recuperação. + +- Adicione limites, cotas e funcionalidades de _failover_, dando atenção especial às operações que mais consomem recursos. +- Identifique páginas que demandam muitos recursos e planeje com antecedência: reduza a superfície de ataque, especialmente não expondo "gadgets" e funções desnecessárias que exijam muitos recursos (ex: CPU, memória) a usuários desconhecidos ou não confiáveis. +- Realize uma validação de entrada rigorosa com _allow-lists_ e limitações de tamanho, e então teste exaustivamente. +- Limite os tamanhos das respostas e nunca envie respostas brutas de volta ao cliente (processe no lado do servidor). +- Padrão para seguro/fechado (_fail closed_), negue por padrão e realize _rollback_ se houver um erro. +- Evite chamadas síncronas bloqueantes em threads de requisição (use assíncrono/não bloqueante, estabeleça _timeouts_, limites de concorrência, etc.). +- Teste cuidadosamente sua funcionalidade de tratamento de erros. +- Implemente padrões de resiliência como _circuit breakers_, _bulkheads_, lógica de retentativa (_retry_) e degradação suave (_graceful degradation_). +- Realize testes de desempenho e carga; adicione engenharia de caos (_chaos engineering_) se tiver apetite ao risco para isso. +- Implemente e projete arquiteturas visando redundância onde for razoável e financeiramente viável. +- Implemente monitoramento, observabilidade e alertas. +- Filtre endereços de remetentes inválidos de acordo com a RFC 2267. +- Bloqueie _botnets_ conhecidas por impressões digitais (_fingerprints_), IPs ou dinamicamente por comportamento. +- Prova de Trabalho (_Proof-of-Work_): inicie operações que consomem recursos no lado do _atacante_, o que não impacta grandes usuários normais, mas afeta bots que tentam enviar uma quantidade enorme de requisições. +- Limite o tempo de sessão no servidor baseado em inatividade e um _timeout_ final. + +--- + +## X02:2025 – Falhas de Gerenciamento de Memória + +### Contexto + +Linguagens como Java, C#, JavaScript/TypeScript (node.js), Go e o Rust "seguro" são resilientes à memória (_memory safe_). Problemas de gerenciamento de memória tendem a ocorrer em linguagens que não possuem essa segurança, como C e C++. Esta categoria teve a pontuação mais baixa na pesquisa da comunidade e baixa nos dados, apesar de ter o terceiro maior número de CVEs relacionados. Acreditamos que isso se deva à predominância de aplicações web sobre as aplicações desktop tradicionais. Vulnerabilidades de gerenciamento de memória frequentemente possuem as pontuações CVSS mais altas. + +### Descrição + +Quando uma aplicação é forçada a gerenciar a memória por conta própria, é muito fácil cometer erros. Linguagens com gerenciamento seguro de memória são usadas cada vez mais, mas ainda existem muitos sistemas legados em produção, novos sistemas de baixo nível que exigem linguagens não seguras, e aplicações web que interagem com _mainframes_, dispositivos IoT, _firmware_ e outros sistemas. CWEs representativas são _CWE-120 Cópia de Buffer sem Verificação do Tamanho da Entrada ('Classic Buffer Overflow')_ e _CWE-121 Stack-based Buffer Overflow_. + +As falhas de gerenciamento de memória podem ocorrer quando: + +- Você não aloca memória suficiente para uma variável. +- Você não valida a entrada, causando um transbordamento (_overflow_) do _heap_, da _stack_ ou de um _buffer_. +- Você tenta acessar um objeto após ele ter sido liberado (_free_). +- Você vaza memória (_memory leak_) até que a aplicação falhe. + +### Como Prevenir + +A melhor maneira de prevenir falhas de gerenciamento de memória é usar uma linguagem com memória segura (_memory-safe_), como Rust, Java, Go, C#, Python, Swift, Kotlin ou JavaScript. + +Se você não puder usar uma linguagem segura: + +- Ative recursos do servidor que dificultam a exploração: ASLR, DEP e SEHOP. +- Monitore a aplicação em busca de vazamentos de memória (_memory leaks_). +- Valide cuidadosamente todas as entradas do sistema. +- Prefira funções mais seguras (ex: em C, prefira `strncpy()` em vez de `strcpy()`). +- Fixe todos os erros _e_ avisos (_warnings_) do compilador. Não ignore avisos apenas porque o programa compilou. + +--- + +## X03:2025 – Confiança Inapropriada em Código Gerado por IA ('Vibe Coding') + +### Contexto + +Atualmente, o mundo inteiro fala sobre e utiliza IA, incluindo desenvolvedores de software. Embora ainda não existam CVEs ou CWEs específicas para código gerado por IA, é bem documentado que esse código frequentemente contém mais vulnerabilidades do que o código escrito por seres humanos. + +### Descrição + +Estamos vendo as práticas de desenvolvimento mudarem para incluir não apenas código escrito com auxílio de IA, mas código escrito e enviado (_committed_) quase inteiramente sem supervisão humana (frequentemente chamado de _vibe coding_). Assim como nunca foi uma boa ideia copiar trechos de código de blogs sem refletir, o problema é agravado neste caso. Trechos de código bons e seguros são raros e podem ser estatisticamente negligenciados pela IA devido a restrições do sistema. + +### Como Prevenir + +Urgimos que todas as pessoas que escrevem código considerem o seguinte ao usar IA: + +- Você deve ser capaz de ler e entender totalmente todo o código que envia, mesmo que tenha sido escrito por uma IA. **Você é responsável por todo código que comita.** +- Revise minuciosamente todo código assistido por IA em busca de vulnerabilidades, idealmente com seus próprios olhos e com ferramentas de segurança (como análise estática). +- Considere utilizar um servidor de Geração Aumentada por Recuperação (RAG) com seus próprios exemplos de código seguro revisados e documentação interna. +- Implemente políticas e processos como parte do seu SDLC para informar aos desenvolvedores como devem ou não usar IA na organização. +- **Não é recomendado** usar _vibe coding_ para funções complexas, programas críticos de negócio ou sistemas que serão utilizados por muito tempo. +- Treine seus desenvolvedores sobre suas políticas e as melhores práticas para o uso seguro de IA no desenvolvimento de software. diff --git a/2025/docs/pt-BR/index.md b/2025/docs/pt-BR/index.md new file mode 100644 index 000000000..07ff60f52 --- /dev/null +++ b/2025/docs/pt-BR/index.md @@ -0,0 +1,41 @@ +# OWASP Top 10:2025 + +Bem-vindo ao lançamento do **OWASP Top 10:2025**. + +O OWASP Top 10 é um documento padrão de conscientização para desenvolvedores e segurança de aplicações web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicações web. + +## Sobre este Lançamento + +Esta é a versão **2025** do OWASP Top 10. Esta versão inclui atualizações baseadas nos dados e tendências de segurança mais recentes. + +## Página Principal do Projeto + +A [página principal do projeto](https://github.com/OWASP/www-project-top-ten) contém informações sobre versões anteriores e metadados sobre este projeto. + +## Primeiros Passos + +Comece pela [Introdução](0x00_2025-Introduction.md) para saber o que há de novo na versão 2025. + +## Navegação + +- [Introdução](0x00_2025-Introduction.md) +- [Sobre a OWASP](0x01_2025-About_OWASP.md) +- [O que são Riscos de Segurança de Aplicações?](0x02_2025-What_are_Application_Security_Risks.md) +- [Estabelecendo um Programa Moderno de Segurança de Aplicações](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) + +### Lista do Top 10:2025 + +1. [A01:2025 - Controle de Acesso Quebrado](A01_2025-Broken_Access_Control.md) +2. [A02:2025 - Configuração Insegura](A02_2025-Security_Misconfiguration.md) +3. [A03:2025 - Falhas na Cadeia de Suprimentos de Software](A03_2025-Software_Supply_Chain_Failures.md) +4. [A04:2025 - Falhas Criptográficas](A04_2025-Cryptographic_Failures.md) +5. [A05:2025 - Injeção](A05_2025-Injection.md) +6. [A06:2025 - Design Inseguro](A06_2025-Insecure_Design.md) +7. [A07:2025 - Falhas de Autenticação](A07_2025-Authentication_Failures.md) +8. [A08:2025 - Falhas de Integridade de Software ou de Dados](A08_2025-Software_or_Data_Integrity_Failures.md) +9. [A09:2025 - Falhas de Registro e Monitoramento de Segurança](A09_2025-Security_Logging_and_Alerting_Failures.md) +10. [A10:2025 - Tratamento Incorreto de Condições Excepcionais](A10_2025-Mishandling_of_Exceptional_Conditions.md) + +--- + +**Nota:** As traduções serão adicionadas conforme estiverem disponíveis. diff --git a/2025/mkdocs.yml b/2025/mkdocs.yml index 35bee0cc0..c8a464249 100644 --- a/2025/mkdocs.yml +++ b/2025/mkdocs.yml @@ -15,23 +15,23 @@ theme: - search.suggest nav: - - Home: 'en/index.md' - - Introduction: 'en/0x00_2025-Introduction.md' - - About OWASP: 'en/0x01_2025-About_OWASP.md' - - What are Application Security Risks?: 'en/0x02_2025-What_are_Application_Security_Risks.md' - - Establishing a Modern Application Security Program: 'en/0x03_2025-Establishing_a_Modern_Application_Security_Program.md' + - Home: "en/index.md" + - Introduction: "en/0x00_2025-Introduction.md" + - About OWASP: "en/0x01_2025-About_OWASP.md" + - What are Application Security Risks?: "en/0x02_2025-What_are_Application_Security_Risks.md" + - Establishing a Modern Application Security Program: "en/0x03_2025-Establishing_a_Modern_Application_Security_Program.md" - Top 10:2025 List: - - A01 Broken Access Control: 'en/A01_2025-Broken_Access_Control.md' - - A02 Security Misconfiguration: 'en/A02_2025-Security_Misconfiguration.md' - - A03 Software Supply Chain Failures: 'en/A03_2025-Software_Supply_Chain_Failures.md' - - A04 Cryptographic Failures: 'en/A04_2025-Cryptographic_Failures.md' - - A05 Injection: 'en/A05_2025-Injection.md' - - A06 Insecure Design: 'en/A06_2025-Insecure_Design.md' - - A07 Authentication Failures: 'en/A07_2025-Authentication_Failures.md' - - A08 Software or Data Integrity Failures: 'en/A08_2025-Software_or_Data_Integrity_Failures.md' - - A09 Security Logging and Alerting Failures: 'en/A09_2025-Security_Logging_and_Alerting_Failures.md' - - A10 Mishandling of Exceptional Conditions: 'en/A10_2025-Mishandling_of_Exceptional_Conditions.md' - - Next Steps: 'en/X01_2025-Next_Steps.md' + - A01 Broken Access Control: "en/A01_2025-Broken_Access_Control.md" + - A02 Security Misconfiguration: "en/A02_2025-Security_Misconfiguration.md" + - A03 Software Supply Chain Failures: "en/A03_2025-Software_Supply_Chain_Failures.md" + - A04 Cryptographic Failures: "en/A04_2025-Cryptographic_Failures.md" + - A05 Injection: "en/A05_2025-Injection.md" + - A06 Insecure Design: "en/A06_2025-Insecure_Design.md" + - A07 Authentication Failures: "en/A07_2025-Authentication_Failures.md" + - A08 Software or Data Integrity Failures: "en/A08_2025-Software_or_Data_Integrity_Failures.md" + - A09 Security Logging and Alerting Failures: "en/A09_2025-Security_Logging_and_Alerting_Failures.md" + - A10 Mishandling of Exceptional Conditions: "en/A10_2025-Mishandling_of_Exceptional_Conditions.md" + - Next Steps: "en/X01_2025-Next_Steps.md" markdown_extensions: - attr_list @@ -48,55 +48,55 @@ plugins: default: true name: en - English build: true - nav_translations: - - SAMPLE: - Home: Startseite - Notice: Anmerkung - Introduction: Einführung - How to use the OWASP Top 10 as a standard: Wie man die OWASP Top 10 als Standard verwendet - How to start an AppSec program with the OWASP Top 10: Wie man ein AppSec-Program mit den OWASP Top 10 beginnt - About OWASP: Über OWASP - Top 10:2025 List: Liste der Top 10:2025 - A01 Broken Access Control: A01 - Mangelhafte Zugriffskontrolle - A02 Cryptographic Failures: A02 - Fehlerhafter Einsatz von Kryptographie - A03 Injection: A03 - Injection - A04 Insecure Design: A04 - Unsicheres Anwendungsdesign - A05 Security Misconfiguration: A05 - Sicherheitsrelevante Fehlkonfiguration - A06 Vulnerable and Outdated Components: A06 - Unsichere oder veraltete Komponenten - A07 Identification and Authentication Failures: A07 - Fehlerhafte Authentifizierung - A08 Software and Data Integrity Failures: A08 - Fehlerhafte Prüfung der Software- und Datenintegrität - A09 Security Logging and Monitoring Failures: A09 - Unzureichendes Logging und Sicherheitsmonitoring - A10 Server Side Request Forgery (SSRF): A10 - Server-Side Request Forgery (SSRF) - Next Steps: Nächste Schritte - - macros: # needs to be the last plugin to export the final osib-YAML file for all languages - module_name: '../osib/osib_macro' - include_dir: '../osib/include' - verbose: false # debug + - locale: pt-BR + name: pt-BR - Português (Brasil) + build: true + nav_translations: + Home: Início + Introduction: Introdução + About OWASP: Sobre a OWASP + What are Application Security Risks?: O que são Riscos de Segurança de Aplicações? + Establishing a Modern Application Security Program: Estabelecendo um Programa Moderno de Segurança de Aplicações + Top 10:2025 List: Lista do Top 10:2025 + A01 Broken Access Control: A01 Controle de Acesso Quebrado + A02 Security Misconfiguration: A02 Configuração Insegura + A03 Software Supply Chain Failures: A03 Falhas na Cadeia de Suprimentos de Software + A04 Cryptographic Failures: A04 Falhas Criptográficas + A05 Injection: A05 Injeção + A06 Insecure Design: A06 Design Inseguro + A07 Authentication Failures: A07 Falhas de Autenticação + A08 Software or Data Integrity Failures: A08 Falhas de Integridade de Software ou de Dados + A09 Security Logging and Alerting Failures: A09 Falhas de Registro e Monitoramento de Segurança + A10 Mishandling of Exceptional Conditions: A10 Tratamento Incorreto de Condições Excepcionais + Next Steps: Próximos Passos + - macros: # needs to be the last plugin to export the final osib-YAML file for all languages + module_name: "../osib/osib_macro" + include_dir: "../osib/include" + verbose: false # debug on_error_fail: true extra: - alternate: # see https://squidfunk.github.io/mkdocs-material/setup/changing-the-language/#site-language-selector + alternate: # see https://squidfunk.github.io/mkdocs-material/setup/changing-the-language/#site-language-selector - name: en - English link: ./en/ lang: en -# - name: de - Deutsch -# link: ./de/ -# lang: de + - name: pt-BR - Português (Brasil) + link: ./pt-BR/ + lang: pt-BR osib: - document: osib.owasp.top10 - version: 2025-0-1 -# document: # e.g. osib.owasp.top10 -# version: # e.g. 4-0, 2025-1-0 - categories: [document, awareness] # list of all default categories + document: osib.owasp.top10 + version: 2025-0-1 + # document: # e.g. osib.owasp.top10 + # version: # e.g. 4-0, 2025-1-0 + categories: [document, awareness] # list of all default categories default_lang: en - yaml_file: ../osib/include/osib.yml - export_dir: ../osib/export - latest: 2 # 2: add the latest version(s), if successor(s) exist, log an info - debug: 0 # debug level (0-3); default is 2 - cre: osib.owasp.cre.1-0 + yaml_file: ../osib/include/osib.yml + export_dir: ../osib/export + latest: 2 # 2: add the latest version(s), if successor(s) exist, log an info + debug: 0 # debug level (0-3); default is 2 + cre: osib.owasp.cre.1-0 successor_texts: - en: successor - de: Nachfolger + en: successor + de: Nachfolger split_to_texts: - en: split to - de: Aufgeteilt in + en: split to + de: Aufgeteilt in