Desenvolvedores: sua API foi projetada para invasores?

Quando uma organização tem um problema de segurança com uma API, geralmente é um problema construído internamente, de acordo com Jeremy Snyder, fundador e CEO da empresa de segurança de API FireTail.io.

A empresa de segurança analisou 40 violações públicas para ver qual o papel que as APIs desempenhavam nos problemas de segurança, que Snyder apresentou em sua apresentação na conferência Black Hat de 2023. O problema pode ser vulnerabilidades integradas, configurações incorretas na API ou até mesmo uma falha lógica no próprio aplicativo – e isso significa que cabe aos desenvolvedores corrigi-lo, disse Snyder.

“É uma variedade de coisas, mas geralmente é com suas próprias APIs”, disse Snyder ao The New Stack. “Está em seu domínio de influência e, honestamente, em seu domínio de controle, porque, em última análise, cabe a eles construir uma API segura.”

O número de violações analisadas é pequeno – limitou-se a violações divulgadas publicamente – mas Snyder disse que o problema é potencialmente muito mais difundido.

“Em primeiro lugar, 83% de todas as solicitações da Internet, se não mais, são solicitações de API”, disse ele. “Não é o volume total de tráfego. É o número de solicitações que fluem pela Internet diariamente, mais de quatro quintos de todas as solicitações são, na verdade, solicitações de API, e não consultas iniciadas pelo usuário.”

Nos últimos meses, disse ele, os pesquisadores de segurança que trabalham nesta área descobriram bilhões de registros que poderiam ter sido violados por meio de um design de API inadequado. Ele apontou para as falhas de design da API em basicamente todos os programas de passageiro frequente de operadoras de serviço completo, que poderiam ter exposto conjuntos de dados inteiros ou permitido a concessão de milhas e pontos de hotel ilimitados.

“Vimos alguns exemplos muito, muito importantes”, disse ele. “Efetivamente, todo o ecossistema de carros conectados teve falhas de design de API que poderiam ter exposto não apenas os proprietários de todos esses veículos, (mas isso) permite atualizar os registros do proprietário, permite desbloquear e ligar esses veículos e afastá-los .”

Snyder explicou alguns dos principais problemas de API e descreveu as práticas recomendadas que os desenvolvedores podem usar para melhorar as APIs.

Falhas comuns de API

A referência indireta de objeto, ou IDR, é um problema comum, disse Snyder. Ele permite que alguém com acesso de usuário legítimo manipule a solicitação da API para acessar os dados de outro usuário.

“Isso é muito comum – pode ser, por si só, o problema número um que vemos consistentemente em todo o conjunto de dados”, disse ele.

Outro problema comum é a exposição excessiva de dados, na qual a API retorna muitos dados. Por exemplo, uma página pode ter uma foto, seu nome, um endereço, qualquer coisa, e a API envia tudo – inclusive dados pessoais. Em seguida, o desenvolvedor depende do aplicativo móvel ou do navegador da web para ocultar todos os dados que não foram solicitados.

“É claro que os maus atores não seguem essas regras”, disse ele. “Eles não vão passar pelo seu aplicativo ou pela interface da web para tentar extrair dados da sua API.”

Os desenvolvedores não estão fazendo isso de propósito, mas erros acontecem quando outras pressões aumentam, acrescentou.

“Não creio que nenhum desenvolvedor pretenda retornar intencionalmente muitos dados ou construir intencionalmente uma API ruim”, disse ele. “Mas acho que há uma compensação entre a rapidez com que posso construir algo – velocidade e conveniência versus considerações de segurança e privacidade.”

Melhores práticas para corrigir falhas de API

Escreva uma especificação. Muito poucos desenvolvedores começam do zero absoluto quando estão construindo uma API, observou Snyder. Normalmente, eles usarão uma estrutura comum de código aberto para construir essa API. Parte desse trabalho inicial deve incluir um arquivo de especificações que rege como a API deve funcionar, disse ele.

Use ferramentas comuns. Não tente criar seu próprio tipo de mecanismo de identidade e autenticação, disse Snyder. “Há de tudo, desde WebAuthn até mecanismos de logon único, e quanto menos você criar e projetar em torno da identidade, maiores serão as chances de acertar facilmente, aproveitando uma solução comprovada”, disse ele.

Pense nos dados. “Pense em projetar sua API de uma forma que não exponha muito e também seja como verificar uma autorização para cada solicitação de dados”, sugeriu Snyder. Às vezes, os desenvolvedores enviam essa verificação de autorização para o frontend em um cliente móvel ou dispositivo da Internet das Coisas. Em um caso famoso, a autorização acontecia dentro da lógica de uma bicicleta ergométrica Peloton. “Novamente, você sabe, os hackers não seguem essas regras, então eles foram direto para a API Peloton usando a linguagem de script”, disse ele. “Eles começaram a manipular solicitações de autorização e conseguiram extrair cerca de 3 milhões de registros”.

A postagem Desenvolvedores: sua API foi projetada para invasores? apareceu primeiro em The New Stack.