Se você postou algo no Instagram hoje, assistiu um vídeo no Youtube, escreveu um tuíte ou fez uma compra na internet, pagando com cartão de crédito, pode não saber, mas usou APIs.
Essa tecnologia se tornou a fundação para os ambientes computacionais modernos, estão em praticamente todas as aplicações e, portanto, são um alvo apreciado por cibercriminosos. APIs, sigla para Application Programming Interface (ou Interface de Programação de Aplicação, em uma tradução livre) são como pontes software-para-software que permitem a troca de informações entre sistemas diferentes.
As APIs permitem que o processamento de solicitações em uma aplicação seja feita no servidor ou na nuvem, não no dispositivo em que o usuário está. Além disso, permitem que dados que não fazem parte da aplicação em uso sejam buscados em outro servidor, sem que um banco de dados precise ser mantido pelos desenvolvedores.
Um exemplo prático de uso de APIs
Você já deve ter feito uma compra online – depois de escolher seus produtos, você precisará definir o endereço de entrega e, para isso, digitar o código postal do seu endereço em um campo. Quando o CEP é incluído neste campo, o site em que você está faz uma chamada via API para o banco de dados dos Correios, que mantém o registro atualizado das ruas e números em todo o país.
Caso não existisse essa API, os desenvolvedores da loja em que você está teriam que criar uma réplica desse banco de dados e garantir que ela estivesse atualizada continuamente. Um trabalho desnecessário, certo? Mais do que isso, as APIs permitem que aplicações escritas em diferentes linguagens de programação conversem entre si, com dados padronizados e conexões seguras.
Por que cibercriminosos invadem aplicações através de APIs?
Se as APIs foram criadas para a troca de informações entre aplicações, é de se esperar que elas formem uma grande superfície de ataque. Os números não mentem: cerca de 80% do tráfego da internet atualmente é formado pela troca de dados entre APIs, e sua adoção em aplicações vem crescendo 160% ano após ano em todo o mundo. Mais do que isso, os ataques a APIs aumentaram 681% nos últimos 12 meses.
Esses componentes são alvo de ataques cibernéticos com o objetivo de sequestrar os dados que trafegam através da conexão entre duas aplicações, que podem ser dados financeiros e pessoais, por exemplo. Um tipo de ataque comum em APIs é aquele que injeta informações indevidas nos bancos de dados através da conexão de uma API. Em um app financeiro, por exemplo, pode-se redirecionar operações financeiras ou alterar saldos em contas em operações que já foram iniciadas entre a interface do usuário e o banco de dados.
Top 8 ataques a APIs e como se proteger
Até aqui vimos que o risco digital para APIs é alto, mas possível de ser reduzido. As técnicas utilizadas pelos cibercriminosos já podem ser identificadas, e ações de correção e mitigação incluem medidas relativamente simples, aplicadas à configuração da API e ao desenvolvimento da aplicação em si. A seguir, confira oito das principais técnicas de ataques a APIs e o que pode ser feito para reduzir o risco de invasão.
1. Exposição da API na web
A primeira vulnerabilidade é também a mais simples, uma API nunca deve estar exposta na internet (internet facing) porque isso permite ao atacante identificar seu tipo e tentar a exploração de falhas. A localização das APIs podem ser descobertas porque, normalmente, são armazenadas em diretórios com nomes similares por desenvolvedores. Também é possível usar técnicas de pesquisa como o Google Dorking e descobrir o endereço das APIs.
Uma tática também muito utilizada é forjar solicitações ao servidor através de website, ou seja, usar o website da companhia para enganar os firewalls e pivotar para sistemas internos e APIs.
Para corrigir: adote melhores práticas de implementação e deploy de aplicações que impeçam o acesso às APIs, use o princípio do privilégio de acesso mínimo (com um IAM, por exemplo) e implemente segmentação de rede.
2. Cache mal configurado
Para APIs que requerem autenticação, os dados transportados por elas são dinâmicos e definidos pela chave utilizada na conexão entre a aplicação e o servidor. Assim, um acesso com a chave do usuário A, somente os dados daquele usuário serão trazidos, ao passo que acessando o mesmo servidor, usando a mesma API mas com a chave do usuário B, serão retornados os dados deste usuário.
Um erro comum no uso de APIs é não utilizar as configurações padrão para este processo de autenticação. Alguns servidores podem não reconhecer configurações personalizadas e fazer a cache (armazenamento) de credenciais, o que permite a um atacante acessar dados de outros usuários.
Para corrigir: configure corretamente um controle de cache para os servidores e APIs, além disso opte por usar cabeçalhos padrão para a autenticação, entendido pela maioria dos servidores ao qual a aplicação conectará.
3. Exposição de tokens
Esse é um erro até rudimentar, mas não podemos deixar de citá-lo aqui. Se um atacante descobrir os tokens (chaves) de autenticação de uma API, isso dará acesso ao conteúdo transportado por ela.
Além disso, algumas APIs criadas para uso interno das empresas, via de regra, usam tokens estáticos de autenticação, que podem ser descobertos em repositórios de código, no frontend da aplicação ou interceptando tráfego entre aplicação e o servidor.
Para corrigir: faça uma varredura nos códigos durante o desenvolvimento para encontrar qualquer token “escondido” nas linhas de programação antes de realizar o deploy da aplicação. Alguns repositórios de código, como o GitHub, também contam com ferramentas que detectam essas falhas quando projetos são subidos na plataforma.
4. Fragilidade de JSON Web Token
Se o token de autenticação utilizado na sua API é formado por grupos de expressões base64 separadas por pontos, ele é provavelmente um JSON Web Token (JWT). A vulnerabilidade dos tokens web JSON não está neles em si, mas nas diversas maneiras em que uma má implementação pode adicionar questões de segurança.
As expressões que formam um JWT são formadas pelo cabeçalho, conteúdo de dados e uma assinatura. Elas armazenam informações sobre o algoritmo de autenticação usado pelo token, seu tipo, credenciais do usuário que está tentando autenticar e tempo de expiração da conexão.
Os tokens são muito utilizados por desenvolvedores porque permitem que não haja necessidade de implementação de gestão de sessões nos servidores. Isso quer dizer que, se a operação for autenticada com um JWT, o servidor não terá que checar a identidade do usuário a cada requisição.
Como mencionamos, o uso em si de JWTs não é inseguro, mas algumas más práticas de implementação, sim:
- Algumas versões de JWT permitem que se defina o algoritmo de autenticação como “nulo” e isso permite que quaisquer dados sejam substituídos, sem necessidade de validação de identidade.
- É possível tentar quebrar a chave de criptografia dos tokens JWT, a possibilidade vai depender da força da chave utilizada, mas há ferramentas específicas para isso e muitos artigos na web que explicam o processo.
- Em alguns casos raros, é possível enganar servidores e fazer com que eles confiem dos dados carregados pelos tokens, é um ataque mais difícil mas há artigos exemplificando o ataque.
- Trocar as chaves de autenticação por modelos menos seguros é possível em algumas versões antigas de bibliotecas JWT, nesse comprometimento troca-se uma chave aleatória por uma pública, o que facilita o comprometimento da conexão com a API.
- Alguns desenvolvedores não configuram o tempo de expiração dos tokens JWT, o que permite que ele permaneça válido indefinidamente.
Para corrigir: a melhor maneira de mitigar as fragilidades dos tokens JWT é utilizar uma biblioteca reconhecida e amplamente implementada, com reputação comprovada em todos os projetos.
5. IDOR
O processo de autenticação usando tokens tenta garantir que o usuário logado tenha acesso somente às informações que se referem a ele em uma aplicação, uma vulnerabilidade conhecida como insecure direct object reference (IDOR, ou referência insegura a objeto direto) permite o acesso de dados de outros usuários mudando a referência de uma requisição para a API.
Imagine um sistema de notas fiscais – na requisição para obter o documento temos algo como “/api/v1/invoices/?id=1234”, onde id se refere ao usuário logado e suas notas fiscais. Se for possível acessar notas fiscais de outros usuários alterando o valor “id”, temos um IDOR.
Para corrigir: esse tipo de vulnerabilidade é muito difícil de ser detectado em varreduras automáticas de código. Para evitá-la é importante implementar autenticação.
6. Falta de documentação de endpoints
É muito comum encontrar APIs implementadas que não contam com documentação extensa sobre funcionalidades e arquitetura e, para um atacante, isso é uma mina de ouro. Por exemplo, um endpoint definido na API como um ativo com funções administrativas e não documentado pode levar a erros de configuração, o que permitiria ao atacante executar ações de nível admin sem estar autenticado como um usuário com este nível de acesso.
Em outro exemplo, um endpoint pode ser explorado por não ter sido testado exaustivamente em relação à segurança cibernética. Não é raro encontrar mensagens de erro em servidores que oferecem pistas valiosas sobre como esse ativo pode ser explorado.
Para corrigir: ter um processo estruturado de documentação da API e suas funcionalidades é a melhor solução. Saber quais operações são executadas, onde, com quais níveis de acesso, usando que tipo de dado, com qual tipo de conexão, tudo deve estar registrado. Adicionalmente, é melhor planejar com documentação antes de iniciar o desenvolvimento.
7. Controle de versões
Quando uma empresa implementa APIs, que conversam com múltiplas aplicações, pode se ter um conjunto crescente de versões desses componentes para garantir que os sistemas integrados se comuniquem entre si. O versionamento de APIs se faz necessário para garantir que integrações já realizadas continuem funcionando, enquanto novas funcionalidades são implementadas para novos usuários.
O problema é que versões antigas podem ser impactadas por novas vulnerabilidades e questões de segurança que foram corrigidas nas atualizações.
Para corrigir: defina ciclos de vida de APIs – quando uma versão 2 for lançada avise os usuários que a versão anterior será descontinuada em um espaço de tempo definido. É importante garantir que as versões de pré-produção ou beta devem ser acessíveis publicamente somente se forem exaustivamente testadas em busca de falhas de segurança.
8. Rate limit para requests
Na maioria das vezes, as APIs não contam com uma proteção que define o número máximo de requisições para um determinado usuário. Essa falta de limite permite que um atacante faça milhares de solicitações, o que leva a comportamentos inesperados do servidor, que tentará atender a todas as requisições.
Esse servidor pode atingir seu limite máximo de processamento ou largura de banda de conexão e, simplesmente, cair. Um atacante que explorar essa falha pode também tentar um ataque de força bruta para descobrir credenciais do sistema, tentando automaticamente dezenas, centenas ou milhares de senhas diferentes, até conseguir quebrar a autenticação.
Para corrigir: a definição de um rate limit pode ser implantada por conta de usuário, por endereço IP, por endpoint ou para toda a API. Alguns proxies reversos também podem ser implementados transversalmente à aplicação, ajustando a carga da API sem desenvolvimento adicional.
O uso extenso de APIs permite a conexão entre sistemas e troca de dados que garantem funcionalidades praticamente ilimitadas para aplicações. No entanto, elas formam uma superfície de ataque muito rica para atacantes, que pode ser explorada e levar a vazamento de dados, troca de informações e prejuízos financeiros.
Proteger APIs depende de processos bem estruturados de desenvolvimento e documentação. Adotando essas melhores práticas simples, sua empresa pode estar mais protegida contra possíveis ataques.
