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

Insufficient Logging & Monitoring – O que é?

Grande ataques normalmente não acontecem rapidamente. Existe um tempo para reconhecer o terreno, encontrar uma brecha, escalar horizontalmente, comprometer sistemas. Quanto mais o atacante voa abaixo do radar, mais chances ele tem de atingir seus objetivos. Insufficient Logging and Monitoring, ou Registro e Monitoração Insuficiente tratam sobre a falta de sensibilidade deste radar.

Quanto mais completo e objetivo é o sistema de registro e monitoramento das APIs, maiores as chances de se detectar comportamentos anormais que atacantes exibem em sua jornada. Quanto mais cedo um agente malicioso é identificado e bloqueado, melhor. Por mais que se deseje aplicações seguras por padrão, e soluções de mitigação que trabalhem em tempo de execução, não é possível garantir 100% de efetividade nessas estratégias, por isso registro e monitoramento são indispensáveis.

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

Improper Assets Management – O que é?

Se suas APIs estão mal documentadas, pode ter certeza de que alguém queira atacá-las fará uma documentação mais completa usando engenharia reversa. É disso que se trata a vulnerabilidade Improper Assets Management ou Gestão de Ativos Imprópria. Para se estar à frente dos ataques, é fundamental ter conhecimento de todo o ambiente para se avaliar com precisão quais APIs oferecem mais risco e priorizar ações sobre elas.

Com frequência, empresas se deparam com APIs que nunca foram documentadas, principalmente internas, APIs com documentação desatualizada e APIs que já foram descontinuadas, mas ainda não foram tiradas de produção. Isso pode oferecer grandes riscos. APIs descontinuadas deixam de receber patches de segurança, mesmo estando em produção. APIs sem documentação podem conter falhas de configuração como ausência de rate-limiting e monitoração. APIs com documentação desatualizada podem conter vulnerabilidades escondidas em parâmetros ocultos.

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

Injection – O que é?

A injeção é um antigo problema do domínio de segurança para aplicações web que também acontece com frequência em APIs. Ocorre quando uma API recebe entrada de uma fonte não confiável e a usa de forma não segura, executando um comando que não é previsto no funcionamento correto, cujo objetivo é malicioso. Isso pode conduzir, por exemplo, à exposição de informações sensíveis, perda de dados e quebra de autenticação.

Os vetores de ataque típicos de ameaças maliciosas de injeção de API incluem SQL, comandos do Sistema Operacional, LDAP, NoSQL, entre outros. Usando como exemplo a injeção de SQL, um invasor envia uma solicitação contendo um trecho de sentença SQL que pode ser interpretado literalmente, estendendo a sentença que seria enviada ao banco de dados com um trecho com objetivos maliciosos.

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

Security Misconfiguration – O que é?

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

Mass Assignment – O que é?

A vulnerabilidade de Atribuição em Massa, também chamada de Mass Assignment, ocorre quando um aplicativo da Web usa um conjunto de dados fornecidos pelo usuário e os atribui automaticamente a variáveis ​​no código do aplicativo sem a higienização adequada. Essa falha de segurança permite que um invasor injete dados maliciosos nos campos de entrada de um aplicativo, resultando na execução de ações não intencionais ou na exposição de dados confidenciais.

Os dados maliciosos podem ser parâmetros ocultos que se relacionem diretamente a desde um campo privado do banco de dados, quanto uma variável interna que eleve os privilégios do usuário. Frameworks de desenvolvimento são especialmente vulneráveis, pois incorporam essas relações para acelerar o processo de criação de software, o que pode passar despercebido pelos engenheiros.

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

Broken Function Level Authorization (BFLA) – O que é?

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

Lack of Resources & Rate Limiting – O que é?

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 TOP 10 ameaças para APIs da OWASP? Baixe nosso Ebook Gratuito: API Security – Guia para Iniciantes

Excessive Data Exposure – O que é?

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

Broken User Authentication – O que é?

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.

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

Broken Object Level Authorization (BOLA) – O que é?

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