Blog

Proteção de APIs: o que você precisa saber na nova economia de APIs

A tecnologia está em constante evolução. Vimos isso nos últimos anos na forma como os aplicativos são desenvolvidos (por exemplo, CI / CD), entregues (por exemplo, microsserviços e nuvem) e consumidos (por exemplo, mais SaaS e dispositivos móveis). Como se isso não bastasse, também enfrentamos ameaças de atacantes que também estão evoluindo e parecem estar sempre um passo à nossa frente. Mas antes de pular para os detalhes de proteção da API, vamos entender o que mudou no mundo dos aplicativos da web nos últimos anos para torná-los mais parecidos com essa grande base.

Aplicativos da Web tradicionais

A geração anterior de aplicativos da web eram aplicativos de várias páginas. Os clientes eram navegadores da web com recursos de processamento limitados e os servidores renderizariam as páginas HTML preparadas para serem enviadas ao navegador. Cada página HTML do site era basicamente uma página diferente processada pelo servidor.

Explorando as implicações

Vamos dar uma olhada nas implicações deste novo modelo de aplicativos baseados em API:

  • Mais área de superfície a ser protegida – os aplicativos tradicionais expõem um pequeno número de páginas HTML, enquanto os aplicativos modernos baseados em API expõem muitas APIs, terminais de API e muitos dados confidenciais. Além disso, os ambientes de aplicativos modernos têm muitos tipos diferentes de APIs (por exemplo, APIs de aplicativos móveis, APIs de microsserviços e APIs de B2B expostos a outros aplicativos e externamente a parceiros)
  • Os padrões de tráfego mudaram – O tráfego entre um cliente e um servidor parece totalmente diferente com aplicativos baseados em API. No caso de aplicativos tradicionais, o cliente envia menos dados em solicitações e a resposta do servidor contém páginas HTML grandes e complexas. Em aplicativos modernos baseados em API, o cliente envia mais parâmetros na solicitação e recebe dados brutos do servidor na resposta. Tanto as solicitações quanto as respostas são mais padronizadas e possuem um formato uniforme (REST / SOAP). Se pensarmos nisso, o servidor de back-end se tornou mais como uma fonte de dados.

Impacto na proteção de API

Este novo modelo de aplicativo baseado em API tem um grande impacto na segurança e proteção da API:

  • A má notícia – existem novos vetores de ataque dos quais você precisa estar ciente. Os aplicativos baseados em API abrem a porta para novos tipos de ataques que visam a lógica dos aplicativos por meio de APIs em um nível muito granular até cada terminal individual.
  • A boa notícia – este modelo permite novas abordagens de detecção, uma vez que as solicitações e respostas com aplicativos baseados em API são geralmente padronizadas e baseadas em um formato uniforme como REST ou SOAP. O formato padronizado em conjunto com a inteligência artificial (IA) facilita o monitoramento do tráfego e a detecção de atividades suspeitas.

Como abordar aplicativos modernos e proteção de API

Você não pode garantir proteção API para seus aplicativos modernos com um WAF simples ou qualquer outra solução tradicional como um RASP, DASP ou um scanner de vulnerabilidade. As soluções tradicionais funcionam com base em assinaturas ou padrões conhecidos e só podem protegê-lo de ataques comuns e conhecidos, como injeção de SQL (SQLi), script de site cruzado (XSS) e falsificação de solicitação de site cruzado (CSRF). Essas soluções não podem detectar vulnerabilidades na lógica exclusiva de suas APIs. Além disso, esses “ataques antigos”, antes populares, tornaram-se menos comuns devido às arquiteturas de aplicativos modernas e às melhores práticas de desenvolvimento. Alguns exemplos:

  • Cross-Site Request Forgery (CSRF) e alguns ataques refletidos de Cross Site Scripting (XSS) não podem ser explorados em muitos aplicativos da web modernos, pois não usam autenticação baseada em cookies.
  • As injeções de SQL (SQLi) estão se tornando menos comuns porque as estruturas de aplicativos fornecem soluções integradas para que os desenvolvedores as evitem.

Os criminosos não desistiram e também evoluíram para acompanhar o tempo. Suas APIs são complexas e exclusivas e os invasores tiram proveito disso procurando vulnerabilidades na lógica exclusiva. Essas são coisas que não podem ser identificadas por uma assinatura e são muito tortuosas para serem tratadas com boas práticas de desenvolvimento. Sua solução de proteção de API deve ser capaz de entender a lógica única da API em um nível granular para identificar vulnerabilidades potenciais e interromper ataques.

Faça o inventário de suas APIs

As violações que vimos nos últimos anos que visam a lógica exclusiva das APIs são perdidas por soluções que carecem de uma compreensão granular dessas APIs. Para fornecer novos recursos e correções de bugs rapidamente, os desenvolvedores geralmente escrevem APIs sem pensar muito sobre a estrutura ou além dos princípios básicos de segurança.

aqui estão alguns exemplos:

Existência de um endpoint de API de administrador em uma API regular.

/ api / v2 / users / export_all_users

Em vez de:
/ api / v2 / admins / export_all_users

APIs antigas e temporárias que deveriam ter sido excluídas

/ api / v2 / temp / set_server_key

API de depuração interna exposta à Internet e que pode expor dados confidenciais

/ api / dev / app_log

A base de uma boa estratégia de proteção de API começa com o inventário e a documentação de suas APIs para que você possa acompanhar as mudanças, encontrar pontos potencialmente vulneráveis ​​e marcar todos os terminais que lidam com informações de identificação pessoal (PII).

Monitore sua atividade de API

Uma das realidades mais importantes que você deve enfrentar como uma empresa que armazena dados valiosos do usuário (PII, cartões de crédito, etc …) é que, em algum ponto, um desenvolvedor cometerá um erro sem saber que se tornará uma oportunidade para um invasor. As soluções tradicionais não enxergam esses tipos de ataques de API. Aqui está um exemplo de uma plataforma de negociação de ações que testei com um endpoint interessante:

/ api / v2 / readTransaction? trans_id = < GUID >

Isso retorna detalhes de uma transação específica, incluindo PII do comerciante. Depois de algumas pesquisas e tentativas, simplesmente removi o trans_id da solicitação e o servidor retornou um dump completo de todas as transações no banco de dados. Isso aconteceu porque os desenvolvedores montaram uma consulta para recuperar apenas os detalhes da minha transação com base no GUID enviado. Quando o trans_id estava faltando, o servidor retornou a coleção inteira.

As soluções de segurança tradicionais simplesmente não são granulares o suficiente para entender a lógica da API e não podem detectar esses tipos de anomalias, mesmo que seja algo simples, como um campo ausente na solicitação. Testar ou hackear uma API é um processo demorado de tentativa e erro que inclui muitas anomalias suspeitas. Para evitar que um invasor explore essas vulnerabilidades de API exclusivas, você deve monitorar suas APIs e detectar qualquer atividade anormal.

Seus aplicativos evoluíram, assim como suas ameaças. Na medida em que as APIs se tornam cada vez mais predominantes em ambientes de aplicativos, você não pode mais simplesmente confiar em soluções tradicionais para mantê-lo protegido contra ataques modernos. A primeira etapa é fazer o inventário das APIs em uso em seu ambiente para que você saiba o que deve proteger. Com uma compreensão granular de suas APIs, uma solução de proteção de API deve ser capaz de basear o comportamento normal e observar o tráfego em tempo real para relatar atividades suspeitas que podem ser uma indicação de ameaças potenciais às suas APIs. Por fim, é fundamental que você tenha o nível certo de detalhes quando uma atividade suspeita for detectada, para que possa interromper rapidamente a ameaça e trabalhar com as equipes de desenvolvimento para fechar quaisquer lacunas nas próprias APIs.

Quer saber como proteger suas APIs? Fale conosco e conheça a solução da SALT Security.

 

A transformação começa agora.