好色先生TV

O Open Web Application Security Project (OWASP) é uma comunidade de seguran?a de aplicativos de código aberto com o objetivo de melhorar a seguran?a do software. O OWASP Top 10 é uma diretriz padr?o do setor que lista os riscos de seguran?a de aplicativos mais críticos para ajudar os desenvolvedores a proteger melhor os aplicativos que projetam e implantam.

Como os riscos de seguran?a est?o em constante evolu??o, a lista OWASP Top 10 é revisada periodicamente para refletir essas mudan?as. Na vers?o mais recente da OWASP Top 10, lan?ada em 2021, alguns tipos de vulnerabilidades que n?o representam mais uma amea?a séria foram substituídos por outros que provavelmente representar?o um risco significativo.

Embora o OWASP Top 10 seja um ótimo lugar para come?ar a proteger os aplicativos, ele certamente n?o deve ser considerado como um objetivo final, pois algumas das vulnerabilidades mais citadas n?o entraram no OWASP Top 10 2021. Para se protegerem contra os pontos fracos do software, os defensores precisam examinar de forma mais ampla toda a pilha de tecnologia da informa??o. Isso significa que os profissionais de seguran?a de TI precisam se concentrar em todo o ecossistema de software e olhar além das fontes "tradicionais" de vulnerabilidades.

Quais s?o as categorias do OWASP Top 10 (2021)?

A1: Inje??o

As falhas de inje??o podem ser introduzidas sempre que uma fonte de dados n?o confiável é enviada a um intérprete. Os exemplos s?o frequentemente encontrados em consultas a bancos de dados din?micos SQL, LDAP, XPath ou NoSQL com entrada fornecida pelo usuário. Os invasores injetam código na entrada do usuário, induzindo o interpretador de consultas a executar comandos maliciosos.

O que torna um aplicativo vulnerável a falhas de inje??o?

• Os dados fornecidos pelo usuário n?o est?o sendo suficientemente validados.
• As consultas din?micas s?o executadas sem sanitiza??o de entrada suficiente.
• Dados hostis usados nos sistemas para comportamento malicioso.

Qual é o impacto das falhas de inje??o?

• Comprometimento do aplicativo ou do host subjacente.
• Exposi??o de dados confidenciais.
• Perda de produtividade, reputa??o ou receita.

Como o site Fortify pode ajudar com as falhas de inje??o?

• Se você for um desenvolvedor: Fortify detecta falhas de inje??o e fornece conselhos de corre??o específicos para cada tipo.
• Se você trabalha com controle de qualidade ou opera??es: Fortify valida o código em tempo de execu??o para controles de atenua??o.
• Se você estiver em Opera??es: Fortify fornece registro em tempo de execu??o e prote??o para tentativas de inje??o em Java e .NET.

---

A2: Autentica??o interrompida

A autentica??o quebrada pode ser introduzida ao gerenciar dados de identidade ou de sess?o em aplicativos com estado. Exemplos s?o frequentemente encontrados quando o registro, a recupera??o de credenciais e os caminhos de API s?o vulneráveis a tokens de sess?o n?o expirados, for?a bruta ou enumera??o de contas. Os invasores assumem a identidade de usuários legítimos, assumindo o controle de contas e comprometendo dados, processos ou sistemas.

O que torna um aplicativo vulnerável à quebra de autentica??o?

• Exp?e, n?o invalida adequadamente ou falha na rota??o de IDs de sess?o.
• N?o alinha as políticas de senha com padr?es como o NIST 800-63B.
• N?o possui autentica??o de dois fatores (2FA) ou permite ataques automatizados.

Qual é o impacto da autentica??o interrompida?

• Roubo de identidade do usuário.
• Perda da confian?a do usuário.
• Comprometimento de dados confidenciais.

Como o site Fortify pode ajudar?

• Se você for desenvolvedor: Fortify detecta e recomenda a corre??o de problemas de autentica??o interrompida.
• Se você estiver em QA ou Opera??es: Fortify valida a autentica??o e a seguran?a do gerenciamento de sess?es de forma din?mica.
• Se você estiver em Opera??es: Fortify instrumenta o monitoramento de tempo de execu??o para eventos de aplicativos Java e .NET.

---

A3: Exposi??o de dados confidenciais

Problemas de exposi??o a dados confidenciais podem ser introduzidos quando os aplicativos acessam dados n?o criptografados, principalmente informa??es de identifica??o pessoal (PII) e outros tipos de dados regulamentados. Os exemplos s?o frequentemente encontrados quando cifras criptográficas fracas s?o usadas em aplicativos legados, protocolos de transporte seguro s?o implementados incorretamente ou a seguran?a centrada em dados n?o está em uso. Os invasores obtêm acesso a dados confidenciais do usuário que lhes d?o controle na vida real.

O que torna um aplicativo vulnerável à exposi??o de dados confidenciais?

• Transmiss?o de dados em texto claro por meio de protocolos como HTTP, SMTP e FTP.
• Dados confidenciais sendo armazenados, transmitidos ou usados desnecessariamente em texto claro.
• Uso de algoritmos criptográficos antigos, fracos ou n?o baseados em padr?es.

Qual é o impacto da exposi??o de dados confidenciais?

• Comprometimento de dados regulamentados (por exemplo, HIPAA ou GDPR), resultando em multas.
• Sequestro de identidade, resultando em custos para limpar ou monitorar dados.
• Status de n?o conformidade com as leis e normas de privacidade.

Como o site Fortify pode ajudar na exposi??o de dados confidenciais?

• Se você for um desenvolvedor: Fortify identifica a exposi??o de dados confidenciais e automatiza a auditoria de problemas.
• Se você trabalha com controle de qualidade ou opera??es: Fortify remove descobertas atenuadas fora do contexto do aplicativo com modelos.
• Se estiver na área de Opera??es: Fortify registra e protege instrumentos para aplicativos em Java e .NET.

---

A4: Entidades externas XML

Os problemas de entidade externa XML podem ser introduzidos quando uma entrada XML que contém uma referência a uma entidade externa é processada por um analisador mal configurado. Os exemplos s?o frequentemente encontrados em aplicativos que analisam a entrada XML de fontes n?o confiáveis, quando as DTDs (Document Type Definitions, defini??es de tipos de documentos) est?o ativadas ou que usam estruturas n?o corrigidas, como o SOAP 1.0. O XML está em toda parte, desde arquivos SVG e de imagem até protocolos de rede e formatos de documentos, como PDF e RSS. Os invasores fazem referência a entidades externas na entrada XML, o que resulta em processadores explorados para extrair dados, executar códigos remotamente ou afetar os servi?os de rede.

O que torna um aplicativo vulnerável a entidades externas XML?

• O aplicativo analisa documentos XML e os processadores têm DTDs ativados.
• Usar SAML para SSO, SOAP anterior à v1.2 ou .NET Framework anterior à v2.0.
• O analisador aceita fontes n?o confiáveis ou insere dados XML n?o confiáveis.

Qual é o impacto das entidades externas XML?

• Roubo de dados confidenciais.
• Carregamento de URL controlado por invasor.
• Ataques de nega??o de servi?o (DoS).

Como o site Fortify pode ajudar com entidades externas XML?

• Se você for um desenvolvedor: Fortify detecta analisadores XML vulneráveis e recomenda fatores de atenua??o.
• Se você trabalha com controle de qualidade ou opera??es: Fortify verifica automaticamente se há analisadores XML vulneráveis e valida cargas úteis de explora??o.
• Se você trabalha com opera??es: Fortify oferece registro em tempo de execu??o e prote??o para problemas em aplicativos Java e .NET.

---

A5: Controle de acesso quebrado

Problemas de controle de acesso podem ser introduzidos quando o código e as restri??es ambientais se sobrep?em de forma incompleta ou s?o definidos em vários locais para uma funcionalidade semelhante. Exemplos s?o encontrados com frequência quando a seguran?a por obscuridade é quebrada por meio de navega??o for?ada em páginas restritas ou quando o aplicativo define métodos complexos para controle de acesso de várias maneiras e locais. Os invasores podem comprometer os limites de acesso para roubar dados confidenciais ou interromper as opera??es.

O que torna um aplicativo vulnerável a falhas no controle de acesso?

• Capacidade de atuar como usuário sem login ou como administrador quando conectado como usuário.
• Manipula??o de metadados ou tokens para privilégios n?o autorizados ou elevados.
• Lógica de controle de acesso bizantina, n?o aplicada ou dispersa.

Qual é o impacto de um controle de acesso interrompido?

• Divulga??o de informa??es n?o autorizadas ou comprometimento de dados confidenciais.
• Modifica??o ou destrui??o de dados.
• Controle da administra??o do site ou dos usuários.

Como o site Fortify pode ajudar com o controle de acesso interrompido?

• Se você for um desenvolvedor: Fortify automatiza a auditoria e permite a cria??o de modelos para remover problemas atenuados em outros lugares.
• Se você trabalha com controle de qualidade e opera??es: os agentes do Fortify detectam superfícies de ataque ocultas e sistemas de controle de acesso quebrados.
• Se você estiver em Opera??es: Fortify instrumenta o registro de controle de acesso em tempo de execu??o para aplicativos Java e .NET.

---

A6: Configura??o incorreta da seguran?a

As falhas de configura??o incorreta da seguran?a podem ser introduzidas durante a configura??o do aplicativo ou de seu ambiente subjacente. A configura??o incorreta pode ocorrer em qualquer nível de uma pilha de aplicativos, desde servi?os de rede e servidores de aplicativos até contêineres e armazenamento. Os exemplos s?o frequentemente encontrados em contas e configura??es padr?o, mensagens de erro com "vazamento" ou estruturas e servi?os sem patches. Os invasores podem obter informa??es de implementa??o e acesso a dados privilegiados para interromper as opera??es.

O que torna um aplicativo vulnerável à configura??o incorreta da seguran?a?

• Portas e contas padr?o ativadas desnecessariamente ou senhas inalteradas.
• Revela??o do rastreamento de pilha ou de outras mensagens em caso de erros e exce??es.
• N?o fortalecer adequadamente a seguran?a em rela??o ao risco apresentado por qualquer parte da pilha.

Qual é o impacto da configura??o incorreta da seguran?a?

O impacto pode variar desde a divulga??o de informa??es até o comprometimento total do sistema.

Como o site Fortify pode ajudar com a configura??o incorreta da seguran?a?

• Se você for um desenvolvedor: Fortify identifica dependências de aplicativos e arquivos de configura??o durante as varreduras.
• Se você trabalha com controle de qualidade e opera??es: Fortify avalia dinamicamente as configura??es de aplicativos e servidores em busca de problemas.
• Se você trabalha na área de Opera??es: Fortify fornece análises de código aberto para relatórios sobre riscos ambientais.

---

A7: Script entre sites

As falhas de XSS (Cross-Site Scripting) podem ser introduzidas quando uma entrada de usuário n?o confiável e n?o higienizada é executada como parte do HTML ou quando os usuários podem ser influenciados a interagir com links maliciosos. Exemplos s?o encontrados com frequência quando constru??es de código familiares de linguagens como JavaScript ou Flash s?o aceitas de fontes n?o confiáveis ou armazenadas para exibi??o posterior por outro agente de usuário. Os invasores podem executar códigos remotos no computador do usuário, roubar credenciais ou fornecer malware a partir de sites de redirecionamento.

O que torna um aplicativo vulnerável a cross-site scripting (XSS)?

Há três formas de XSS, geralmente direcionadas a agentes de usuário, como navegadores:

• XSS refletido: o aplicativo ou a API inclui entrada n?o confiável na saída HTML.
• XSS armazenado: o código n?o higienizado salvo no disco é acionado posteriormente pela a??o do usuário.
• DOM XSS: aplicativos, estruturas e APIs que consomem entradas n?o confiáveis.

Qual é o impacto do XSS (cross-site scripting)?

• Controle da conta da vítima no aplicativo.
• Recupera??o de dados do aplicativo da Web de destino.
• Modifica??o do conteúdo da página.

Como o site Fortify pode ajudar com o XSS (cross-site scripting)?

• Se você for um desenvolvedor: Fortify detecta vulnerabilidades de XSS no código e prevê a probabilidade de explora??o.
• Se você trabalha com controle de qualidade e opera??es: Fortify valida o código dinamicamente em busca de entradas n?o higienizadas vulneráveis a XSS.
• Se você estiver em Opera??es: Fortify fornece registro de eventos Java e .NET, incluindo redirecionamento n?o autorizado.

---

A8: desserializa??o insegura

Falhas inseguras de desserializa??o podem ser introduzidas quando linguagens e estruturas permitem que dados serializados n?o confiáveis sejam expandidos para um objeto, geralmente quando os aplicativos da Web est?o comunicando o usuário ou salvando o estado do aplicativo. Os exemplos s?o encontrados com frequência quando os desenvolvedores n?o imp?em restri??es aos métodos que podem ser autoexecutados durante o processo de desserializa??o. Os invasores aproveitam essas "cadeias de gadgets" chamadas fora da lógica do aplicativo para executar códigos remotamente, negar servi?os ou obter acesso n?o autorizado.

O que torna um aplicativo vulnerável à desserializa??o insegura?

• O aplicativo desserializa dados de fontes n?o confiáveis.
• O aplicativo n?o verifica a origem ou o conteúdo antes da desserializa??o.
• As classes aceitáveis n?o s?o incluídas na lista de permiss?es para evitar a exposi??o desnecessária do gadget.

Qual é o impacto da desserializa??o insegura?

• Essas falhas podem levar a ataques de execu??o remota de código, um dos ataques mais graves possíveis.

Como o site Fortify pode ajudar com a desserializa??o insegura?

• Se você for um desenvolvedor: Fortify detecta vulnerabilidades no código-fonte e fornece análise de componentes.
• Se você trabalha com controle de qualidade e opera??es: Fortify instrumenta aplicativos executados dinamicamente para validar vetores de ataque.
• Se você estiver em Opera??es: Fortify instrumenta o registro de eventos Java e .NET, incluindo a desserializa??o.

---

A9: Uso de componentes com vulnerabilidades conhecidas

Essas falhas podem ser introduzidas quando estruturas e bibliotecas de código aberto ou de terceiros s?o introduzidas em um aplicativo e executadas com os mesmos privilégios. Exemplos s?o frequentemente encontrados quando o desenvolvimento baseado em componentes resulta em uma falta de compreens?o dos riscos associados às dependências e componentes ou sistemas difíceis ou impossíveis de serem corrigidos. Os invasores utilizaram componentes vulneráveis para algumas das maiores viola??es da história, embora as vulnerabilidades possam variar do comprometimento do aplicativo à execu??o remota de código.

O que torna um aplicativo vulnerável a estruturas e bibliotecas de código aberto ou de terceiros?

• Eles podem ser acidentais (por exemplo, erro de codifica??o) ou intencionais (por exemplo, componente backdoored).
• O aplicativo ou o ambiente usa componentes sem patches ou desatualizados (um dos motivos pelos quais é essencial).
• Falta de varredura de vulnerabilidades em códigos de terceiros ou dependências aninhadas.
• Inventários de componentes indisponíveis ou boletins de seguran?a ignorados.

Qual é o impacto do uso de componentes com vulnerabilidades conhecidas?

Embora algumas vulnerabilidades conhecidas causem apenas impactos menores, algumas das maiores viola??es conhecidas, como Heartbleed e Shellshock, basearam-se na explora??o de vulnerabilidades conhecidas em componentes compartilhados. O uso de componentes com vulnerabilidades de código conhecidas pode resultar na execu??o remota de código no servidor afetado, dando ao invasor o controle total da máquina.

Como o site Fortify pode ajudar na seguran?a de código aberto?

• Se você é desenvolvedor: Fortify fornece análise de componentes de software por meio de integra??es Sonatype.
• Se você trabalha com controle de qualidade e opera??es: Fortify automatiza a valida??o din?mica de vulnerabilidades conhecidas em tempo de execu??o.
• Se você estiver em Opera??es: Fortify registra e protege instrumentos para componentes de aplicativos Java e .NET.

---

A10: Registro e monitoramento insuficientes

Falhas insuficientes de registro e monitoramento podem ser introduzidas quando os vetores de ataque ou o mau comportamento do aplicativo n?o s?o bem compreendidos ou quando as práticas recomendadas de monitoramento de indicadores de comprometimento n?o s?o seguidas. Os exemplos s?o frequentemente encontrados em sistemas legados sem recursos de registro, quando os registros de testes de penetra??o de aplicativos n?o s?o examinados ou quando os registros n?o fornecem detalhes suficientes para entender o que os invasores fizeram. Os atacantes contam com uma média de cerca de 200 dias para a detec??o, que normalmente é descoberta externamente, para estabelecer a persistência e se direcionar a outros sistemas vulneráveis.

O que torna um aplicativo vulnerável a registros e monitoramento insuficientes?

• Avisos e erros geram mensagens de registro inexistentes, inadequadas ou pouco claras.
• Os registros s?o armazenados localmente sem controles de viola??o e/ou n?o s?o monitorados.
• Os limites de alerta e os processos de resposta s?o insuficientes ou n?o resultam em nenhuma a??o.

Qual é o impacto do registro e do monitoramento insuficientes?

A maioria dos ataques bem-sucedidos come?a com a sondagem de vulnerabilidades. Permitir que essas sondagens continuem pode aumentar a probabilidade de explora??es bem-sucedidas. Os invasores podem estabelecer persistência, fazer backdooring de aplicativos e sistemas operacionais, roubar dados ou, de outra forma, obter controle desapercebido e n?o autorizado dos sistemas. Se as informa??es críticas de seguran?a n?o forem registradas ou armazenadas adequadamente, n?o haverá nenhum rastro para que a análise forense descubra a origem do ataque. Entender que existe um problema pode se tornar mais difícil ou impossível se o invasor mantiver o controle dos recursos de registro.

Como o site Fortify pode ajudar com o registro e o monitoramento insuficientes?

• Se você for desenvolvedor: Fortify verifica os recursos de registro em aplicativos e APIs em busca de vulnerabilidades.
• Se você trabalha com controle de qualidade e opera??es: Fortify , as varreduras din?micas produzem registros de aplicativos para análise de suficiência, como testes de caneta.
• Se você estiver em Opera??es: Fortify instrumentos de registro e prote??o para aplicativos Java e .NET.

---

O que há de novo na OWASP (2021)?

Embora tenham se passado apenas quatro anos desde que o último top 10 foi lan?ado em 2017, houve muitas mudan?as no setor de seguran?a cibernética, o que nos fez pensar duas vezes sobre as preocupa??es de prioridade máxima ou sobre quais novas preocupa??es adicionar.

Três novas categorias foram introduzidas:

A04:2021

Design inseguro: Essa categoria se concentra nas falhas de design. Isso é necessário porque o movimento de deslocamento para a esquerda no desenvolvimento exige um deslocamento para a esquerda também na modelagem de amea?as.

A08:2021

Falhas de integridade de software e dados: Concentra-se em suposi??es sobre atualiza??es de software, dados críticos e o pipeline de CI/CD sem verificar a integridade que eles podem afetar. Isso também incorpora a A08:2017 - Insecure Deserialization (desserializa??o insegura).

A10:2021

Falsifica??o de solicita??o do lado do servidor (SSRF): Essa categoria está principalmente entre as 10 principais da pesquisa da comunidade. Eles realmente enfatizaram essa vulnerabilidade devido à capacidade de explora??o e ao impacto acima da média.

Outras altera??es

As outras categorias tiveram mudan?as de nome, subiram de posi??o ou foram consolidadas em outras categorias:

• A01:2017 - A inje??o foi transferida para A:03.
• A02:2017 - Autentica??o interrompida foi renomeada para Falhas de identifica??o e autentica??o e transferida para A07.
• A03:2017 - Exposi??o de dados confidenciais foi transferida para A02 e renomeada como Falhas criptográficas para abordar mais completamente a causa raiz, n?o apenas os sintomas.
• A05:2017 - Broken Access Control foi movido para A01 porque 94% dos aplicativos testados mostraram exposi??o a alguma forma de Broken Access Control.
• A06:2017 - Configura??o incorreta da seguran?a foi movida para o lugar A05.
• A07:2017 - Cross-Site Scripting (XSS) foi consolidado em A03 Injection.
• A09:2017 - Uso de componentes com vulnerabilidades conhecidas foi movido para A06 e renomeado como Componentes vulneráveis e desatualizados. Essa mudan?a se deveu em grande parte ao fato de a comunidade classificá-la em segundo lugar em sua lista.
• A10:2017 - Insufficient Logging & Monitoring (Registro e monitoramento insuficientes) subiu para A09 e agora se chama Security Logging and Monitoring Failures (Falhas no registro e monitoramento de seguran?a).

Deseja ver como o Fortify pode ajudar sua organiza??o? Inicie sua