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

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.