Blog

Miniguia: Segurança de APIs

Uma das tendências mais importantes em segurança cibernética é a segurança das APIs, e esse movimento – que começou em 2020, tem tomado força no Brasil, por conta do Open Banking. A abertura do ambiente bancário exige que as instituições utilizem, publiquem e documentem as suas APIs para conexão e compartilhamento de dados.

E, de fato, as APIs estão realmente em todos os lugares: em qualquer um de seus ambientes de nuvem e em seus datacenters. Elas são usadas ​​para se comunicar com as interfaces do cliente, como aplicativos da web e para celular, e para se comunicar com fornecedores e parceiros de negócios com comunicação de servidor para servidor.

Hoje, APIs são usadas para automação, administração, e podemos ir mais longe: qualquer pedaço de código que foi escrito nos últimos três anos está usando ou expondo uma API.

Essa explosão de APIs traz muitos desafios para a organização que conta com um nível de segurança médio hoje. Na maior parte das vezes, as APIs foram desenvolvidas rapidamente, e os erros são muito comuns. Esses erros podem ser falhas de design, configurações incorretas e vulnerabilidades, como autorização incorreta. Seria impossível encontrar uma organização que esteja bem ciente de todas as APIs em seu ambiente, especialmente aquelas que não são roteadas pelo gateway centralizado, muito menos os dados que passam por qualquer uma das APIs e quem tem permissão para acessar a API ou os dados por trás dela.

Mas afinal, o que é uma API?

API significa, em inglês, Application Programming Interface – ou seja é uma interface de programação para aplicaç   ões. Basicamente, as APIs são um conjunto de normas que permite a comunicação entre plataformas utilizando padrões e protocolos já estabelecidos para a transmissão de informações entre diferentes aplicações.

Por conta disso, o setor bancário estabeleceu a utilização de APIs para a comunicações entre diferentes instituições e aplicações, diminuindo o tempo de desenvolvimento e possibilitando que diferentes plataformas possam trocar dados.

As principais ameaças para APIs hoje

Embora a definição geral para API pareça simples, a segurança das APIs é algo bastante complexo, e existem poucas soluções específicas para APIs no mercado. Para se ter uma ideia da complexidade da segurança de APIs hoje em dia, listamos os principais riscos de segurança para APIs, de acordo com a OWASP:

Paginação insegura e limites de recursos

A maioria das APIs fornece acesso a recursos que são listas de entidades como /users ou /widgets. Navegadores web normalmente filtram e paginam essa lista para limitar o número de itens retornados ao cliente (o browser, no caso) da seguinte forma:

No entanto, se essa entidade tiver qualquer PII ou outra informação, um hacker pode acessar esse endpoint para obter um dump de todas as entidades em seu banco de dados. Isso pode ser mais perigoso se essas entidades expuserem acidentalmente PIIs ou outras informações sensíveis, ou permitir, por exemplo, que criminosos acessem grandes bases de dados.

Para se proteger contra ataques de paginação, você deve rastrear quantos itens de um único recurso são acessados ​​em um determinado período de tempo para cada usuário ou chave de API. Ao rastrear o acesso aos recursos da API no nível do usuário, você pode bloquear um usuário ou uma chave da API assim que atingir um limite.

Geração de chave de API insegura

A maioria das APIs são protegidas por algum tipo de chave de API ou JWT (JSON Web Token). Isso fornece uma maneira natural de rastrear e proteger a API, pois as ferramentas de segurança da API podem detectar comportamento anormal da API e bloquear o acesso a uma chave automaticamente. No entanto, os hackers vão querer burlar esses mecanismos, gerando e usando um grande pool de chaves API de um grande número de usuários, assim como um hacker da web usaria um grande pool de endereços IP para burlar a proteção DDoS.

A maneira mais fácil de se proteger contra esses tipos de ataques é exigir que uma pessoa se inscreva no seu serviço e gere chaves de API. O tráfego de bots pode ser evitado com o uso de captcha ou identificação de dois fatores. A menos que haja um caso de negócios legítimo, os novos usuários que se inscrevem em seu serviço não devem ter a capacidade de gerar chaves de API de maneira programática. Em vez disso, apenas clientes confiáveis ​​devem ter a capacidade de gerar chaves de API de maneira programática.

Exposição acidental da chave da API

Um comportamento “normal” para a APIs é o seu acesso por tempo indefinido, o que aumenta a probabilidade de um hacker obter uma chave de API válida que não tenha expirado. Você salva essa chave de API em uma variável de ambiente do servidor e esquece dela.

O cliente que consome uma API tem acesso direto às credenciais, como ao depurar via Postman ou CURL. Basta um único desenvolvedor para copiar / colar acidentalmente o comando CURL que contém a chave da API em um fórum público, como em GitHub Issues ou Stack Overflow.

As chaves de API são geralmente tokens que não exigem nenhuma outra informação ou identificação – além de os tokens não poderem ser utilizados uma única vez, e tampouco serem habilitados para exigir identificação de dois fatores.

A maneira mais fácil de evitar a exposição da chave é criar dois tokens em vez de um. Um token de atualização é armazenado como uma variável de ambiente e só pode ser usado para gerar tokens de acesso de curta duração. Ao contrário do token de atualização, esses tokens de curta duração podem acessar os recursos, mas são limitados por tempo, como em horas ou dias.

O cliente armazenará o token de atualização com outras chaves de API. Em seguida, seu SDK irá gerar tokens de acesso na inicialização do SDK ou quando o último token de acesso expirar. Se um comando CURL for colado em um problema do GitHub, um hacker precisará usá-lo em algumas horas, reduzindo o vetor de ataque.

Exposição a ataques DDoS

As APIs abrem modelos de negócios totalmente novos onde os clientes podem acessar sua plataforma de API de forma automática. No entanto, isso pode tornar a proteção DDoS complicada. A maior parte da proteção DDoS é projetada para absorver e rejeitar um grande número de solicitações de agentes mal-intencionados durante ataques DDoS – porém, os acessos legítimos precisam ser autorizados.

Isso exige que as solicitações HTTP sejam identificadas com a utilização de cookies – para que o tráfego de bot seja devidamente tratado. Isso se torna muito mais complicado para APIs, pois todo o tráfego parece tráfego de bot e não vem de um navegador onde itens como cookies estão presentes.

Parando ataques DDoS

A parte mágica das APIs é que quase todo acesso requer uma chave de API. Se uma solicitação não tiver uma chave de API, você pode rejeitá-la automaticamente

Então, como você lida com solicitações autenticadas? O mais fácil é aproveitar os contadores de limite de taxa para cada chave de API, como lidar com X solicitações por minuto e rejeitar aquelas acima do limite com 429 HTTP response.

Segurança de servidor incorreta

APIs não são diferentes de servidores web quando se trata de organização para manutenção de segurança. Os dados podem ser vazados devido a um certificado SSL configurado incorretamente ou permissão de tráfego não HTTPS. Para aplicativos modernos, há poucos motivos para aceitar solicitações não HTTPS, mas um cliente pode emitir por engano uma solicitação não HTTP de seu aplicativo ou CURL, expondo a chave de API. As APIs não têm a proteção de um navegador, portanto, coisas como HSTS ou redirecionamento para HTTPS não oferecem proteção.

Para manter uma implementação SSL adequada, é preciso testar sua implementação SSL. Você também deve bloquear todas as solicitações não HTTP que podem ser feitas em seu balanceador de carga. Você também deve remover quaisquer cabeçalhos HTTP, limpar todas as mensagens de erro que vazem detalhes de implementação. Se sua API for usada apenas por seus próprios aplicativos ou só puder ser acessada no lado do servidor, revise o guia oficial para compartilhamento de recursos de origem cruzada para APIs REST.

Cache incorreto de headers

APIs fornecem acesso a dados dinâmicos com escopo para cada chave de API. Qualquer implementação de cache deve ter a capacidade de escopo para uma chave de API para evitar poluição cruzada. Mesmo se você não fizer cache de nada em sua infraestrutura, poderá expor seus clientes a brechas de segurança. Se um cliente com um servidor proxy estava usando várias chaves de API, como uma para desenvolvimento e outra para produção, eles poderiam ver os dados de polinização cruzada.

Para evitar esse erro, você deve garantir que o controle de cache para headers esteja devidamente configurado.

Registro e monitoramento insuficientes

Este é um dos 10 itens principais de segurança da API do OWASP. A maioria dos estudos demonstra que o tempo para detectar uma violação de dados é de mais de 200 dias. Se você não tiver o registro e monitoramento de API adequados, os invasores podem continuar usando a mesma vulnerabilidade ou até mesmo sondar por mais vulnerabilidades.

Você deve garantir que seu registro de API não apenas rastreie as próprias solicitações de API, mas também esteja vinculado aos usuários para análise de comportamento do usuário e armazenado por pelo menos um ano. Esses sistemas devem ser protegidos para garantir que os dados não possam ser excluídos acidentalmente ou retirados antes do tempo.

Falta de proteção a endpoints internos

O mesmo serviço de API pode ter terminais que são usados ​​externamente e externamente. Só porque um endpoint não está documentado, não significa que um hacker não possa fazer uma solicitação. Além de proteger com um esquema de autenticação e autorização, você deve garantir que esses terminais não fiquem expostos à Internet pública, o que pode ser feito em seu balanceador de carga ou gateway de API. Isso ajuda ao fornecer vários níveis de segurança, uma estratégia comum de prevenção.

Falta de gestão na autorização

Embora a maioria dos desenvolvedores de API adicione um esquema de autenticação global, como chaves de API ou OAuth, para verificar quem é a pessoa, é mais difícil implementar. A autorização também é necessária e separada da autenticação. A autorização envolve verificar se essa pessoa (que já está identificada) pode acessar um recurso específico. Isso pode ser feito por meio de escopos de API, verificando um ID de locatário ou ID de usuário, entre outras coisas.

Por ser específico para a lógica de seu aplicativo e nem sempre transversal, a autorização pode ser uma área da qual os desenvolvedores se esquecem. A menos que seus identificadores de objeto tenham entropia suficiente, um hacker pode facilmente testar diferentes ids por meio de iteração. Isso é especialmente verdadeiro para bancos de dados SQL que incrementam o id na inserção.

Certifique-se de que o usuário autenticado está autorizado a acessar todos os recursos necessários para gerar a resposta da API. Isso pode envolver a verificação de um ID de usuário ou listas de controle de acesso (ACL) vinculadas aos objetos em questão.

A transformação começa agora.