Arquivo para Tag: Web Application Security

Por que API Security também é Web Application Security?

/em

No artigo anterior, falamos o quanto o estado atual de ferramentas para Web Application Security e Application Security não estão adaptados para trazer segurança para APIs. Hoje vamos falar porque uma boa estratégia de segurança para aplicações web deve passar por uma boa estratégia de segurança para APIs.

Podemos dizer que as APIs servem a 3 propósitos principais: compartilhamento de regras de negócio entre organizações, desacoplar o front-end do back-end e comunicação entre máquinas. O primeiro propósito pode ser visto desde o que se diz ser os primórdios das APIs no ano 2000, quando Salesforce e eBay disponibilizaram serviços para desenvolvedores incorporarem em suas aplicações por meio desta interface.

A partir de então, o uso da internet veio se intensificando, demandando aplicações mais complexas e interativas. O que não era bem atendido pelo padrão da época, em que as páginas eram geradas estaticamente pelo servidor e qualquer alteração de dados vinda do lado do servidor demandava a geração de uma nova página para ser visualizada. A introdução do AJAX deu início a uma arquitetura que veio para ficar, na qual o cliente que processa atualizações de conteúdo, a partir de requisições a endpoint que fornecem dados atualizados. Desde então vimos o surgimento de Single-Page Applications, frameworks reativos, aplicativos mobile e esses endpoints que alimentam o front-end também passaram a ser chamados de APIs. 

Já o terceiro propósito é mais recente, com a ascensão da Internet das Coisas e desenvolvimento da automação de infraestrutura. Os dois primeiros propósitos das APIs tocam diretamente o campo de aplicações web modernas. Hoje, é extremamente difícil você usar uma aplicação que não tenha pelo menos uma integração com uma empresa de meio de pagamentos ou de cartão de crédito. Como gerar e enviar uma nota fiscal ao governo sem pelo menos uma integração? E se você estivesse comprando em um e-commerce e a página fosse recarregada enquanto você estivesse validando um cupom? Sua visão sobre a experiência não seria nem um pouco afetada?

As APIs são fundamentais para a experiência com aplicações web, e não há um caminho alternativo emergente. O problema é que essa atenção para elas ainda não chegou ao campo de segurança. É comum ver times de desenvolvimento considerando como o suficiente apenas autenticação, SSL e cuidado com ataques comuns como injection. Ou então, equipes de segurança que recebem os pacotes antes do lançamento e fazem avaliações sobre o risco daquele código específico. Ou equipes de operações que consideram WAF e API Gateway e monitoramento das redes o suficiente. Por que essas abordagens não são o suficiente?

O desenvolvimento das APIs trouxe consigo novas práticas. Entre elas, a arquitetura de microsserviços. Como consequência, o risco de uma falha de segurança na interação entre serviços cresce exponencialmente à medida que novos serviços são adicionados. Um provável reflexo disso é o comportamento da Quebra de Controle de Acesso nas listas da OWASP. Na primeira divulgação, em 2004, essa vulnerabilidade ocupava a segunda posição. Após a evolução do conhecimento sobre o assunto e a incorporação disso em frameworks de aplicação, esse problema ocupava a quinta posição na lista de 2017. Agora, se olharmos para a primeira OWASP Top 10 para API, de 2019, a principal ameaça é um tipo de Quebra de Controle de Acesso. E na última publicação da principal lista da OWASP, em 2021, essa vulnerabilidade está no topo, enquanto Injection, que historicamente tem sido um dos principais temores de quem se preocupa com segurança de aplicações, caiu para a terceira posição.

Usando como exemplo o BOLA (Broken Object Level Authorization), que ocupa o topo da OWASP para APIs e é uma quebra de controle de acesso, sua exploração gera uma requisição com características iguais à de um usuário normal, dificultando sua detecção por um WAF (para mais detalhes, veja o artigo anterior). Uma estratégia de mitigação eficiente demanda informações contextuais da lógica da aplicação. Informações que precisam ser adquiridas com agilidade, uma vez que toda essa evolução na arquitetura das aplicações web contribuiu para um salto na velocidade de lançamentos de novas features.

Essa maior velocidade na implementação de código em produção é um fator que piora o cenário de vulnerabilidade em APIs/Aplicações Web. Uma pesquisa da ESG (Enterprise Strategy Group) apontou que 48% dos respondentes lançam código com vulnerabilidade com frequência. Entre os principais motivos, 54% responderam que foi para cumprir um deadline e 45%, porque as vulnerabilidades foram descobertas muito tarde para serem corrigidas a tempo. Imagine a potencial superfície de ataque em um ambiente com inúmeras APIs (algumas não catalogadas e “esquecidas” pelo time, inclusive), múltiplos microsserviços se comunicando, sendo que frequentemente alguns deles contêm vulnerabilidades.

Portanto, é fundamental que uma abordagem que resolva problemas específicos de segurança para APIs esteja incluída em uma abordagem de segurança para aplicações web. 

Diante disso, é dever da GoCache se alinhar às novas necessidades, assim, anunciamos que estamos desenvolvendo uma nova suite para proteção de APIs. 

Uma série de novidades serão anunciadas, e se você quiser saber em primeira mão e participar do beta, entre em contato com produto@gocache.com.br. 

Vamos construir o futuro da Segurança de Aplicações Web juntos?

Por Victor Queiroz Vilas Boas, Product Manager GoCache.

Por que Web Application Security não é suficiente para segurança em API’s?

/em ,

Houve um tempo em que as aplicações web eram formadas por um grande bloco de código, homogêneo, em que o backend já entregava a página renderizada ao cliente. Esse grande bloco era hospedado em um grande servidor (ou alguns), dentro de um datacenter, no qual o perímetro de rede era ferrenhamente guardado, tal qual um castelo, mas onde tudo o que estivesse dentro do perímetro, era considerado seguro.

Ok! Isso não é assunto para arqueologia, já que boa parte das aplicações atuais ainda usam essa arquitetura. Mas o ponto importante aqui, é que as ferramentas de Web Application Security, como WAF e Application Security, como Application Security Testing (AST) surgiram dentro deste paradigma.

Como as páginas eram entregues prontas do servidor, a aplicação era um bloco homogêneo e estável, e o perímetro de rede era totalmente conhecido e controlável, a superfície de ataques era bastante reduzida e em questão de alguns ajustes, a proteção de um WAF era efetiva. Da mesma forma, testes com SAST e DAST reproduziam o comportamento da aplicação em produção, com menos distorções.

Mas de lá para cá, muita coisa vem acontecendo gradualmente: Single-Page Application, Mobile, integração entre empresas, cloud, frameworks de frontend reativos, arquitetura de microsserviços. E junto com tudo isso, emergiu um elemento fundamental para o funcionamento de tudo o que foi mencionado anteriormente: API ou Application Programing Interface.

A segurança de APIs é peculiar em relação à segurança de aplicações web a ponto de ter a sua própria lista de top 10 ameaças da OWASP. Apesar de ter grandes vulnerabilidades em comum com aplicações web, como injection, estão em destaque problemas de autenticação e autorização, como Broken Object Level Authorization e Broken Authentication.

Um exemplo destes tipos de vulnerabilidade aconteceu com a Uber em 2019. Ao criar uma conta, o browser do motorista enviava uma chamada com o parâmetro “userUuid”, e em troca recebia um JSON com detalhes da conta. O problema é que a API não validava que quem estava chamando era realmente o dono do “userUuid”, sendo que um atacante poderia enviar uma chamada com o “userUuid” de qualquer usuário, recebendo dentre outras informações sensíveis, o token de identificação, que poderia ser usado para roubar a conta. Felizmente isso foi descoberto antes de ser explorado, mas mostra a gravidade do problema.

E por que um WAF não protege contra um ataque como esse? A resposta é que esse tipo de vulnerabilidade depende intimamente do contexto específico da aplicação. No caso acima, a requisição é idêntica a uma requisição comum, de forma que difícil ela se encaixaria no padrão de alguma regra. Seria necessário detectar que a chamada na API não foi realizada em um fluxo normal, ou que o atacante não tem autorização sobre o “userUuid”, o que é muito específico à forma como a aplicação foi construída.

Algumas são as razões para a emergência dessas vulnerabilidades específicas. Como a renderização é feita do lado do cliente, as APIs ficam mais próximas às fontes de dados sensíveis. Além disso, com a emergência da arquitetura de microsserviços, a autenticação e a lógica da API são executadas em serviços diferentes, provavelmente geridos por equipes diferentes. Mesmo que as equipes adotem boas práticas de autorização, cada interação entre microsserviços corre o risco de expor uma falha. Como a complexidade se eleva exponencialmente em relação à quantidade de serviços e equipes, os pontos potenciais de falha são multiplicados. Por isso AST também perde eficiência neste contexto: o código do serviço pode estar perfeito, mas o problema está na interação com outros serviços.

Tendo em vista tudo o que foi mencionado, para a GoCache, é fundamental investir em novas soluções mais direcionadas aos problemas de vulnerabilidades de API. E é exatamente o que está acontecendo! Estamos preparando uma série de novidades em uma nova suite de produtos de API Protection.

Entre em contato com produto@gocache.com.br para participar do beta e ajudar a construir o futuro da Segurança de Aplicações Web. Afinal, API Security também é Web Application Security, e esse é o tema do próximo artigo desta série.

Por Victor Queiroz Vilas Boas, Product Manager GoCache.