API #03: Segurança

Blindando suas APIs: Um Guia Essencial para a Segurança em APIs RESTful

set 03, 2024

No mundo digital de hoje, onde a troca de dados entre aplicativos é a norma, proteger suas APIs RESTful é mais crucial do que nunca.

Imagine suas APIs como as portas de entrada para o seu aplicativo, você não deixaria essas portas abertas para qualquer um, certo?

A segurança em APIs não é um luxo, é uma necessidade. Falhas na proteção de suas APIs podem ter consequências devastadoras, tanto para sua empresa quanto para seus usuários. Este guia fornece uma visão geral das melhores práticas de segurança para APIs RESTful, ajudando você a proteger seus dados e recursos valiosos contra-ataques maliciosos.

Veja alguns exemplos reais que ilustram o impacto dessas falhas:

Equifax (2017): Uma vulnerabilidade em uma API da Equifax, uma das maiores agências de crédito dos EUA, permitiu que hackers roubassem dados pessoais de mais de 145 milhões de pessoas, incluindo números de seguro social, datas de nascimento e endereços. O impacto financeiro para a Equifax foi estimado em bilhões de dólares, incluindo custos de reparação, multas e perda de valor de mercado. Você pode ler mais sobre esse incidente aqui.

Facebook (2018): Uma falha na API do Facebook permitiu que um aplicativo de terceiros coletasse dados de milhões de usuários sem seu consentimento. Esses dados foram posteriormente usados para fins políticos, gerando um escândalo global e abalando a confiança dos usuários na plataforma. Saiba mais sobre o caso Cambridge Analytica aqui.

Parler (2021): Uma configuração incorreta na API da rede social Parler permitiu que pesquisadores de segurança baixassem e arquivassem milhões de posts, incluindo vídeos e imagens, expondo informações privadas de usuários e atividades potencialmente ilegais. Veja mais detalhes sobre essa falha de segurança aqui.

As consequências de falhas de segurança em APIs podem ser devastadoras, incluindo:

Roubo de dados: Informações pessoais, financeiras e confidenciais podem ser acessadas e exploradas por criminosos.
Perda financeira: Custos de reparação, multas regulatórias e perda de receita podem impactar significativamente o resultado da empresa.
Danos à reputação: A confiança dos usuários e do mercado pode ser abalada, levando à perda de clientes e oportunidades de negócio.
Interrupção do serviço: Ataques de negação de serviço (DoS) podem tornar sua API indisponível, prejudicando a experiência do usuário e a operação do seu negócio.
Responsabilidade legal: Em alguns casos, empresas podem ser responsabilizadas legalmente por falhas na proteção de dados de usuários.

Ao longo deste conteúdo, você verá sobre diferentes métodos de autenticação e autorização, padrões de segurança e estratégias de gerenciamento de vulnerabilidades, com uma abordagem prática .

Vejamos abaixo alguns métodos e boas práticas de segurança para serem utilizados em suas APIs.

Autenticação vs. Autorização:

Antes de mergulharmos nos métodos de segurança, vamos esclarecer dois conceitos fundamentais: autenticação e autorização.

A autenticação é como o porteiro na entrada da sua festa, verificando se você está na lista de convidados. Já a autorização, por outro lado, é como o segurança dentro da festa, decidindo se você tem permissão para acessar a área VIP.

Em termos de API, a autenticação verifica a identidade de quem está fazendo a requisição, enquanto a autorização determina o que eles podem fazer uma vez dentro.

Alguns métodos mais comuns …

Basic Authentication

A opção mais simples, mas também a mais vulnerável. É como enviar seu nome e senha em um cartão postal — qualquer um pode ler! Use apenas com HTTPS para criptografar a comunicação.

Este é um sistema de autenticação bem simples especificado no protocolo HTTP.

O cliente envia uma requisição com o header (Authorization) que contém a palavra Basic e o nome de usuário e senha, separados por dois pontos no formato de base64.

Por exemplo, para autorizar o usuário joão com senha joão@123, o client enviaria na requisição, o seguinte header:

Authorization: Basic am/Do286am9hb0AxMjM=

O formato base64 é muito fácil de ser decodificado, portanto, o formato basic authentication só é recomendado quando são utilizados outros complementos de segurança, como, por exemplo, o certificado HTTPS.

API Keys

Imagine que cada usuário recebe um crachá único para acessar sua API. Fácil de implementar, mas lembre-se: um crachá perdido pode cair em mãos erradas.

API Keys é um método de autenticação que na teoria veio para resolver alguns problemas do modelo de Basic Authentication.

A ideia central do formato de API Keys é simples, o servidor gera uma chave de acesso única para o client, e para utilizar a API, o client envia essa chave única em toda requisição.

É um método bem simples e rápido de ser implementado, e durante anos foi o método mais utilizado pelos desenvolvedores.

A questão crucial é que esse método tem como objetivo apenas a autenticação, e não a autorização, ou seja, em teoria, um usuário com uma Key válida tem acesso a todas as operações de uma API.

Além disso, ela funciona como qualquer requisição HTTP, e se algum ponto de rede estiver inseguro, ela pode ser facilmente interceptada e utilizada para acesso indevido da API.

Geralmente essa key é usada no header vejamos um exemplo abaixo:

Imagine que você recebeu do servidor a seguinte:

key: “a2V5LWFwaQ==”

Para eu me autenticar eu faria uma requisição com o seguinte header:

Api-key: a2V5LWFwaQ==

OAuth

O protocolo mais recomendado atualmente. É como dar a chave da sua casa a um amigo de confiança, mas apenas para regar as plantas enquanto você está fora.

Ele permite que aplicativos acessem seus dados de forma controlada e segura.

O OAuth está na sua versão 2.0, e não é apenas um método de autenticação, e sim um protocolo completo com diversas especificações de segurança.

Ele é extremamente útil para o processo de autenticação e autorização, e por isso, atualmente é o método mais recomendado para o cenário de APIs.

Vamos entender alguns conceitos básicos do OAuth 2:

• Resource Owner: entidade dona do recurso, ou seja, que é capaz de controlar o acesso a um recurso. Normalmente é o próprio usuário.

• Resource Server: servidor que possui os recursos, e por sua vez, recebe as requisições.

• Authorization Server: servidor que gera tokens de acesso para permitir que o client acesse os recursos autorizados pelo resource owner.

• Client: aplicação que acessa os recursos do resource server.

Para entender melhor, vamos supor que você desenvolveu uma aplicação que utiliza dados do usuário do Instagram, então vamos simular como seria um fluxo básico de autenticação via OAuth 2.0:

1. O usuário acessa a sua aplicação que teria um botão de “integre ao Instagram”, sendo que a sua aplicação seria o client.

2. Ao clicar no botão, o usuário é redirecionado para a tela de login do Instagram (authorization server).

3. Após o usuário informar as credenciais, o Instagram fornece um código de acesso ao client.

4. Então o client solicita autorização aos recursos (endpoints da API do Instagram) para o resource owner (sendo o próprio usuário) enviando o código de acesso recebido anteriormente.

5. O authorization server por sua vez, verifica se o código de acesso é valido, e caso positivo, ele gera um token de acesso para retornar ao client.

6. Por último, agora que o client já tem o token de acesso e autorização aos recursos, então a cada requisição, o resource server (API do Instagram) irá responder com os dados protegidos.

Observações Importantes:

Segurança: O token de acesso deve ser armazenado e gerenciado de forma segura pela sua aplicação para evitar acessos não autorizados.
Escopos de Permissões: Durante a solicitação de autorização, você pode especificar os escopos de acesso que sua aplicação necessita, garantindo que o usuário tenha controle sobre quais dados serão compartilhados.
Renovação de Token: Dependendo do tipo de token concedido, pode ser necessário implementar um mecanismo para renová-lo periodicamente, mantendo o acesso contínuo aos recursos da API.

Assuntos que giram em torno da especificação do oAuth..

OpenID Connect: Extensão da funcionalidade de autenticação do OAuth. Como o OAuth foi projetado para autorização, o OpenID Connect acaba sendo um ótimo complemento na segurança de APIs, conseguindo auxiliar no sentido de provar que o usuário é realmente quem ele diz que é.

JWT: Formato de token seguro que utiliza JSON como base.

SAML

Útil para sistemas corporativos onde o Single Sign-On (SSO) é importante, mas menos comum devido à sua complexidade.

O SAML, ou Security Assertion Markup Language. É um padrão aberto que permite que provedores de identidade (IDP) passem credenciais de autorização para provedores de serviços (SP). Em outras palavras, o usuário pode usar as mesmas credenciais para entrar em aplicações diferentes.

Na prática, o SAML ativa o Single Sign-On (SSO), algo bem interessante para a experiência dos usuários, ao fazerem o login uma única vez, conseguem navegar em todos as aplicações com o padrão implementado.

Não vejo outro cenário de aplicação do SAML além de casos que o login único seja premissa, pois utiliza o XML na comunicação, que já é algo ultrapassado para o desenvolvimento WEB que estamos vivendo atualmente.

Boas Práticas: Além do Básico…

Em uma visão direta ao ponto, essas são as principais recomendações de segurança para a grande maioria dos cenários de APIs:

HTTPS Sempre:

Criptografe seus dados, tornando-os ilegíveis para intrusos.

Essa é uma dica básica de segurança na WEB para você manter as mensagens trafegadas seguras e criptografadas, dificultando qualquer interceptação da requisição.

É natural haver uma queda de desempenho, porém, se você estiver utilizando HTTP 2 existem diversos workarounds de otimização.

Dados Sensíveis? Nunca na URL:

Evite incluir informações confidenciais na URL, como senhas ou chaves de API.

GET  https://api.dev.delivery/posts/?apiKey=senha_1234

Abrace o OAuth:

Use-o sempre que possível para uma segurança robusta.

O OAuth hoje é sem dúvidas a especificação mais completa para APIs RESTful, por isso, utilize tudo que há de melhor no OAuth, apenas tomem muito cuidado para não deixar a implementação muito complexa e impactar negativamente a experiência do desenvolvedor que irá consumir sua API.

Antes de iniciar a sua implementação propía experimente usar uma aplicação de de mercado com por o exemplo o Keycloak.

Rate Limit:

Limite o número de requisições por usuário para evitar ataques de negação de serviço (DoS).

Essa é uma prática interessante, que pode ajudar a prevenir ataques que focam em deixar sua infraestrutura indisponível por uma quantidade alta de requisições. Com a implementação desse header você consegue restringir o número de requisições do client.

Com a implementação, você sempre retorna os seguintes headers na resposta de uma requisição:

X-Rate-Limit-Limit — Número de requisições permitidas durante um período específico (dia, hora, etc)

X-Rate-Limit-Remaining —Número de requisições restantes do período corrente

X-Rate-Limit-Reset — Segundos restantes do período corrente

Timestamp:

Adicione um carimbo de data/hora às requisições para evitar ataques de repetição.

Se for uma API em que segurança é um ponto crítico, uma boa dica é criar um header customizado com o timestamp. Assim, o servidor pode comparar o timestamp atual, e aceitar apenas as requisições que estiverem próximas a um período (por exemplo: 2 minutos). Isso é um procedimento simples,, que pode prevenir ataques básicos de replay em tentativas de força bruta.

Valide Tudo:

Verifique todos os dados recebidos antes de processá-los.

Por questões de segurança, sempre valide os parâmetros da requisição antes da execução da lógica do negócio.

Caso a requisição esteja com parâmetros não especificados na sua documentação, rejeite imediatamente a requisição por poder ser indício de um ataque malicioso.

Além disso, para não impactar negativamente a experiência de quem não está mal-intencionado, retorne mensagens de erros claras sobre o assunto, e disponibilize exemplos da requisição feita corretamente.

API Gateway:

Considere usar um gateway para centralizar a segurança e outras funcionalidades da sua API.

Existem diversas ferramentas que facilitam as implementações dessas recomendações centralizando toda a inteligência de segurança em uma camada específica de arquitetura. Nesse desenho conseguimos entender esse modelo:

Existem alguns projetos bem conhecidos no mercado com essa proposta com uma comunidade bem ativa, considere em avaliá-los antes de desenvolver a sua própria solução.

Conclusão

A segurança em APIs RESTful é um desafio constante, mas com as ferramentas e práticas certas, é possível proteger seus dados e garantir a integridade de suas aplicações

A escolha do método de autenticação e autorização para sua API dependerá de vários fatores, incluindo o tipo de API, o nível de segurança necessário e o fluxo de trabalho do usuário.

API Keys são fáceis de implementar e usar, mas não são tão seguras quanto outros métodos. Basic Authentication é mais segura que API Keys, mas ainda é vulnerável a ataques de interceptação. OAuth 2.0 é o método mais seguro e recomendado para a maioria das APIs.

Ao escolher um método de autenticação e autorização, é importante considerar os seguintes fatores:

O tipo de API;
O nível de segurança necessário;
O fluxo de trabalho do usuário;

É importante também implementar boas práticas de segurança, como usar HTTPS e evitar incluir informações confidenciais na URL.

Para que você fique totalmente informado, não deixe de conferir os próximos artigos desta série exclusiva para membros da nossa comunidade.