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

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.