by adminPor que métodos tradicionais não protegem APIs
Estamos fazendo uma série de post sobre proteção de APIs de serviços financeiros e, no último texto, explicamos por que os principais desafios da proteção das APIs. Hoje você vai entender por que os métodos tradicionais não são capazes de protegem as APIs.
Primeiramente, vale saber o óbvio: as instituições financeiras usam as práticas recomendadas durante o processo de desenvolvimento. O objetivo é minimizar as vulnerabilidades no código de produção. Apesar disso, não se deve esperar que as equipes de DevOps sejam capazes de eliminar todas as vulnerabilidades antes da implementação. Outra consideração importante é que as equipes de DevOps precisam agir rápido. Nesse processo, a segurança não pode inibir a rapidez da inovação.
Desenvolver com proteção é desafio
As equipes distribuídas e remotas aumentam a complexidade para identificar vulnerabilidades. Mesmo com práticas de DevOps maduras, pode ser um desafio obter acesso a todos os códigos, aplicativos e sistemas. Trabalhar com equipes terceirizadas complica ainda mais o serviço. Isso porque a certificação do provedor só vai até certo ponto, e as cadeias de suprimento digitais são complexas.
Além disso, o aplicativo precisa ser liberado e entrar em produção para que seja possível identificar algumas vulnerabilidades. Com as vulnerabilidades chegando inevitavelmente à produção, a proteção no tempo de execução é fundamental para evitar que os invasores explorem as vulnerabilidades.
Diferenças entre proteções tradicionais e proteção de APIs
A maioria das instituições financeiras têm stacks de segurança de tempo de execução sofisticados. Eles normalmente são compostos por várias camadas de ferramentas de proteção como mitigação de bots, WAFS e gateways de API. Essas ferramentas tradicionais conseguem oferecer alguns recursos básicos de segurança e proteção para os aplicativos tradicionais. Porém, falta a elas a arquitetura e o contexto necessários para identificar e impedir ataques que visam a lógica única de cada API. Entenda, ponto por ponto:
- A autenticação e autorização são recursos fundamentais essenciais para a segurança. No entanto, o Salt Security State of API Security Report Q3 2021 descobriu que 95% das explorações de API acontecem em APIS autenticadas. Além disso, muitos invasores se aproveitam das falhas de autorização autorização mais comuns, chamadas BOLA (Broken Object Level Authorization), a ameaça número um da OWASP API Security Top 10 list.
- A criptografia como de TLS é importante para proteger os dados em trânsito contra ataques do tipo “homem no meio”. Mas os invasores têm acesso fácil aos dados não criptografados em um endpoint cliente usando ferramentas comuns como o proxy 0WASP Zed Attack ou o Portswigger Burp Suite.
- Definição de taxa limite é outra abordagem de segurança comum, mas esses controles não fazem nada para identificar ou deter os invasores que usam métodos sutis para se manter nos limites da política.
- As ofertas de mitigação de bots geralmente baseiam-se em uma combinação de técnicas que incluem código no lado do cliente e CAPTCHAS para detectar e impedir ataques. Essas abordagens podem deteriorar a experiência do aplicativo para os usuários legítimos. 0s invasores sofisticados conseguem fazer engenharia reversa do código do lado do cliente e ignorar os CAPTCHAS, tornando essas abordagens ineficazes.
Para atacar suas APIS, os invasores fazem engenharia reversa e usam técnicas de reconhecimento para entender a estrutura e a lógica específica. O reconhecimento leva tempo, tem uma atividade baixa e lenta e métodos sutis para sondar uma API e mapear a estrutura, identificar os componentes do aplicativo em uso, entender a lógica da API e procurar vulnerabilidades.
É difícil reconhecer um invasor
A atividade de reconhecimento do invasor se parece com o tráfego normal da API para as ferramentas tradicionais, como WAFS, gateways de API e outras soluções baseadas em proxy. Além disso, a arquitetura dessas ferramentas as limita a inspecionar uma transação por vez, isoladamente e além da definição de taxa limite. Elas dependem de assinatura para detectar padrões de ataque bem conhecidos, como XSS (Cross-Site Scripting) e SQLI (SQL Injection).
Ou seja, se a transação não corresponder a uma assinatura de ataque conhecida, ela passará pelo WAF. Por fim, como cada API é única e possui vulnerabilidades específicas, as assinaturas não podem ajudar a evitar os ataques à APIs. As ferramentas como WAFS e gateways de API não conseguem conter os ataques que visam vulnerabilidades específicas da API nem identificar as características das atividades de reconhecimento de um invasor.
Salt Security: big data e IA a favor da segurança das APIs
A SALT é uma solução que combina Big Data e Inteligência Artificial para identificar potenciais ameaças por contexto, melhorando a sua postura de segurança em APIs. É primeira plataforma patenteada da indústria para evitar a próxima geração de ataques de API, usando proteção comportamental. Saiba mais no vídeo abaixo:
Mais sobre ataques a APIs
- Ataques de APIs são nova fronteira de criminosos
- As maiores invasões de API dos últimos tempos
- APIs de open bankings e suas vulnerabilidades
- O que querem os criminosos com ataques de APIs
- Conheça os desafios da proteção de APIs
Próximos posts
- O que é necessário para proteger as APIs de serviços financeiros
- Proteção de APIs de serviços financeiros com a Salt