Por que a segurança de API é assunto de todos

Aug 20, 2023

O planeta está inundado de APIs, os mecanismos usados ​​pelos computadores para trocar informações, os blocos de construção de todos os softwares. As empresas criam suas próprias APIs para uso interno ou para permitir que os clientes interajam com seus sistemas. Eles usam APIs para se comunicar com parceiros em extranets e entre nuvens. Eles usam APIs de terceiros para acessar funcionalidades prontas – para exibir o Google Maps ou usar tabelas de consulta de código postal em formulários, por exemplo.

O número de APIs está crescendo exponencialmente à medida que proliferam aplicativos móveis, web e em nuvem. Algumas estatísticas do setor:

Não é de surpreender que as APIs também sejam um vetor de ataque significativo e de rápido crescimento. De acordo com o Gartner: “O crescimento explosivo das APIs está expandindo a superfície de ataque das organizações, proporcionando aos atores mal-intencionados novas oportunidades de violação e exfiltração de dados”.

Dependendo do seu ponto de vista, é muito surpreendente ou pouco surpreendente que cerca de 50% das APIs em uso não sejam gerenciadas.

Surpreendente porque representam um risco óbvio e crescente. Não é surpreendente porque a explosão na utilização de APIs é agravada pela falta de consciência dos riscos – e porque as APIs são difíceis de gerir. Os desenvolvedores frequentemente publicam novas APIs ou novas versões sem se preocupar em excluir suas antecessoras. O ciberespaço está repleto de APIs zumbis, expondo sistemas e dados de back-end, mas não monitorados e sem valor comercial.

Uma superfície de ataque em constante expansão e mal patrulhada: este é o sonho de um hacker que se torna realidade.

O alerta do Gartner destaca um dos riscos óbvios da segurança das APIs: as APIs são pontos de passagem para muito tráfego sensível. Em aplicativos bancários ou de comércio eletrônico, eles podem incluir detalhes da conta dos clientes ou números de cartão de crédito. Mas as APIs expõem não apenas os dados de uma empresa (e de seus clientes), mas também a lógica de negócios por trás dos serviços. As deficiências na lógica de negócios apresentam aos hackers novas maneiras de lançar ataques que provavelmente passarão despercebidos antes que ocorram perdas graves.

Por exemplo, fizemos um trabalho para um banco que usava uma rotina para arredondar quantias muito pequenas em transações de câmbio. O algoritmo era irrelevante para negociações típicas, pois significava uma diferença de uma fração de centavo. Mas o sistema não aplicava limite ao número de transações que um único cliente poderia realizar num dia e, ao contornar os controles front-end e atacar diretamente sua lógica de negócios, era possível realizar um grande número de pequenas transações que permitiriam a um invasor usar a função de arredondamento para imprimir dinheiro em nossa própria conta. Obtivemos resultados semelhantes com clientes da indústria de criptografia, onde o abuso da lógica de negócios da API também nos permitiu roubar criptomoedas.

É claro que o banco tinha controlos que o teriam eventualmente alertado para a questão, mas reconheceu que poderia ter recebido vários milhões de dólares em transações anómalas antes de serem levantadas quaisquer bandeiras vermelhas. Este exemplo ilustra alguns princípios importantes de segurança de API. As APIs mais úteis são públicas. Eles foram feitos para serem usados. Você não pode ocultá-los ou dificultar o acesso sem impedi-los de fazer seu trabalho.

Técnicas como testes de penetração podem ajudar, mas mesmo os testes de penetração são apenas exercícios pontuais, e os testadores avaliam apenas o escopo fornecido. As empresas com pontos cegos de API não sabem como definir o escopo das APIs, e a maioria dos testadores de penetração não será solicitada a testar a lógica de negócios ou não terá conjuntos de habilidades específicas de API para avaliar o que um invasor de API competente poderia fazer com seu acesso .

A segunda lição é que não faz sentido focar apenas em uma parte do ciclo de vida da API. Os princípios da mudança para a esquerda concentram-se corretamente na construção da segurança no ponto de design e codificação, mas o ciclo de vida de produção do código é igualmente importante. As coisas mudam. O código original foi ajustado por outro desenvolvedor. A documentação é deficiente ou inexistente. O negócio está sob pressão. As atualizações podem não ser testadas exaustivamente. E mesmo que o desenvolvimento e os testes tenham sido impecáveis ​​e as revisões meticulosas, pode haver algo que faltou no design original que pode voltar para assombrá-lo. Mude para a esquerda, sim, mas pare de olhar diretamente para o seu perigo.