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

A economia da API
Interfaces de programação de aplicações (API) são funções e recursos que permitem que aplicativos interajam entre si. As APIs, geralmente descritas como interfaces máquina a máquina, incluem bibliotecas, estruturas, kits de ferramentas e kits de desenvolvimento de software.

As APIs estão impulsionando a Internet e nossa economia. Você usa uma API toda vez que entra em um aplicativo como o Instagram, envia uma mensagem ou verifica seu e-mail. As APIs permitem uma troca de dados tranquila.

Além disso, as APIs simplificam para os desenvolvedores adicionarem novas funcionalidades aos seus aplicativos. Em vez de construir um produto do zero, um desenvolvedor pode usar uma API e construir em cima do que outros, ou ele mesmo, já fizeram. Esse atalho economiza tempo e garante que funcionalidades importantes funcionem corretamente.

Além disso, com a disseminação da tecnologia em nuvem, mais e mais programas SaaS estão migrando para a nuvem. Esses serviços em nuvem usam APIs para se comunicarem. De mensagens de texto a comércio eletrônico e simplesmente verificar as notícias, as atividades diárias dependem do suporte da API.

Como resultado dessas conveniências, o uso da API está aumentando rapidamente. Com isso, pode haver dezenas, centenas ou até milhares de APIs conectando aplicativos internos entre si e com o mundo externo em uma única organização. Mas nem tudo são boas notícias.

Ameaças à API
À medida que o uso de APIs aumenta, o mesmo acontece com as ameaças que as visam. Um ataque de API ocorre quando uma API é usada ou testada de forma maliciosa. Os ataques baseados em API são três vezes mais comuns do que os ataques contra aplicativos HTML. As APIs incluem documentação sobre sua estrutura e métodos de implementação, tornando mais fácil para os hackers usarem essas informações para lançar ataques cibernéticos. Se uma API for quebrada, exposta ou não estiver adequadamente protegida, isso pode resultar na exposição de dados confidenciais ou pessoais. Falhas de segurança, ou mesmo equívocos, podem levar a esses ataques. Portanto, a segurança da API deve evoluir para permanecer atualizada nesse ambiente em constante mudança.

Equívocos
Muitas empresas e organizações não entendem completamente as APIs. Esses equívocos podem levar uma API a ficar desprotegida e vulnerável a ataques. Aqui estão três equívocos comuns:

Não preciso conhecer todas as minhas APIs
Algumas organizações pensam que não têm nenhuma API, algumas não estão cientes de todas as suas APIs e outras podem pensar que há pouco tráfego passando por elas. Muitas empresas hoje não mantêm um inventário completo de todas as APIs, o que cria uma vulnerabilidade significativa.

Conhecer todas as APIs usadas por seus aplicativos, incluindo APIs de sombra, facilita o conhecimento das alterações e dos riscos em evolução. Configurações incorretas, comportamento suspeito e ataques cibernéticos podem ocorrer quando as equipes de segurança não têm conhecimento das APIs e os protocolos de violação de dados confidenciais não podem proteger suficientemente os aplicativos de possíveis ataques.

WAF é suficiente
Muitas empresas ainda contam com ferramentas de segurança tradicionais, como gateways de API e firewall de aplicativo Web (Web Application Firewalls – WAFs) ou outros métodos de proteção convencionais. Mas, embora esses meios possam proteger suas APIs de ameaças conhecidas, eles não protegem você de outras ameaças.

As ferramentas tradicionais perdem completamente os ataques que visam a lógica das APIs à medida que as ameaças se tornam mais complicadas e sofisticadas. Como esses ataques lentos e de baixo volume ocorrem ao longo de horas ou dias, os WAFs não podem coletar e analisar as grandes quantidades de dados necessários para estabelecer o contexto e identificar essas atividades sutis do invasor.

Hackers não conseguem ver minha API
Outro equívoco comum é que as APIs estão escondidas nos bastidores e se beneficiam da segurança por meio da obscuridade. Em comparação com aplicativos da Web típicos, as APIs, por sua própria natureza, revelam muito mais funcionalidades e dados do aplicativo do que você imagina. Como resultado, os invasores podem explorar facilmente as APIs usando as mesmas ferramentas dos desenvolvedores, usando métodos sutis para mapear a API, entender a lógica e buscar vulnerabilidades.

Além disso, algumas empresas podem não estar cientes de APIs públicas ou não documentadas em seus sistemas e aplicativos, potencialmente permitindo a entrada de hackers.

Resumindo
À medida que o uso de APIs cresce, cresce também a motivação dos hackers para explorar as lacunas de segurança. O Gartner prevê que, até 2022, os abusos de API passarão de um vetor de ataque pouco frequente para o mais frequente. Não ter um status da API pode fazer com que empresas e negócios sejam expostos ou atacados.

A segurança da API requer o seu próprio conjunto de táticas e soluções para compreender e mitigar vulnerabilidades e preocupações de segurança específicas. A única maneira de proteger as APIs é protegê-las de forma holística e abrangente durante todo o ciclo de vida do software. Você precisa descobrir todas as suas APIs, aprender sua lógica de negócios, fazer a linha de base e rastrear o tráfego, identificar falhas de segurança ou ameaças em potencial e considerar possíveis remediações – durante todo o ciclo de vida de cada API.

Interface de Programação de Aplicação (API) são interfaces de software que permitem que os aplicativos se comuniquem. Por exemplo, você utiliza uma API toda vez que usa o Google ou o Twitter, envia uma mensagem instantânea ou verifica a previsão do tempo no seu telefone. Uma interface gráfica de usuário não é necessária para que o software se comunique. Em vez disso, as APIs são interfaces legíveis por máquina que permitem que os produtos de software compartilhem dados e funcionalidades com facilidade.

A dependência do desenvolvedor em APIs aumentou no ano passado em meio à pandemia global. Uma pesquisa do RapidAPI revela que essa dependência continuará a se expandir. Organizações de todos os tamanhos de uma ampla variedade de setores planejam ingressar na economia da API este ano, e o teste e a segurança da API foram as principais preocupações entre os entrevistados.

As APIs, como qualquer outro recurso disponível na internet, possuem vulnerabilidades. Portanto, manter a segurança é fundamental porque as APIs podem ser acessadas pela Internet, incluindo Uniform Resource Identifiers (URIs) com dados confidenciais anexados.

Riscos da API

As APIs dão a terceiros acesso aos seus dados por design. Cada API inclui um endpoint que responde a solicitações de API.

Existem falhas em todos os sistemas. Uma fraqueza em um sistema (hardware ou software) que um invasor pode explorar é conhecida como vulnerabilidade. Um endpoint de API é semelhante a um servidor da Web acessível pela Internet. Quanto maior o acesso livre e aberto do público a um recurso, maior a ameaça potencial dos abusadores. As APIs fornecem apenas controle de acesso mínimo, se houver. A superfície de ataque cresceu à medida que as APIs se tornaram uma parte essencial do desenvolvimento de aplicativos modernos. Por outro lado, muitos sites empregam controle de acesso e exigem que usuários autorizados façam login.

Um ataque de API ocorre quando um invasor usa uma API de forma maliciosa ou tenta violá-la. Os ataques de API afetam uma variedade de verticais e negócios. Ameaças perigosas estão se tornando mais comuns e aprimorando o direcionamento de aplicativos da web específicos.

O aumento de ameaças de segurança relacionadas à API nos últimos anos levou o Open Web Application Security Project (OWASP) a lançar o API Security Top 10, que ajuda a aumentar a conscientização sobre os problemas de segurança de API mais sérios que afetam as organizações.

Aplicação

À medida que as APIs se tornam mais centrais para os negócios modernos, a falta de clareza sobre quem é responsável pela segurança da API coloca organizações e usuários em perigo. Embora os riscos sejam conhecidos, quase um terço das APIs são aprovadas sem revisão pela equipe de segurança de TI de uma empresa.

Quem é responsável por proteger as APIs? Alguns acreditam que é trabalho dos desenvolvedores, enquanto outros pensam que é responsabilidade da equipe da API. Sem surpresa, as equipes de API culpam o DevOps, e o DevOps joga a bola de volta para o departamento de TI. Infelizmente, toda essa confusão leva a lacunas de segurança significativas, que hackers talentosos ficam felizes em explorar.

Quando tantas equipes lidam com o desenvolvimento da API, é difícil atribuir a responsabilidade pela sua segurança. Cada organização tem a sua própria estrutura e método de distribuição de responsabilidade, que muitas vezes é mal planejado e mal compreendido. As vulnerabilidades de segurança da API continuarão a ser exploradas por abusadores até que uma estrutura de propriedade definida esteja em vigor. No entanto, à medida que as APIs evoluem e se tornam mais amplamente utilizadas, as vulnerabilidades de segurança só aumentam.

Além disso, como as APIs operam em um ciclo constante de criação e atualizações, loops de feedback iterativo entre os estágios de desenvolvimento, teste e produção conectam as equipes de segurança e desenvolvimento e permitem um modelo de melhoria contínua da segurança.

O que você pode fazer

O software moderno é vulnerável a uma ampla gama de ameaças. Manter-se atualizado com as mais recentes explorações e problemas de segurança é uma prática inteligente, mas desafiadora. Ter benchmarks para esses problemas ajuda a garantir a segurança do aplicativo antes que ocorra um ataque.

Como as APIs criam tantos pontos de entrada na arquitetura de uma rede, colocar um firewall na frente de um servidor não é mais suficiente para proteger todos os pontos de entrada. Além disso, uma solução tradicional baseada em WAF não pode distinguir chamadas de API maliciosas e legítimas.

A única maneira de proteger totalmente as suas APIs é proteger e cobrir todas as APIs durante todo o ciclo de vida de desenvolvimento de software da API, pois várias equipes as desenvolvem. Como resultado, algumas vulnerabilidades só podem ser identificadas no nível do código em desenvolvimento. Algumas podem ser capturadas por testes com simulações inteligentes. Outras só podem ser descobertas monitorando APIs em tempo real na produção, definindo uma linha de base do comportamento esperado e detectando anomalias.

Os ataques DDoS são a mais complexa das duas ameaças, porque usam uma variedade de dispositivos que aumentam a gravidade dos ataques. Ser atacado por um computador não é o mesmo que ser atacado por uma botnet de cem dispositivos ou mais.

Parte de estar preparado para ataques DDoS é estar familiarizado com o maior número possível de formas de ataque. Nesta seção, veremos isso com mais detalhes para que você possa ver como esses ataques são usados para danificar as redes corporativas.

Os ataques DDoS podem vir de várias formas, incluindo:

Inundação SYN – Os ataques de inundação SYN são outro tipo de ataque DoS em que o invasor usa a sequência de conexão TCP para tornar a rede da vítima indisponível. O invasor envia solicitações SYN para a rede da vítima, que responde com uma resposta SYN-ACK. O remetente deve responder com uma resposta ACK, mas, em vez disso, o invasor não responde (ou usa um endereço IP de origem falsificado para enviar solicitações SYN). Cada solicitação que não é respondida ocupa recursos de rede até que nenhum dispositivo possa fazer uma conexão.

Slowloris – Slowloris é um tipo de software de ataque DDoS que foi originalmente desenvolvido por Robert Hansen ou RSnake para derrubar servidores web. Um ataque Slowloris ocorre quando o invasor envia solicitações HTTP parciais sem a intenção de completá-las. Para manter o ataque, o Slowloris envia periodicamente cabeçalhos HTTP para cada solicitação para manter os recursos da rede de computadores vinculados. Isso continua até que o servidor não possa fazer mais conexões. Essa forma de ataque é usada por invasores porque não requer nenhuma largura de banda.

Inundação HTTP – Em um ataque de Inundação HTTP, os usuários do invasor solicitam HTTP GET ou POST para lançar um ataque a um servidor ou aplicativo da web individual. Inundações HTTP são um ataque de camada 7 e não usam pacotes malformados ou falsificados. Os invasores usam esse tipo de ataque porque exigem menos largura de banda do que outros ataques para tirar a rede da vítima de operação.

Ataques Zero-Day – Ataques Zero-Day são ataques que exploram vulnerabilidades que ainda não foram descobertas. Este é um termo geral para ataques que podem ser enfrentados no futuro. Esses tipos de ataques podem ser particularmente devastadores porque a vítima não tem uma maneira específica de se preparar para eles antes de sofrer um ataque ao vivo.

Inundações de XML-RPC do WordPress – Nesse tipo de ataque, o invasor explora pingbacks do WordPress, entre outros, realizando comparativos antes de configurar o ataque. Inundações de HTTP aleatórias e inundações de desvio de cache são os ataques DDoS de camada 7 mais amplamente reconhecidos.

Um estudo recente mostrou que cerca de 75% dos tomadores de decisão de TI sofreram pelo menos um DDoS nos últimos 12 meses e 31% relataram interrupção do serviço como resultado desses ataques.

A cada dia mais e mais organizações comerciais e governamentais estão descobrindo da maneira mais difícil que o DDoS é uma ameaça que não pode ser ignorada.

E qual o segredo do “sucesso” do DDoS? Muitos ataques DDoS são bem-sucedidos não devido à habilidade ou recursos de quem faz o ataque, mas devido à falta de preparação do lado de quem precisa se defender.

Os gerentes de segurança, acostumados a lidar com ameaças como intrusões, explorações de aplicativos da web e worms, podem ainda não estar totalmente cientes de que lidar com DDoS requer uma gama de ferramentas de proteção web exclusiva e dedicada a isso.

Os ataques de negação de serviço distribuído (DDoS – Distributed denial of service) são uma subclasse de ataques de negação de serviço (DoS – denial of service). Um ataque DDoS envolve vários dispositivos online conectados, coletivamente conhecidos como botnets, que são usados para sobrecarregar um site de destino ou aplicação com tráfego falso.

Ao contrário de outros tipos de ataques cibernéticos, os ataques DDoS não tentam violar seu perímetro de segurança. Em vez disso, um ataque DDoS visa tornar o seu site e os servidores indisponíveis para usuários legítimos.

O DDoS também pode ser usado como cortina de fumaça para outras atividades maliciosas e para derrubar dispositivos de segurança, violando o perímetro de segurança do alvo.

Um ataque de negação de serviço bem-sucedido é um evento altamente perceptível que afeta toda uma base de usuários online. Isso o torna uma arma popular de escolha para hacktivistas, extorsionistas e qualquer outra pessoa que queira defender uma causa ou um ponto de vista.

Os ataques DDoS podem ocorrer em explosões curtas ou ataques repetidos, mas de qualquer forma o impacto em um site ou empresa pode durar dias, semanas e até meses, à medida que a organização tenta se recuperar. Isso pode tornar o DDoS extremamente destrutivo para qualquer organização online. Entre outras coisas, os ataques DDoS podem levar à perda de receita, corroer a confiança do consumidor, forçar as empresas a gastar fortunas em compensações e causar danos à reputação a longo prazo.

Se você administra um projeto online e ainda não sabe por onde começar para proteger sua aplicação, as perguntas básicas abaixo podem te ajudar a dar os primeiros passos.

Perguntas básicas importantes incluem:

● Quais ativos de infraestrutura precisam de proteção?

● Quais são os pontos fracos ou pontos únicos de falha?

● O que é necessário para derrubá-los?

● Como e quando você saberá que é o alvo? Será tarde demais?

● Quais são os impactos (financeiros e outros) de uma interrupção prolongada?

De posse dessas informações, é possível priorizar suas preocupações, examinando várias opções de mitigação de DDoS dentro da estrutura do seu orçamento de segurança.

Se você estiver executando um site comercial ou aplicativos online (por exemplo, aplicativos SaaS, banco online, comércio eletrônico), provavelmente desejará proteção 24 horas por dia, 7 dias por semana, sempre ativa. Um grande escritório de advocacia, por outro lado, pode estar mais interessado em proteger sua infraestrutura – incluindo servidores de e-mail, servidores FTP e plataformas de back office – do que o seu site. Este tipo de negócio pode optar por uma solução “on demand”.

O segundo passo é escolher o método de implantação. A maneira mais comum e eficaz de implementar proteção contra DDoS sob demanda para os seus principais serviços de infraestrutura em uma sub-rede inteira é por meio do protocolo de gateway de fronteira (BGP – border gateway protocol). No entanto, isso funcionará apenas sob demanda, exigindo que você ative manualmente a solução de segurança em caso de ataque.

Consequentemente, se você precisar da proteção contra DDoS sempre ativa no seu aplicativo da Web, use o redirecionamento de DNS para redirecionar todo o tráfego do site (HTTP/HTTPS) por meio da rede do provedor de proteção contra DDoS (geralmente integrada a uma rede de entrega de conteúdo, conhecidas como CDNs). A vantagem dessa solução é que a maioria das CDNs oferece escalabilidade e plantão NOC para absorver ataques volumétricos, ao mesmo tempo que minimiza a latência e acelera a entrega de conteúdo.

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