Leia sobre dicas e funcionalidades da GoCache CDN para melhorar a seguranca do seu site, loja virtual ou app mobile.

Configuração Incorreta de Segurança, ou Security Misconfiguration, representa uma série de erros como cabeçalhos HTTP mal configurados, cabeçalhos desnecessários, mensagens de erro verbosas, bancos de dados abertos à internet entre inúmeros outros exemplos. Atacantes exploram essa vulnerabilidade buscando conhecer mais profundamente a API em busca de informações que direcionam melhor seu ataque e brechas que sirvam de porta de entrada.

Esse problema pode ser particularmente delicado em operações grandes e complexas. Por mais que haja validações manuais e automáticas para identificá-lo em diferentes instâncias, esses processos abrangem apenas erros de configuração conhecidos e divulgados. A quantidade de partes móveis também aumenta a probabilidade de alguma área estar sujeita a erros. Por fim, as falhas de configuração podem estar escondidas nas interações entre essas partes móveis, ocultando o problema.

Quer conhecer as TOP 10 ameaças para APIs da OWASP? Baixe nosso Ebook Gratuito: API Security – Guia para Iniciantes

O BFLA, traduzido para o português como Autorização Quebrada a Nível de Função, é outro tipo de Quebra de Controle de Acesso. É parecido com o BOLA, porém, enquanto o alvo do BOLA são os objetos com que a API interage, o alvo do BFLA são as funções da API. Para explorar um caso desse tipo, o atacante acessa APIs que executam ações às quais seu usuário não tem privilégio, por exemplo, acessar uma API administrativa tendo privilégio de usuário comum.

Também é um caso de BFLA um usuário anônimo executar ações restritas apenas a usuários autenticados. Um usuário acessar recursos aos quais ele não teria privilégio em sua própria conta gera apenas prejuízos localizados na receita da empresa, porém, se um usuário que não é administrador obter privilégios administrativos, ele pode gerar um dano muito maior, ao poder visualizar informações, modificar e até excluir outras contas. Outra forma grave de explorar essa vulnerabilidade é acessar objetos de outras contas que seriam só para visualização, como comentários de redes sociais, e poder modificá-los ao alterar o método da requisição (ex.: substituir GET por DELETE).

Quer conhecer as TOP 10 ameaças para APIs da OWASP? Baixe nosso Ebook Gratuito: API Security – Guia para Iniciantes

Excessive Data Exposure, Exposição excessiva de dados em português, é quando um aplicativo revela mais informações do que o necessário para o usuário por meio de uma resposta de API. Isso pode incluir dados confidenciais, como números de segurança social, números de cartão de crédito e credenciais de login. Quando essas informações são divulgadas, agentes mal-intencionados podem usá-las para explorar o usuário de alguma forma, como roubo de identidade ou fraude financeira.

Os desenvolvedores de API geralmente cometem o erro de expor todas as propriedades do objeto sem considerar sua sensibilidade individual e confiam no código do lado do cliente para realizar a filtragem de dados. O problema é que agentes maliciosos podem instalar proxies em computadores ou smartphones, tendo acesso aos dados que não são exibidos pelo front-end. Além disso, combinada com outras vulnerabilidades, a exposição excessiva pode ampliar o estrago de uma vulnerabilidade, como por exemplo, exibir dados de cartão de crédito em uma API de dados pessoais com autenticação quebrada.

Quer conhecer as TOP 10 ameaças para APIs da OWASP? Baixe nosso Ebook Gratuito: API Security – Guia para Iniciantes

O BOLA, traduzido para o português como Autorização Quebrada a Nível de Objeto, é um tipo específico de Quebra de Controle de Acesso (Top 1 na lista da OWASP para aplicações web). É uma vulnerabilidade idêntica à conhecida como IDOR (Insecure Direct Object Reference ou Referência Direta ao Objeto Insegura), que já esteve no Top 2 em uma das primeiras listas para aplicações web.

Pense no objeto como sendo o estado de um recurso da API, como um dado pessoal de um usuário, um comentário ou uma compra. Quando um objeto tem sua autorização quebrada, significa que alguém que não tem permissão sobre ele possa acessá-lo se referencia-lo diretamente, mesmo estando autenticado.

É como se houvesse um condomínio fechado em que todas as casas estivessem destrancadas. Um visitante malicioso pode conseguir a credencial de um morador para atravessar o portão do condomínio (autenticação). Uma vez dentro do condomínio, ele é capaz de entrar não só na casa do dono dessa credencial, como em qualquer casa, já que estão destrancadas (quebra na autorização).

Agora, imagine uma API em que você forneça seu CPF para obter seus dados financeiros. Se ela estiver vulnerável ao BOLA, para um agente malicioso obter dados de qualquer cliente, basta oferecer o CPF dele, mesmo que tenha se autenticado como outro. Como você pode ver, uma vez identificada, é uma vulnerabilidade fácil de explorar e escalar. E de grande impacto: sua aplicação vai desde vazar dados importantes a criar transações em nome de outras pessoas.

Ela também é bastante comum. Principalmente quando falamos de aplicações complexas, formadas por muitas APIs, desenvolvidas por diferentes times e com deploys frequentes, a probabilidade de algo ser posto em produção com essa falha em algum momento é alta. E por se tratar de uma falha na lógica de negócio, não é fácil detectar sua presença de forma escalável, seja em testes unitários ou a nível de análise de tráfego.

Quer conhecer as TOP 10 ameaças para APIs da OWASP? Baixe nosso Ebook Gratuito: API Security – Guia para Iniciantes

Não é segredo que as APIs estão sob risco de ataque. O Gartner já estimou que em 2022 as APIs serão o maior vetor de vazamentos de dados. Porém, a discussão sobre quais são os riscos e como se proteger contra eles ainda é muito tímida nas empresas. O problema só piorará à medida que as APIs se tornarem mais complexas e mais empresas confiarem nelas para funções críticas de negócios. Os riscos de segurança aumentam exponencialmente.

Para saber como se proteger, é fundamental conhecer quais são os principais riscos. Muitos ainda acreditam que Web Application Security é suficiente para lidar com os riscos de segurança de API, o que não é verdade. A OWASP, conhecida por suas publicações periódicas a respeito das 10 principais ameaças para aplicações web, possui uma lista exclusiva para APIs, fato que ainda é pouco difundido. Conheça a seguir as principais ameaças para a segurança de APIs listadas pela OWASP.

API1:2019 Broken Object Level Authorization (BOLA):

O BOLA, traduzido para o português como Autorização Quebrada a Nível de Objeto, é um tipo específico de Quebra de Controle de Acesso (Top 1 na lista da OWASP para aplicações web). É uma vulnerabilidade idêntica à conhecida como IDOR (Insecure Direct Object Reference ou Referência Direta ao Objeto Insegura), que já esteve no Top 2 em uma das primeiras listas para aplicações web.

Pense no objeto como sendo o estado de um recurso da API, como um dado pessoal de um usuário, um comentário ou uma compra. Quando um objeto tem sua autorização quebrada, significa que alguém que não tem permissão sobre ele possa acessá-lo se referencia-lo diretamente, mesmo estando autenticado.

É como se houvesse um condomínio fechado em que todas as casas estivessem destrancadas. Um visitante malicioso pode conseguir a credencial de um morador para atravessar o portão do condomínio (autenticação). Uma vez dentro do condomínio, ele é capaz de entrar não só na casa do dono dessa credencial, como em qualquer casa, já que estão destrancadas (quebra na autorização).

Agora, imagine uma API em que você forneça seu CPF para obter seus dados financeiros. Se ela estiver vulnerável ao BOLA, para um agente malicioso obter dados de qualquer cliente, basta oferecer o CPF dele, mesmo que tenha se autenticado como outro. Como você pode ver, uma vez identificada, é uma vulnerabilidade fácil de explorar e escalar. E de grande impacto: sua aplicação vai desde vazar dados importantes a criar transações em nome de outras pessoas.

Ela também é bastante comum. Principalmente quando falamos de aplicações complexas, formadas por muitas APIs, desenvolvidas por diferentes times e com deploys frequentes, a probabilidade de algo ser posto em produção com essa falha em algum momento é alta. E por se tratar de uma falha na lógica de negócio, não é fácil detectar sua presença de forma escalável, seja em testes unitários ou a nível de análise de tráfego.

API2:2019 Broken User Authentication

Para que se faça o correto controle de acesso, é fundamental que se identifique quem está solicitando acesso. Não fazer a identificação de usuário em uma API exibe dados pessoais e sensíveis, ou não ter controle contra alguém que viole as credenciais de outros usuários outro usuários, é o que se chama de Quebra de Autenticação de Usuário ou Broken User Authentication.

Por incrível que pareça, é comum haver APIs que não deveriam ser anônimas sem autenticação. Pode acontecer tanto involuntariamente, quando o time de produto e desenvolvimento se esquece deste componente na fase de concepção, como pode acontecer voluntariamente, pelo time considerar equivocadamente que nenhum atacante irá descobrir a API, o que costuma se chamar de “segurança por obscuridade”.

Por outro lado, há APIs que possuem processo de autenticação, porém ele não é robusto o suficiente para resistir a um ataque. Agentes maliciosos podem se aproveitar do uso de credenciais roubadas, sequestro de sessão, senhas fracas, tokens de API com baixa entropia, ausência de rate-limiting e de autenticação de 2 fatores, entre outras formas de se violar a autenticação de terceiros. O impacto causado por este tipo de ataque é similar ao da vulnerabilidade anterior.

API3:2019 Excessive Data Exposure

Excessive Data Exposure, Exposição excessiva de dados em português, é quando um aplicativo revela mais informações do que o necessário para o usuário por meio de uma resposta de API. Isso pode incluir dados confidenciais, como números de segurança social, números de cartão de crédito e credenciais de login. Quando essas informações são divulgadas, agentes mal-intencionados podem usá-las para explorar o usuário de alguma forma, como roubo de identidade ou fraude financeira.

Os desenvolvedores de API geralmente cometem o erro de expor todas as propriedades do objeto sem considerar sua sensibilidade individual e confiam no código do lado do cliente para realizar a filtragem de dados. O problema é que agentes maliciosos podem instalar proxies em computadores ou smartphones, tendo acesso aos dados que não são exibidos pelo front-end. Além disso, combinada com outras vulnerabilidades, a exposição excessiva pode ampliar o estrago de uma vulnerabilidade, como por exemplo, exibir dados de cartão de crédito em uma API de dados pessoais com autenticação quebrada.

API4:2019 Lack of Resources & Rate Limiting

Lack of Resources & Rate Limiting, em português, significa falta de recursos ou de rate-limiting. Toda API consome recursos que são limitados, como CPU, memória e armazenamento. Quando o consumo de algum desses recursos chega ao limite, a API começa a falhar, trazendo prejuízo à experiência dos usuários. Existem duas formas de exaurir uma API: por meio de consultas onerosas ou por meio do volume de consultas. Por isso é importante o dimensionamento correto do back-end e forçar limites de uso que o mantenham longe do limite suportado.

Quando o uso excessivo da API é intencional, com o objetivo de derrubar ou prejudicar sua experiência, chamamos isso de Ataque de Negação de Serviço ou Denial of Service (DoS ou DDoS quando se usam diversos IPs para atacar, ou seja, distribuído). A falta de limitação da taxa de requisições, o que chamamos de rate-limiting, também abre portas para outros objetivos maliciosos, como ataques por brute-force, roubo de credenciais e enumeração, todos ataques que dependem de tentativa e erro para descobrir informações como senhas e vulnerabilidades

Quer conhecer as 10 principais ameaças listadas pela OWASP? Baixe nosso ebook grátis e tenha acesso – API Security: Guia para Iniciantes