0
0
As listas dos Dez Melhores da Fundação OWASP ajudaram os defensores a concentrar seus esforços em relação a tecnologias específicas e a API OWASP (Interface de Programação de Aplicativos) Security Top 10 2023 não é exceção. Elaborado pela primeira vez há cinco anos e atualizado este ano, visa abordar mudanças nos métodos de ataque.
No entanto, os líderes do Projeto de Segurança de API OWASP tiveram um trabalho difícil ao decidir como agrupar e priorizar as ameaças. A lista é elaborada com base nas contribuições da indústria e deve refletir as preocupações de conformidade, por isso nunca satisfaria completamente todas as pessoas. A questão é: isso vai longe o suficiente para ser valioso para aqueles que estão envolvidos no assunto quando se trata de desenvolvimento e defesa de API?
O que mudou e o que permaneceu igual?
Ao comparar a lista antiga e a nova, podemos ver que as duas principais ameaças – API1 Broken Object Level Authorization (BOLA) e API2 Broken User Authentication – permaneceram inalteradas. API1 denota a manipulação da identificação de um objeto que é enviado dentro de uma solicitação à API enquanto API2 marca o abuso de mecanismos de autenticação por meio de ataques como preenchimento de credenciais, incluindo funções de senha esquecida/restante. Eles fornecem as vitórias mais rápidas para os invasores e é fácil ver por que continuam no topo da lista.
API3 substituiu a exposição excessiva de dados pela autorização em nível de propriedade de objeto quebrado. Isso significa que resolvemos o problema da exposição de dados confidenciais? Infelizmente, não, continua a ser um grande problema. O que esta mudança significa é o próximo estágio que um invasor executaria ao explorar a exposição de dados confidenciais, ou seja, romper a autorização em nível de propriedade. Então porque é que o Projecto decidiu fazer a mudança? Provavelmente por uma questão de clareza, porque a exposição de dados confidenciais é um problema que abrange o resto da lista. Mas alguns, incluindo eu próprio, argumentariam que esta não é a forma correcta de apresentar a questão, porque desclassifica o que é uma questão muito séria.
Da mesma forma, API6 foi Atribuição em Massa em 2019 e agora é Acesso Irrestrito a Fluxos de Negócios Sensíveis. Eles são diferentes? Na verdade. Ambos estão falando sobre aproveitar objetos e suas propriedades dentro do fluxo do aplicativo, com os exemplos listados na página do projeto referindo-se a um aplicativo de compartilhamento de carona onde a funcionalidade é explorada no backend. Há, no entanto, algo sutil na nomenclatura que faz a versão 2023 parecer algo que precisa ser consertado, em vez de ser nebuloso e confuso, portanto, nesse aspecto, é uma melhoria.
Traga bots para a mistura
A API6 também mostra como uma API que não está funcionando corretamente pode rapidamente acabar com a automação de ataques sendo utilizada contra ela na forma de ataques de bot. Isto é importante porque sempre houve uma distinção artificial entre ataques de API e de bot, com o setor de segurança oferecendo soluções diferentes para cada um quando a realidade é que ataques automatizados podem e são lançados contra APIs. Portanto, não faz mais sentido monitorar ataques de API e ataques de bots separadamente: a mitigação de bots precisa se tornar parte da segurança da API. Isto é evidente no nosso relatório recente , que revelou que os ataques automatizados ofuscaram outros TTPs na análise do tráfego durante o último trimestre de 2022.
No geral, a nova lista redefine em grande parte muitas das tácticas, técnicas e procedimentos (TTP) anteriores, numa tentativa de ser mais inclusiva. A API4, por exemplo, passou de Falta de Recursos e Limitação de Taxa para Consumo Irrestrito de Recursos, refletindo o fato de que a limitação de taxa se estende além da questão da capacidade da rede. Outros recursos que podem ser abusados se os limites não forem definidos incluem CPU, memória e armazenamento, por exemplo, mas igualmente importante, os provedores de serviços podem encontrar recursos de serviço esgotados pelas solicitações de API. Eles podem fornecer e-mails, mensagens de texto ou chamadas telefônicas e uma solicitação repetida de API pode fazer com que o provedor de serviços acumule enormes custos de serviço.
No entanto, existem algumas mudanças na ordem e novos conceitos no final. A configuração incorreta de segurança da API7 cai para a API8, pois houve progresso nesta área.
API7 agora é Server Side Request Forgery (SSRF). As APIs são o principal alvo dos ataques SSRF porque canalizam rotineiramente o tráfego de saída de um aplicativo. Os desenvolvedores geralmente acessam recursos externos, como web hooks, busca de arquivos de URLs ou SSO personalizado e visualizações de URL – afirma o Projeto – ou provedores de nuvem ou contêineres expõem canais de gerenciamento e controle ao comprometimento via HTTP. E a antiga API8, ataques de injeção? Essa não é mais uma ameaça categorizada separadamente porque normalmente é adotada em muitos dos outros tipos de ataque.
Mudanças significativas
A API9 vê outra mudança sutil, mas importante, na redação: de gerenciamento inadequado de ativos para gerenciamento inadequado de estoques. Isso reflete o aumento do número de APIs shadow que estão por aí e que, uma vez implantadas, não são mais monitoradas e efetivamente saem do radar da equipe de segurança. Não gerenciadas, desconhecidas e desprotegidas, essas APIs são alvos fáceis para invasores que agora as procuram ativamente. Na verdade, descobrimos que foram feitas 45 mil milhões de tentativas de pesquisa para APIs shadow durante o segundo semestre de 2022, em comparação com cinco mil milhões durante os primeiros seis meses. Um inventário de API em tempo de execução que monitore continuamente as APIs de produção é, portanto, vital para garantir que todas as APIs que entram em operação sejam protegidas, mas é uma das principais falhas nas organizações atualmente.
Finalmente, a API10 mudou de registro e monitoramento insuficientes, agora amplamente cobertos pela API9, para consumo inseguro de APIs. Isso reflete a extensão que vimos da cadeia de software de API, com APIs agora sendo frequentemente integradas a outras APIs. O problema que surgiu é que os desenvolvedores tendem a confiar inerentemente nas interações com essas APIs externas, especialmente de empresas conhecidas, mesmo que elas possam apresentar falhas e/ou vazar dados.
Claramente, muito foi pensado para ajustar o Top Ten da API OWASP para abordar com mais precisão os TTPs que os invasores estão usando agora. O resultado apresenta alterações menores e algumas alterações importantes na lista, todas elas justificadas. Na verdade, não são os descritores, mas a própria lista que é problemática. É um conceito arbitrário projetado para atrair a atenção e aumentar o perfil da segurança da API, mas será que ele contribui para promover a forma como nos defendemos contra esses ataques?
Como isso se comporta em um cenário de ataque
Se usarmos a análise de violação, podemos comparar uma violação típica com as categorias da lista para ver como o conceito se compara. Muitas violações começam com uma API que a organização vítima não sabia que possuía (API9 na lista de 2023). Essa API retorna algum tipo de dado sobre um usuário que não é o invasor (API1). Agora o invasor vai criar uma automação de ataque usando um bot para tentar explorar isso da forma mais rápida e completa possível (API6), completando a cadeia de ataque e dando ao invasor acesso aos dados ocultos nos sistemas da organização vítima.
É evidente que tal ataque cruzaria pelo menos três das categorias de ataque, portanto priorizá-las torna-se irrelevante. Na verdade, estes três ataques estão a ganhar terreno, com 100 milhões detetados durante o primeiro semestre de 2022.
Além do mais, além de vermos os invasores se movimentarem durante um ataque e utilizarem TTPs conhecidos, também os vemos criar TTPs exclusivos para tentar subverter a API. Estes cresceram mais de cinco vezes entre Junho e Novembro (de 2.000 para 11.000). A maioria desses ataques foi voltada para obter controle de contas (ATO), raspagem para realizar reconhecimento ou exfiltração de dados e caçar falhas de lógica de negócios na API para cometer fraudes.
Acompanhar ataques tão diversos exige que a equipe de segurança se concentre não apenas em sua defesa, mas também em métodos de detecção e mitigação. Seja para saber onde estão as APIs, testá-las em busca de falhas ou impedir que bots ataquem fluxos desconhecidos, a segurança da API precisa se tornar mais abrangente, rastreando e protegendo a API durante todo o seu ciclo de vida.
Um bom resumo dos TTPs
O novo OWASP API Top 10 pode não ser perfeito, mas cobre as bases e fornece um excelente ponto de partida para abordar o tópico. Reconhece agora que alguns métodos de ataque, como dados confidenciais e ataques de exposição e injeção, abrangem vários TTPs e, portanto, não requerem uma categoria separada. Também amplia a necessidade de mitigação de bots como parte da segurança da API e a natureza complexa dos ecossistemas de API que os vêem integrados entre si, por exemplo.
Mas a sua estrutura não permite mostrar como estes ataques estão a ser utilizados na natureza. Ele ainda compartimenta esses ataques quando os atores das ameaças estão se tornando muito mais versáteis e combinando-os.
Realisticamente, a única maneira de acompanhar esse cenário de ameaças em rápida evolução é monitorar e gerenciar essas APIs. Criar um inventário em tempo de execução, conduzir avaliações de superfície de ameaças de API, realizar detecção de anomalias de especificações e implementar detecção e mitigação automatizada de bots em tempo real são agora essenciais para proteger a pegada de API do negócio.
FONTE: HELP NET SECURITY