Segurança de APIs

Segurança de APIs

A ideia aqui é resumir o ótimo report do OWASP sobre as 10 vulnerabilidades mais exploradas dentro do universo das APIs.

O relatório é bem completo e sugiro a todos os interessados a dar uma lida, mas eu decidi fazer esse POST mais para ser como um guia rápido/handbook sobre o assunto. Não sou um perito em segurança (estou longe disso na verdade) mas como minha função é trabalhar na governança das API’s, segurança acaba sendo um item que preciso me preocupar.

1. Broken Object Level Authorization

Relembrando um pouco das boas práticas de implementação em APIs REST, uma API pode ter vários recursos, e para fins didáticos, podemos entender que um recurso é uma Entidade que vamos expor.

Fonte: carledwinti

Percebam que o recurso /clientes/{id} é acessível através do seu atributo de identificação. Esse tópico de segurança trata justamente desse tipo de recurso, se eu não tiver uma camada de segurança que valide que o usuário X pode editar/excluir esse recurso, comprometo a integridade dos dados.

Tratativas

  • Garantir que ao acessar um recurso por seu identificador, o usuário em questão tem permissão para executar a ação sugerida.
  • Dificultar o acesso ao identificador do recurso, ou seja, evitar usar números sequenciais. GUIDs é uma boa escolha.

2. Broken Authentication

De forma muito resumida, trata-se de boas práticas para garantir os métodos de autenticação. Hoje temos inúmeras opções, mas geralmente o time que implementa essa camada acha que fazer tudo na raça é a melhor opção. E dessa forma acaba esquecendo de fechar todas as brechas.

Então esse tópico é mais um alerta, pois uma autenticação implementada incorretamente acaba sendo pior que uma autenticação não implementada. Uma discussão profunda entre os times de desenvolvimento, arquitetura e segurança precisa ser feita para garantir que tudo está funcionado como deve estar. Um JWT que não é validado corretamente, senhas não encriptadas, informações sensíveis adicionadas em um token de forma desnecessária, podem comprometer a solução como um todo.

Tratativas

  • Não reinvente a roda, quando se trata de segurança utilize padrões de mercado.
  • Entenda todos os mecanismos de autenticação para poder escolher o que for mais adequado ao seu cenário.
  • Pense em estratégias de bloqueio em caso de tentativa de acesso não autorizado.

3. Excessive Data Exposure

Menos é mais, sempre!! Expor dados desnecessários na API é sempre uma má ideia, não só pelo lado da segurança, mas em termos de performance (dados a mais trafegando), complexidade de manipulação e etc.

Especificamente sobre segurança, um dado sensível exposto aqui pode ser utilizado para complementar a exploração de outras brechas de segurança.

Tratativas

  • Só exponha o essencial para sua API funcionar.
  • Limitar quais dados serão expostos, apenas no lado cliente não serve de nada. As informações ja devem sair “filtradas” do seu Backend.

4. Lack of Resources & Rate Limiting

Neste tipo de brecha, o que é explorado a limitação de recursos no lado do servidor. Chamadas excessivas partindo de uma mesma origem precisam ser bloqueadas, utilizando um recurso de Rating Limit por exemplo. Dessa forma evitamos que nosso serviço tenha qualquer tipo de indisponibilidade por excesso de chamadas.

Não tratar esse tipo de problema, principalmente em endpoints que estão abertos para o mundo (login, recuperar senha e etc) pode trazer muita dor de cabeça (DDoS).

Tratativas

  • A aplicação (Back-end) não deve se preocupar com esse tipo de problema, as soluções de segurança de mercado ja conseguem resolver esse problema.
  • As soluções de API Gateway, geralmente eferecem recursos para limitar chamadas aos recursos oriundos de uma mesma origem.

5. Broken Function Level Authorization

Esse item é semelhante ao tópico 1, mas aqui o foco é em níveis de acesso. Geralmente aplicações tem áreas/painéis administrativos e os controles de acesso que são implementados não levam em consideração toda complexidade do negócio.

Sem uma gestão efetiva de quem pode acessar o que, um invasor poderia manipular chamadas das áreas restritas/seguras, comprometendo o acesso ao recurso. E não adianta criar endpoints específicos para acesso a área restrita, sem uma validação de perfil-permissão nas funções/métodos envolvidos na requisição não é possível garantir a integridade dos recursos.

Tratativas

  • Implementar validações de perfil-permissão sempre que possível.
  • Bloquear todas as chamadas permitindo o acesso ao recurso apenas quando explicitamente concedido.

6. Mass Assignment

Com a evolução das linguagens de programação, temos framework para tudo. Muitas dessas bibliotecas utilizam o conceito de CoC (Convention Over Configuration). Por exemplo, muitos frameworks fazem o mapeamento dos atributos de um request diretamente para os atributos da entidade em questão. Um invasor sabendo dessa informação pode começar a explorar uma brecha no sentido de tentar manipular atributos que não estejam expostos.

Tratativas

  • Criar uma whitelist de atributos permitidos.
  • Implementar algum tipo de abstração entre o framework e o mapeamento dos objetos.
  • Contratos de APIs bem implementados e validados podem ajudar também.

7. Security Misconfiguration

Preocupe-se com a segurança em toda a stack da sua API. Desde a aplicação até a infraestrutura. De nada adianta possuir a melhor forma de autenticação mas o seu servidor não estar corretamente configurado, permitindo que um invasor explore arquivos/diretórios desprotegidos (chmod +666) por exemplo.

Ainda em nível de aplicação, é necessário refletir se todas as operações precisam estar disponíveis naquele recurso específico. Você realmente precisa daquele DELETE?

Tratativas

  • Revise constantemente o fluxo inteiro da sua API, para garantir que ela e suas dependências estejam seguras (arquivos de configuração, acessos externos e etc).
  • Garanta que sua empresa tem um time de segurança olhando para a infraestrutura, aplicando patches, controlando acessos para criar um ambiente seguro.

8. Injection

Essa vulnerabilidade é conhecida desde que a internet existe e mesmo assim é uma das mais exploradas. Trata-se do bom e velho injection, e veja que não estamos falando estritamente de SQL Injection e sim de vários outros tipos LDAP, NoSQL, Bash Script e etc.

As APIs trouxeram para a transformação digital o a agilidade que precisávamos para realizar negócios. Porém, toda essa agilidade, quando não planejada, abre algumas brechas de segurança. Hoje temos APIs que interagem diretamente com o S.O dos servidores, imagina o estrago que isso pode causar, pois alguém poderia injetar um script bash na requisição comprometendo o servidor por exemplo.

Tratativas

  • Sanitizar os parâmetros da requisição

9. Improper Assets Management

Em um plano de governança de api saudável, precisamos pensar sempre no ciclo de vida da mesma. Como todo software, as api’s evoluem e precisam ter suas versões antigas depreciadas. Ao abandonar uma versão antiga da API, sem proceder com sua depreciação, ela pode cair no esquecimento do time de desenvolvimento e ser uma porta de entrada para um invasor.

Esse gerenciamento de recursos não serve apenas para APIs consideradas produtivas, POCs e testes devem seguir um rigoroso processo de controle de ciclo de vida, pois uma vez descoberto o endpoint em questão, pode comprometer toda a infraestrutura.

Tratativas

  • Tenha um catálogo de suas APIs, e revisite-os com frequência.
  • Garanta que as APIs disponíveis realmente tenham um propósito.
  • Documente um ciclo de vida para suas APIs e garanta que ele é seguido a risca.

10. Insufficient Logging & Monitoring

Esse tópico acaba sendo muito mais uma boa prática do que uma vulnerabilidade de segurança real. É necessário ter o máximo de informações possíveis para saber como reagir a um ataque. Imagine que sua API começa a receber muitas chamadas e seu serviço simplesmente cai. Sem informações de log, que nesse caso podem conter a origem do ataque e qualquer outra informação relevante, seria muito complicado tomar uma ação efetiva como bloquear uma faixa de IPs por exemplo. Sem a devida monitoração, seria quase impossível determinar que uma API deixou de responder, ou ainda, seus recursos de infraestrutura (CPU e Memória) estão se esgotando.

Este tópico não se enquadra apenas em APIs, mas todo mundo que trabalha com desenvolvimento de software precisa garantir esses itens. Hoje temos muita opção para tornar esse monitoramento menos doloroso.

Topo