O grande susto
Um amigo comentou comigo um episódio interessante: Telefonaram para ele dizendo que era um canal de nível oito de seu banco, confirmando dados como endereço, nome de mãe e pai, cônjuge, filhos etc, dizendo que existiam transações suspeitas, e que a conta dele havia sido invadida e ele precisava ligar urgentemente para central do banco, e seguir os passos para mudanças de senha e a pessoa do nível 8 de segurança, ainda fez o favor de alertá-lo: “Por favor, não forneça suas senhas para o atendente, e sim para o canal da URA, quando o mesmo solicitar, pois esse é o canal seguro”. Por incrível que pareça, o número de telefone era muito parecido com o do banco, e no meio da noite, ainda com sono e medo de perder seu dinheiro, ele não exitou em realizar o procedimento. Para resumir a história: Este amigo caiu num grande golpe, que gerou uma grande dor de cabeça para resolvê-lo, inúmeras interações com o banco de verdade, boletins de ocorrência na polícia. Fatos como estes vem acontecendo e as vítimas podem ser não só seus clientes, mas você.
De onde informações como estas são vazadas?
Apesar da grande maioria de ataques no Brasil serem atribuídos a ransomwares, cada vez mais as empresas estão expondo APIs, o que do ponto de vista de negócios é mais que certo e necessário, entretanto a forma de expor as informações e operações, sobretudo via APIs pode comprometer não somente as empresas, mas também as regulamentações e movimentos que têm como alicerce exatamente estes componentes, entre estas temos:
- Open Finance/ Open Banking
- Open Insurance
- Início do Open Health
- Etc
Estas regulamentações, que possuem um caráter fidedigno de propiciar o empoderamento das pessoas como o centro de tudo, são elas quem decidirão quais seus dados serão compartilhados, além da forma, e claro: Com o direito de revogar a qualquer momento os usos destas informações.
Os episódios de vazamento de dados já estão presentes na nossa região desde o fim de 2019, onde 2 empresas de telefonia móvel tiveram dados vazados através da vulnerabilidade classificada pela OWASP API Top 10 como BOLA- Broken Object Level Authorization (Objeto de nível de autorização corrompido), veja a definição na prática:
” API1:2019 Autorização de nível de objeto quebrado
As APIs tendem a expor endpoints que lidam com identificadores de objetos (exemplo: CPF, CNPJ, Email etc), criando um amplo problema de controle de nível de acesso das informações de um requisitante. As verificações de autorização de nível de objeto devem ser consideradas em todas as funções que acessam uma fonte de dados usando a entrada do usuário.”
Para ilustrar este cenário, vamos observar a imagem abaixo:
Figura 1 – Fluxo de execução de um ataque BOLA
Imagine uma aplicação Web, Mobile ou até ChatBot (canal cliente), quando uma requisição é disparada com destino aos backends (endpoints, serviços), uma sequência de eventos acontece, vamos então explicar cada uma delas:
- O canal cliente envia um payload (envelope com as informações, cabeçalhos HTTP, endereço) com o destino a um determinado backend. Neste caso, imagine que a requisição foi a seguinte:
- http://minhaapi.empresa.com.br/planos-comprados/12345689000 – Onde o número no final da URL representa o CPF do cliente. Do ponto de vista funcional, até aí nenhum problema, milhares de APIs têm esse comportamento.
- O cliente fictício aqui nesta chamada com o CPF 123456789000 se chama Johnny Walker
- Já dando um spoiler: Se você usa HTTP Basic ou apenas chaves de acesso, você já está com a segurança comprometida, o ideal seria você enviar um Token JWT (JSON Web Tokens), pois estes lhe permitem trafegar informações de usuários mais seguras, o token pode ser gerado no momento da requisição e este é válido, às vezes por um período determinado, para facilitar a interação com o canal cliente.
- O Firewall irá validar a requisição, que parece sem problemas.
- A camada de WAF (Web Application Firewall) também não vê nada de errado, pois os WAFs são fundamentais para proteção de aplicações, mas falham no entendimento do contexto das requisições para definirem o que é fidedigno ou não.
- O API Gateway por sua vez, de acordo com Chris Richardson: implementa um padrão de Microsserviço (https://microservices.io/patterns/apigateway.html), que em sua grande maioria é um produto, que fará o seu papel exatamente como o figurino manda:
- A requisição tem um Token? Sim
- Este token é válido de acordo com o provedor de identidade e chaves (Issuer) ? Sim
- A quantidade de requisições está dentro do esperado deste consumidor (throttling)? Sim
- O tempo de resposta está OK (rate limit) ? Sim
- Então pode ir até o Backend e executar a instrução.
Essa é cadeia da execução, que mais uma vez: Totalmente de acordo com o que se espera, entretanto existe um grande problema: A chave para encontrar os dados do cliente está sendo passada no endereço da chamada (URL), desta forma o que acontece quando:
- Com um Token JWT válido (o mais seguro e recomendável)
- Trocando o CPF na requisição de 123456789000, que pertence a Johnny Walker, o que acontecerá se o CPF informado for: 98765432100, que pertence a Ginger Roger?
- Resposta: Os dados de Ginger serão obtidos sem problema, pois se o tempo entre uma requisição e outra não levantar suspeitas, com o Token válido, todos os envolvidos na requisição ilustrada na Figura 1, vão deixar com que esta e outras requisições também sejam executadas, resultando num vazamento de dados em massa.
O problema acima aconteceu nos seguintes casos (preservando nomes das empresas em casos éticos):
- 2019 – Uma das maiores operadoras de tv a cabo e telefonia móvel no Brasil com 8 milhões de assinantes que tiveram dados vazados.
- 2019 – Uma das maiores operadoradoras de telefonia celular no Brasil com 24 Milhões de assinantes com dados vazados
- 2022 – Banco com 22 milhões de contas de clientes que tiveram dados comprometidos.
Porém você pode pensar: “Isso é problema apenas no Brasil…” A resposta definitivamente é não! Empresas como Facebook, Instagram, Equifax, T-Mobile, Verizon, Paypal e outras gigantes do mundo digital, somam cerca de 1 bilhão de pessoas com dados comprometidos.
Como foi dito anteriormente: “Sim, vários negócios orientados por APIs estão em risco!”.
Práticas para Proteger suas APIs
No mercado temos duas práticas de proteção de APIs que são as mais populares:
- Proteção feita através de motores de Inteligência Artificial (IA)
- Proteção feita através de análise dos contratos de APIs.
Independentemente da abordagem de soluções, o que já está provado é que ferramentas tradicionais não são capazes de proteger de forma efetiva suas APIs, além disto, o desenvolvimento das APIs utiliza práticas de desenvolvimento ágil, que pode facilitar muito a forma como você pode proteger suas APIs, vamos agora saber mais sobre estas suas abordagens.
Inteligência Artificial
Ferramentas que seguem esta abordagem tem a vantagem de serem adicionadas as infraestruturas de forma mais rápida, entretanto, a possibilidade de falsos positivos é enorme, e isto se dá muitas vezes, como dito anteriormente: A falta de contexto quando o caso é API. Além disso, a descoberta de um problema já em produção, de acordo com o NIST tem um custo de correção 30x quando levado em consideração ao custo de desenvolvimento, se comparados as fases de desenvolvimento e testes, onde possuem os custos de 5x a 10x do custo inicial .
Analogia para entendimento
Fazendo a analogia de segurança, quando comparamos nossos recursos a serem protegidos como uma casa, existem mecanismos que funcionam como grades, cadeados etc, que servem para proteção, mas que sim, são passíveis de falhas.
Proteção de acordo com os contratos das APIs
Rezam as boas práticas que as APIs devem ter um contrato, estes conhecidos como: contratos Swagger e Open API Spec(OAS). Estes, por sua vez, servem para descrever as operações e dados da API em questão, ou seja, tudo que a API deve fazer e como estão descritos nesses documentos.
Com isto em mente, é possível implementar o Modelo Positivo de Segurança, que consiste na capacidade de aceitar somente operações e dados descritos neste contrato, e tudo, absolutamente tudo que estiver fora deste contrato será rechaçado. Desta maneira, a redução de falso-positivos é reduzida drasticamente, fazendo com que as API possam ter uma proteção mais efetiva.
Analogia para entendimento
Fazendo a analogia do cartão de embarque no aeroporto, apenas serão permitidos no avião, aqueles que possuem as credenciais(cartão) e ainda provem que eles são eles mesmos, o que é comparado com a lista de passageiros esperados. Qualquer outra pessoa, sem o cartão de embarque específico, ou de outro voo, serão barrados no embarque em questão, não existe desta forma “achismo” ou potenciais pontos de falhas, dadas as diversas conferências que existem.
Usando essa abordagem de melhorar, testar e proteger com base no contrato, é possível então levar em consideração todo o ciclo de desenvolvimento das APIs. E esta é a abordagem da 42Crunch:
A abordagem da 42Crunch parte do princípio de empoderamento de todos os times envolvidos no desenvolvimento e lançamento à produção das APIs.
Para Desenvolvimento
Para os desenvolvedores, é disponibilizado de forma gratuita uma extensão para Visual Studio Code, IntelliJ e Eclipse, e com esta extensão é possível ajudar o desenvolvedor a verificar o Score de segurança e vulnerabilidades das APIs. Em algumas investigações de APIs de seguradoras que são abertas, já capturamos APIs com o Score de 18 (0 a 100), ou seja, estas API possuem inúmeros pontos de vulnerabilidades:
Com esta extensão é possível identificar:
- Vulnerabilidade
- Possíveis pontos que podem ser explorados
- Como remediar
Esta extensão não analisa o código fonte (linguagem de programação) e sim, apenas o contrato. Por este motivo, este componente não substitui ferramentas como SonarQube, Veracode etc.
Para o DevOps 1: Análise de Score do contrato nas etapas de CI/CD
Caso o desenvolvedor tente “commitar” um contrato que o Score não esteja de acordo com o mínimo aceitável, (por exemplo: 85%), automaticamente o processo de execução do pipeline vai devolver pros desenvolvedores a negativa da execução.
Para o DevOps 2: Análise de Conformidade
Automaticamente a plataforma irá criar testes automáticos que realizarão chamadas no Backends com dados e tipos de chamadas exatamente desconformes ao contrato Swagger/OAS para verificar o comportamento do Backend, por exemplo:
| Teste Automatico | Resultado Esperado | Resultado Retornado | Conclusão |
|---|---|---|---|
| Envio de um valor string para um atributo que aceita apenas numeral(moeda) | Se houver erro de dados: Envio : HTTP 409 JSON: Tipo_erro: “cliente” Msg: “Erro de formatação de dados” |
HTTP 500 StackTraceException:….. |
O Backend não está em conformidade com o contrato |
| Envio de um valor string para um atributo que aceita apenas numeral(moeda) | Se houver erro de dados: Envio : HTTP 409 JSON: {“tipo_erro”: “cliente” “msg”: “Erro de formatação de dados” |
HTTP 201 Executado com sucesso. |
O Backend não está em conformidade com o contrato |
Estes tipos de testes, de acordo com as expectativas do contrato, são extremamente difíceis de serem executados de forma manual, ou mesmo pelos desenvolvedores e testadores, desta forma, a plataforma automaticamente poderá gerar os testes necessários, e mais uma vez, fazer com que o desenvolvedor possa corrigir eventuais erros na camada de backend, que são expostas exatamente pelo contrato Swagger/OAS.
Para Ambiente de Produção
A 42Crunch entrega um componente novo na infraestrutura que é o API Firewall, este por sua vez, analisa a requisição do cliente e as respostas dos backends, se estas não forem de acordo com as permitidas no contrato Swagger, automaticamente serão bloqueadas, notificando a equipe de operação e fazendo com que a camada de consumo, sendo um usuário malicioso ou não, receba o mínimo de informações, fazendo com que a integridade de dados de negócios seja preservada.
Desafio das Empresas
Possuir os contratos Swagger/OAS pode ser uma tarefa desafiadora, uma vez que muitas empresas não se atentaram para estes artefatos, muitas vezes sendo gerados pelos backends de forma automática, o que gera inúmeras discrepâncias nos quesitos de segurança. Para ajudar neste aspecto, a 42Crunch está trabalhando em um novo componente para lançamento no segundo semestre de 2022.
Conclusão
Quando o tema é proteção de APIs, estamos abordando um assunto extremamente novo, há muita pesquisa sobre boas práticas para aprimorar a segurança de APIs e, para deixar alguns resumos:
- Componentes tradicionais podem não ser suficientes para proteger suas APIs;
- Soluções existentes não suportam todos os pontos de ataques;
- Abordagem de proteção de APIs com base em Inteligência Artificial podem gerar ainda inúmeros falsos positivos;
- O modelo Shift-Left/Shield Right da 42Crunch, aborda todas as fases de desenvolvimento das APIs, e protege as APIs reduzindo de forma drástica a geração de falsos positivos.
Se você quiser conversar sobre os assuntos explorados aqui, por favor, entre em contato conosco através do formulário: https://42crunch.com/request-demo/
