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

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

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

Se você já conhecia a OWASP Top 10, mas não sabia que havia uma lista específica da entidade para APIs, provavelmente você deve ter estranhado. Porém, quando você pensa em termos de arquitetura da aplicação, faz todo o sentido haver uma lista dedicada para enfrentar problemas específicos de API.

A OWASP Top 10 para aplicações web surgiu em uma época em que a maioria das aplicações seguia uma arquitetura em que o front-end era renderizado no servidor. Sendo assim, as regras de negócio eram todas processadas no servidor, que entregava os arquivos HTML já com os dados incorporados. Isso limitava muito a superfície de ataque, sendo necessário um pouco de engenhosidade para conseguir manipular dados, por isso a prevalência de SQL Injection e XSS.

Nessa mesma época, as aplicações eram majoritariamente monolíticas, sendo executadas em um grande bloco de código homogêneo, dentro de máquinas em um datacenter ou em VMs em cloud. Os pontos de entrada na aplicação eram poucos, sendo mais simples de controlar. Era simples passar todo o tráfego pelo mesmo nó de uma ferramenta de WAF e normalmente, autenticação e autorização eram realizadas em um ponto único na entrada da aplicação. Problemas de autenticação e autorização já se faziam presentes, mas não com a mesma força de injections.

O que muda com as APIs? Dada a função delas, os dados são expostos de forma bem mais direta do que em uma página renderizada no servidor. Uma simples falha de quem programa já é suficiente para expor informações sensíveis sem muito trabalho de quem está explorando. Talvez você esteja se perguntando por que isso é um problema, dado que o que é mais simples também é mais fácil de revisar a qualidade. O grande problema é que a evolução das APIs vem acompanhada com o crescimento da complexidade.

As APIs diminuem o acoplamento das funções de uma aplicação, permitindo uma distribuição mais eficiente do trabalho de desenvolvimento, o que acelera a entrega de novos produtos a um nível que antes era inviável. Como consequência, geramos uma malha cada vez mais complexa de comunicação entre back-end e front-end e dentro do próprio back-end.

O tráfego externo que antes era forçado para entrar em apenas um nó, hoje pode ter à disposição inúmeros pontos de entradas (às vezes desconhecidos). O controle e conhecimento pleno da arquitetura que uma equipe de segurança, se perdeu como consequência da velocidade com que novos produtos são lançados. As assinaturas de padrões de ataque, normalmente associados às linguagens e frameworks específicos utilizados em um monolito, perderam eficiência em um ambiente que pode envolver a comunicação de microsserviços construídos em diferentes linguagens.

Como exemplo das consequências deste fenômeno, vemos que a OWASP Top 10 para APIs tem uma presença muito forte de falhas de autenticação e autorização quando comparada com a OWASP Top 10 para aplicações web de 2017. Provavelmente, a ascensão da Quebra de Controle de Acesso à primeira posição na lista para aplicações web divulgada em 2021 tenha relação com a importância das APIs nas aplicações web hoje. O processo de autenticação e autorização em aplicações distribuídas (que muitas vezes estão por trás de APIs) pode ser extremamente desafiador em relação ao mesmo processo em um monolito.

Isso não significa que ferramentas de Web Application Security não funcionam mais. WAF (Web Application Firewall), SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing) entre outras soluções para segurança de aplicações web continuam a ter o seu papel, uma vez que os problemas solucionados por elas continuam existindo, principalmente no contexto individual de cada microsserviço. O que muda é que com a complexidade trazida pelas arquiteturas de aplicação viabilizadas pelas APIs, novos comportamentos emergem, sendo necessárias novas abordagens para mitigar os riscos.

Quer aprender mais sobre API Security? Baixe nosso Ebook Grátis!

Para entender o que é uma web API, precisamos dar um passo para trás e entender o que é uma API em si. Segundo a Mozilla Foundation, APIs (Application Programming Interfaces) são construções que permitem que se interaja com uma aplicação através de software. Elas possibilitam conectar diferentes sistemas que podem se utilizar de diferentes linguagens de programação. O que poderia ser uma comunicação impossível ou inviável, encontra um ponto de conexão em comum usando este artefato.

Vejamos em uma contextualização:

Considere que um cliente GoCache queira ter uma integração com a CDN da GoCache para obter dados de tráfego e eventos de segurança, como essa comunicação é possível se ele não tem acesso ao código da CDN GoCache?

Simples, através da API GoCache, que disponibiliza mediante a regras de negócio o acesso a funções, dados e controle da CDN.

O que diferencia uma web API é a comunicação via web, usando principalmente o protocolo HTTP. Com a vida do ser humano cada vez mais cercada por aplicações web e mobile, as web APIs estão se tornando peça chave para grandes transformações na forma como se desenvolve e opera software. A seguir, apresentaremos os principais usos de APIs e os principais padrões em que sua comunicação ocorre.

Quais são os principais usos de Web APIs?

Modernização de arquiteturas de aplicações web

As primeiras aplicações web eram bastante estáticas. As páginas HTML já chegavam do servidor em sua forma final e mesmo que houvesse interatividade via javascript, para atualizar algum conteúdo da página, era necessário que toda sua estrutura fosse enviada novamente pelo servidor. Vamos entrar num acordo que há muito a ser melhorado nessa experiência. E foi justamente o motivo de uma grande evolução introduzida por volta de 2005.

Nessa época foi introduzido o AJAX (Asynchronous Javascript and XML). Essa tecnologia permitia a solicitação assíncrona de dados ao servidor, por meio de javascript e XML, evitando que toda a página tivesse que ser recarregada para atualizar apenas uma pequena parte do conteúdo. Apesar de não serem chamadas por esse nome neste período, pode-se considerar este uso um exemplo de web API. Mais tarde, no fim da década, a introdução dos smartphones trouxe os aplicativos móveis, cuja comunicação com o servidor ocorre de maneira similar ao AJAX.

De lá para cá, novos padrões e frameworks têm surgido, mas podemos agrupar essas tendências em um fenômeno: desacoplamento entre front-end e back-end, no qual os dados são fornecidos assincronamente via API e a página é renderizada ou no navegador, ou em um servidor dedicado para essa função. Desconsiderando outros aspectos, uma das principais vantagens dessa abordagem arquitetural é a agilidade ganha com o menor acoplamento. Quem desenvolve o front-end depende menos de quem trabalha com o back-end para desenvolver e testar novos produtos, e vice-versa. Equipes que definem o design das APIs antes de desenvolver (API First) se beneficiam ainda mais dessa arquitetura agilidade.

Outra característica de arquitetura das primeiras aplicações web é o monolito, ou seja, as aplicações eram majoritariamente constituídas por um bloco homogêneo de código, executado em um único servidor (ou replicado em mais servidores para escala horizontal). Quando se trata de aplicações pequenas, como por exemplo, um blog WordPress, essa abordagem não costuma gerar transtornos, sendo até preferível em grande parte dos casos. Mas quando falamos de aplicações mantidas por dezenas de desenvolvedores ou mais, a situação pode ficar um pouco mais complicada.

Isso começou a ser percebido com mais clareza na época do florescimento das metodologias ágeis e da cultura DevOps. Com dezenas de equipes autônomas trabalhando no mesmo código, é fácil enxergar o potencial que as dependências entre o trabalho delas têm de ser um obstáculo ao desenvolvimento ágil. E como, mesmo o deploy de uma pequena mudança impacta toda a aplicação, a frequência com que novas funcionalidades entram em produção também fica comprometida.

Houveram algumas tentativas de mudar esse cenário, como SOA (Service Oriented Architecture), mas não alcançaram o sucesso. O cenário começou a melhorar com bastante influência da arquitetura de contêineres. Os contêineres fornecem um ambiente muito mais leve, consistente e seguro para quebrar o monolito em dezenas, centenas e até milhares de pequenos serviços, os chamados “microsserviços”. Tecnologias de orquestradores, como Kubernetes, tem auxiliado muito o trabalho de lidar com a complexidade criada por esse tipo de ambiente.

A velocidade desenvolvimento de software cresceu de forma assombrosa nos últimos anos, junto com a difusão dessa arquitetura. E onde entra o papel das APIs? São justamente elas as responsáveis pela comunicação entre os microsserviços. As APIs fornecem uma interface com um nível de abstração suficiente para diminuir o acoplamento entre as diferentes funções da aplicação sem comprometer a coesão do conjunto.

Trocas de valor entre empresas

É praticamente inviável para a maioria dos produtos que todos os seus componentes sejam produzidos pela mesma empresa. Você dificilmente verá um fabricante de celular fazendo seus próprios parafusos, por exemplo. Mas uma coisa que não é tão evidente, é que certas indústrias, como a automotiva e mais recentemente, a aeronáutica, descobriram que podem terceirizar o desenvolvimento e produção de componentes mais complexos e fundamentais para a funcionalidade de seu produto, buscando focar em suas competências chave.

Uma fabricante de aeronaves pode terceirizar o desenvolvimento e produção das asas de seu avião, diminuindo o aporte de capital necessário para desenvolver seu novo produto e podendo concentrar seu foco em aspectos mais globais dele. Mas o que isso tem a ver com APIs? O mesmo fenômeno acontece com a indústria de software e as APIs têm papel importante nisso.

Se voltarmos algumas décadas no tempo, veremos que mesmo nas aplicações web mais antigas, muitos componentes já eram fornecidos por terceiros. Bancos de dados, servidores web e sistemas operacionais seriam muito onerosos se cada empresa que criasse uma aplicação web tivesse que construí-los. E entre 1999 e 2000 houve um grande marco de evolução: a Salesforce surgiu como a primeira empresa que nasceu no modelo de Software como um Serviço (SaaS – Software-as-a-Service). Curiosamente, nesse mesmo ponto surgiu o que é considerado hoje como a primeira web API.

Basicamente, ao invés de oferecer um CD-ROM com um software de CRM a ser instalado nos servidores de seus clientes, a Salesforce trouxe a proposta de entregar a funcionalidade de seu produto via internet. Desse momento em diante, principalmente nos últimos anos, vimos uma explosão de softwares sendo vendidos como serviços. Movimentos como Open Banking e Open Health só acentuam essa tendência.

Hoje, para criar um e-commerce, você não precisa criar seus próprios sistema de pagamentos, helpdesk, mecanismo de recomendação, etc. Tudo isso pode ser fornecido por terceiros, ajudando a focar no que importa, que no caso é garantir uma boa experiência de compra na loja virtual. Como nesse modelo o fornecedor opera seu próprio software, é imperativo que este processe os dados fornecidos por seus clientes. E são justamente as APIs que são a interface de troca de dados entre os dois lados dessa troca de valor.

O conteúdo apresentado nesse post faz parte do nosso Ebook – API Security: Guia para Iniciantes. Faça o download grátis e tenha acesso a um documento com mais de 40 páginas!