Por que suas chaves de API estão deixando você vulnerável a ataques

Durante anos, os especialistas em segurança de APIs sublinharam a importância de proteger as nossas APIs. A maioria das empresas implementou um gateway de API como medida defensiva contra ameaças cibernéticas. No entanto, muitas dessas APIs dependem exclusivamente de chaves de API básicas para proteção.

Apesar da implicação aparentemente segura de seu nome, as chaves de API não oferecem segurança robusta na prática. APIs que lidam com dados confidenciais exigem uma forma de proteção mais fortalecida, como tokens em vez de chaves de API.

O que é uma chave de API?

As chaves de API regulam o acesso e monitoram o uso de uma API. Geralmente, os desenvolvedores são obrigados a anexar sua chave de API exclusiva às solicitações para interagir com uma API. O servidor API então verifica essa chave para confirmar se o solicitante tem permissão para acessar os recursos ou executar determinadas operações.

Existem duas razões principais para o uso generalizado de chaves de API:

• Por padrão, todo gateway de API oferece a opção de liberar APIs e gerenciar o acesso usando uma chave de API, estabelecendo isso como norma.
• Sua facilidade de uso atrai os desenvolvedores. Incorporar a chave de API é tão simples quanto inseri-la no caminho ou cabeçalho da solicitação.

Isso parece bom para mim. Qual é o problema aqui?

Imagine que sua API não lida com informações confidenciais e não é crítica para as operações da sua organização. Nesses cenários, usar uma chave de API como medida de segurança pode ser perfeitamente adequado. Exemplos em que uma chave de API pode ser suficiente incluem APIs que fornecem previsões meteorológicas, localizações de lojas ou outros dados acessíveis ao público.

Por outro lado, se sua API expõe informações de identificação pessoal (PII) ou quaisquer dados cujo comprometimento possa prejudicar você ou sua organização, você estará vulnerável a acesso não autorizado, violações de dados e potencial abuso de recursos.

É amplamente reconhecido na engenharia de software que nomear coisas pode ser incrivelmente desafiador. Grande parte do mal-entendido pode surgir do que inferimos do termo “chave”. No domínio físico, uma chave protege as nossas casas, veículos ou cofres, sugerindo uma segurança robusta. Portanto, é compreensível presumir que uma chave de API protege sua API. No entanto, embora ofereça algum nível de proteção, geralmente não é considerado robusto pelos padrões modernos.

O Google disse que as chaves de API são para projetos; a autenticação é para usuários, enquanto a autenticação se destina à verificação de usuários. Em essência, uma chave de API identifica quais serviços um aplicativo cliente pode acessar. O gateway da API usa esse identificador para impor limites de taxa, monitorar a utilização da API e, ocasionalmente, lidar com o faturamento.

Os desenvolvedores geralmente incorporam chaves de API diretamente nos aplicativos. Isso significa que cada usuário opera sob a mesma chave de API, sem autenticação individual ou verificações de autorização. Caso essas chaves sejam expostas ou roubadas, atividades maliciosas poderão ocorrer sem o conhecimento do proprietário da API.

As chaves de API normalmente são emitidas uma vez e permanecem válidas indefinidamente, o que é preocupante porque as chaves comprometidas podem passar despercebidas por um longo período. Devido à simplicidade com que as chaves de API podem ser integradas, os desenvolvedores podem tornar-se complacentes, enviando-as inadvertidamente para repositórios públicos. A existência de ferramentas como o git-hound é uma prova da prevalência de tais deslizes.

Proteger ou não proteger, essa é a questão

Na busca pela simplicidade, muitas vezes descobrimos que medidas mínimas, como senhas, ficam aquém da segurança. Assim, surge o advento da autenticação de dois fatores, que, apesar de acrescentar etapas extras ao processo de login, é amplamente aceita como uma melhoria necessária para a proteção de contas. Da mesma forma, a segurança fornecida apenas pelas chaves de API é insuficiente; eles exigem a presença reforçada de tokens.

Os tokens de API têm uma dupla finalidade, abordando questões essenciais de segurança: verificam a identidade (autenticação) e determinam os níveis de acesso (autorização).

A HubSpot, reconhecendo as limitações das chaves de API, determinou recentemente que os desenvolvedores em sua plataforma façam a transição para o uso de tokens de acesso. Essa mudança está detalhada no site do desenvolvedor.

Tais mudanças estão a tornar-se comuns, especialmente entre empresas em crescimento que inicialmente optam pelo método mais rápido para conceder acesso à API antes de reconhecerem a necessidade de medidas de segurança mais fortes e escaláveis.

O que é um token?

Um token de API é um identificador exclusivo usado para autenticar um usuário ou aplicativo na API, servindo como uma chave para acessar serviços sem transmitir credenciais confidenciais. Ele garante a segurança encapsulando as permissões do usuário, geralmente tem uma expiração e pode ter como escopo níveis de acesso específicos. Normalmente, um desenvolvedor recebe um ClientID e um segredo que pode ser usado para gerar um token seguro.

Essa abordagem baseada em token permite interações sem estado com a API. Como o servidor não precisa manter um estado de sessão, ele pode atender muito mais clientes sem se preocupar com a sobrecarga de memória das sessões armazenadas, com a vantagem adicional de se recuperar com mais facilidade de falhas parciais.

Os tokens podem usar escopo para que você possa controlar o acesso que cada integração tem ao seu sistema. Os escopos de token de API são usados ​​para limitar os direitos de acesso de um token de API, especificando quais recursos ou ações o token tem permissão para acessar ou executar. Por exemplo, um serviço de armazenamento em nuvem pode ter os seguintes escopos:

• Ler: Permite baixar e listar arquivos.
• Escrever: Permite fazer upload e modificar metadados de arquivos.
• Excluir: Permite exclusão de arquivos.
• Compartilhar: Permite compartilhar arquivos com outros usuários.

O benefício para o usuário final do aplicativo é que ele pode revogar um escopo a qualquer momento, o que significa que pode retirar o acesso, por exemplo, à sua data de nascimento ou sexo.

A principal vantagem de usar tokens em vez de chaves de API é que eles são projetados para serem regenerados regularmente, essencialmente tornando mais difícil atingir um alvo em movimento. Isso significa que o consumidor da API precisa escrever seu código para lidar com isso desde o início.

Por que todo mundo não usa apenas tokens, então?

Resposta curta: dá mais trabalho.

https://curity.io/resources/learn/code-flow/

A beleza de uma chave de API é que você pode simplesmente adicioná-la como um parâmetro de consulta no URL ou no cabeçalho e pronto:

GET https://api.example.com/data?apikey=YourAPIKey

Escrever um serviço de manipulação de tokens requer um pouco mais de esforço:

1. Preparar solicitação de token: configure um POST solicite com seu client_id, client_secret e especifique o grant_type as client_credentials.
2. Enviar solicitação de token: use uma ferramenta como curl para enviar a solicitação ao endpoint de token do serviço.
3. Receber token ao portador: extraia o access_token da resposta JSON.
4. Usar token de portador: inclua o token de portador no cabeçalho de autorização para solicitações de API.
5. Gerenciar a expiração do token: solicite um novo token após o atual expirar.

Exigir tokens para acesso à API pode dissuadir os desenvolvedores, tentando-os a optar pela abordagem mais direta de um rival. No entanto, sacrificar a segurança robusta pela facilidade de uso pode resultar em um ataque à API. Considere qual cenário é menos desejável: manchetes destacando uma violação de segurança na API de um concorrente ou na API da sua equipe?

Além disso, vários kits de desenvolvimento de software (SDKs) podem simplificar esse processo para os desenvolvedores. Essas ferramentas encapsulam as complexidades, permitindo que os desenvolvedores integrem e usem sua API sem a necessidade de um conhecimento profundo dos processos de autenticação subjacentes.

Como a Apiable resolveu esse problema com precisão

Curity oferece um serviço de token seguro e serviço de autenticação (para login do usuário) pronto para simplificar consideravelmente o trabalho dos desenvolvedores de API. A startup finlandesa de portais de API como serviço, Apiable, usa isso para emitir tokens seguros para clientes em três estágios:

• Estágio 1: Defina os níveis ou tipos de autorização suportados no nível do programa API.

Surgiram casos em que cada versão de API para um portal necessita de uma avaliação de segurança prévia. Esse procedimento pode ser árduo e desacelerar o ritmo de lançamento de novas APIs dentro de uma empresa.

Nossa recomendação é alocar tempo para colaborar com sua equipe de segurança para criar um conjunto de protocolos de autorização de API endossados ​​específicos para sua organização. Depois que esses padrões estiverem em vigor, eles poderão ser aplicados de forma consistente em vários produtos de API, eliminando a necessidade de discussões repetitivas.

• Etapa 2: Abstraia a complexidade do gerente de produto da API.

Os gerentes de produto, que frequentemente têm experiência em negócios, podem encontrar dúvidas de desenvolvedores como: “Qual fluxo OAuth 2.0 é apropriado para esta API?” Estes gestores podem não ter o conhecimento técnico para responder a tais questões específicas.

No entanto, com uma estrutura de segurança predefinida, os gestores de produtos API podem determinar com confiança o nível de segurança adequado para as suas ofertas, garantido pelo endosso da sua organização.

Essa abordagem se alinha ao modelo de maturidade de segurança de API da Curity e simplifica o processo de tomada de decisão em relação aos fluxos OAuth 2.0. Ele melhora a compreensão geral dos níveis de segurança de diferentes fluxos usando uma escala de classificação fácil de entender de 0 a 3, representada visualmente por um semáforo codificado por cores de vermelho a verde.

• Etapa 3: Ajude o consumidor da API a entender qual fluxo OAuth ele deve implementar.

Os desenvolvedores podem achar complexo discernir o fluxo OAuth 2.0 apropriado para seu cenário específico, principalmente ao lidar com vários produtos de API, cada um com seu próprio conjunto de fluxos de autorização suportados. Essa complexidade geralmente resulta em um amplo guia de “Introdução” que abrange todos os possíveis métodos de autorização.

Para agilizar esse processo, quando um desenvolvedor assina um produto de API, o portal de API personaliza sua exibição para apresentar apenas o tipo de autorização relevante para o plano e caso de uso selecionado, completo com exemplos práticos. Essa abordagem personalizada permite que os desenvolvedores comecem a trabalhar mais rapidamente e se beneficiem de uma experiência aprimorada de desenvolvedor.

Observação: Essas credenciais foram regeneradas após a captura desta captura de tela.

Conclusão

A chave de API aparentemente simples é enganosamente inadequada para proteger APIs que acessam dados confidenciais. Pode oferecer uma aparência de segurança, mas a natureza estática das chaves de API e sua ampla distribuição as tornam um risco.

Por outro lado, os tokens fornecem uma medida de segurança dinâmica e robusta. Eles garantem que cada solicitação não seja apenas autenticada, mas também autorizada, abordando as duas questões fundamentais de segurança que as chaves de API por si só não conseguem.

A transição de chaves de API para tokens pode inicialmente parecer assustadora devido ao esforço necessário para implementar o tratamento adequado de tokens. No entanto, a compensação é um ecossistema de API muito mais seguro, onde os dados confidenciais estão mais bem protegidos contra acessos não autorizados e violações.

No mundo digital, assim como no mundo físico, o bloqueio mais forte é aquele que se adapta e muda, mantendo afastados usuários não autorizados. O uso do serviço de token seguro da Curity pela Apiable demonstra como as organizações podem proteger suas APIs sem sobrecarregar os desenvolvedores.

Ao definir níveis de autorização suportados e simplificar protocolos de segurança, os gerentes de produtos de API podem navegar no equilíbrio entre segurança e acessibilidade, garantindo que suas APIs sejam fáceis de usar e seguras.

A evolução das chaves API para a autenticação baseada em tokens não é apenas uma tendência, mas um passo necessário em direção a uma infraestrutura digital mais segura. Esta abordagem representa um investimento na longevidade e integridade dos ativos digitais de uma organização, solidificando a confiança na tecnologia que sustenta o nosso mundo moderno.

A postagem Por que suas chaves de API estão deixando você vulnerável a ataques apareceu pela primeira vez em The New Stack.