- \n
- Open Finance\/ Open Banking<\/li>\n
- Open Insurance<\/li>\n
- In\u00edcio do Open Health<\/li>\n
- Etc<\/li>\n<\/ul>\n
Estas regulamenta\u00e7\u00f5es, que possuem um car\u00e1ter fidedigno de propiciar o empoderamento das pessoas como o centro de tudo, s\u00e3o elas quem decidir\u00e3o quais seus dados ser\u00e3o compartilhados, al\u00e9m da forma, e claro: Com o direito de revogar a qualquer momento os usos destas informa\u00e7\u00f5es.<\/p>\n
Os epis\u00f3dios de vazamento de dados j\u00e1 est\u00e3o presentes na nossa regi\u00e3o desde o fim de 2019, onde 2 empresas de telefonia m\u00f3vel tiveram dados vazados atrav\u00e9s da vulnerabilidade classificada pela OWASP API Top 10 como BOLA- Broken Object Level Authorization<\/i> (Objeto\u00a0 de n\u00edvel de autoriza\u00e7\u00e3o corrompido), veja a defini\u00e7\u00e3o na pr\u00e1tica:<\/p>\n
\u201d API1:2019 Autoriza\u00e7\u00e3o de n\u00edvel de objeto quebrado<\/p>\n
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\u00edvel de acesso das informa\u00e7\u00f5es de um requisitante. As verifica\u00e7\u00f5es de autoriza\u00e7\u00e3o de n\u00edvel de objeto devem ser consideradas em todas as fun\u00e7\u00f5es que acessam uma fonte de dados usando a entrada do usu\u00e1rio.\u201d<\/p>\n
Para ilustrar este cen\u00e1rio, vamos observar a imagem abaixo:<\/p>\n
![\"\"](\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/07\/Bola-API-Attack-Flow-1024x263-1.png\")
<\/p>\n<\/p>\n
Figura 1 \u2013 Fluxo de execu\u00e7\u00e3o de um ataque BOLA<\/p>\n
Imagine uma aplica\u00e7\u00e3o Web, Mobile ou at\u00e9 ChatBot (canal cliente), quando uma requisi\u00e7\u00e3o \u00e9 disparada com destino aos backends (endpoints, servi\u00e7os), uma sequ\u00eancia de eventos acontece, vamos ent\u00e3o explicar cada uma delas:<\/p>\n
- \n
- O canal cliente envia um payload (envelope com as informa\u00e7\u00f5es, cabe\u00e7alhos HTTP, endere\u00e7o) com o destino a um determinado backend. Neste caso, imagine que a requisi\u00e7\u00e3o foi a seguinte:\n
- \n
- http:\/\/minhaapi.empresa.com.br\/planos-comprados\/<\/a>12345689000 \u2013 Onde o n\u00famero no final da URL representa o CPF do cliente. Do ponto de vista funcional, at\u00e9 a\u00ed nenhum problema, milhares de APIs t\u00eam esse comportamento.<\/li>\n
- O cliente fict\u00edcio aqui nesta chamada com o CPF 123456789000 se chama Johnny Walker\u00a0<\/i><\/li>\n<\/ol>\n<\/li>\n
- J\u00e1 dando um spoiler<\/i>: Se voc\u00ea usa HTTP Basic ou apenas chaves de acesso, voc\u00ea j\u00e1 est\u00e1 com a seguran\u00e7a comprometida, o ideal seria voc\u00ea enviar um Token JWT (JSON Web Tokens<\/i>), pois estes lhe permitem trafegar informa\u00e7\u00f5es de usu\u00e1rios mais seguras, o token pode ser gerado no momento da requisi\u00e7\u00e3o e este \u00e9 v\u00e1lido, \u00e0s vezes por um per\u00edodo determinado, para facilitar a intera\u00e7\u00e3o com o canal cliente.<\/li>\n
- O Firewall ir\u00e1 validar a requisi\u00e7\u00e3o, que parece sem problemas.<\/li>\n
- A camada de WAF (Web Application Firewall) tamb\u00e9m n\u00e3o v\u00ea nada de errado, pois os WAFs s\u00e3o fundamentais para prote\u00e7\u00e3o de aplica\u00e7\u00f5es, mas falham no entendimento do contexto <\/b>das requisi\u00e7\u00f5es para definirem o que \u00e9 fidedigno ou n\u00e3o.<\/li>\n
- O API Gateway por sua vez, de acordo com Chris Richardson: implementa um padr\u00e3o de Microsservi\u00e7o (https:\/\/microservices.io\/patterns\/apigateway.html<\/a>), que em sua grande maioria \u00e9 um produto, que far\u00e1 o seu papel exatamente como o figurino manda:\n
- \n
- A requisi\u00e7\u00e3o tem um Token? Sim<\/li>\n
- Este token \u00e9 v\u00e1lido de acordo com o provedor de identidade e chaves (Issuer) ? Sim<\/li>\n
- A quantidade de requisi\u00e7\u00f5es est\u00e1 dentro do esperado deste consumidor (throttling)? Sim<\/li>\n
- O tempo de resposta est\u00e1 OK (rate limit) ? Sim<\/li>\n
- Ent\u00e3o pode ir at\u00e9 o Backend e executar a instru\u00e7\u00e3o.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Essa \u00e9 cadeia da execu\u00e7\u00e3o, 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\u00e1 sendo passada no endere\u00e7o da chamada (URL), desta forma o que acontece quando:<\/p>\n
- \n
- Com um Token JWT v\u00e1lido (o mais seguro e recomend\u00e1vel)<\/li>\n
- Trocando o CPF<\/b> na requisi\u00e7\u00e3o de 123456789000<\/i>, que pertence a Johnny Walker, o que acontecer\u00e1 se o CPF<\/b> informado for: 98765432100<\/i>, que pertence a Ginger Roger?<\/li>\n
- Resposta<\/b>: Os dados de Ginger ser\u00e3o obtidos sem problema, pois se o tempo entre uma requisi\u00e7\u00e3o e outra n\u00e3o levantar suspeitas, com o Token v\u00e1lido, todos os envolvidos na requisi\u00e7\u00e3o ilustrada na Figura 1, v\u00e3o deixar com que esta e outras requisi\u00e7\u00f5es tamb\u00e9m sejam executadas, resultando num vazamento de dados em massa.<\/li>\n<\/ol>\n
O problema acima aconteceu nos seguintes casos (preservando nomes das empresas em casos \u00e9ticos):<\/p>\n
- \n
- 2019 \u2013 Uma das maiores operadoras de tv a cabo e telefonia m\u00f3vel no Brasil com 8 milh\u00f5es de assinantes que tiveram dados vazados.<\/li>\n
- 2019 \u2013 Uma das maiores operadoradoras de telefonia celular no Brasil com 24 Milh\u00f5es de assinantes com dados vazados<\/li>\n
- 2022 \u2013 Banco com 22 milh\u00f5es de contas de clientes que tiveram dados comprometidos.<\/li>\n<\/ul>\n
Por\u00e9m voc\u00ea pode pensar: \u201cIsso \u00e9 problema apenas no Brasil\u2026\u201d A resposta definitivamente \u00e9 n\u00e3o! Empresas como Facebook, Instagram, Equifax, T-Mobile, Verizon, Paypal e outras gigantes do mundo digital, somam cerca de 1 bilh\u00e3o de pessoas com dados comprometidos.<\/p>\n
Como foi dito anteriormente: \u201cSim, v\u00e1rios neg\u00f3cios orientados por APIs est\u00e3o em risco!\u201d.<\/p>\n
Pr\u00e1ticas para Proteger suas APIs<\/h2>\n
No mercado temos duas pr\u00e1ticas de prote\u00e7\u00e3o de APIs que s\u00e3o as mais populares:<\/p>\n
- \n
- Prote\u00e7\u00e3o feita atrav\u00e9s de motores de Intelig\u00eancia Artificial (IA)<\/li>\n
- Prote\u00e7\u00e3o feita atrav\u00e9s de an\u00e1lise dos contratos de APIs.<\/li>\n<\/ul>\n
Independentemente da abordagem de solu\u00e7\u00f5es, o que j\u00e1 est\u00e1 provado \u00e9 que ferramentas tradicionais n\u00e3o s\u00e3o capazes de proteger de forma efetiva suas APIs, al\u00e9m disto, o desenvolvimento das APIs utiliza pr\u00e1ticas de desenvolvimento \u00e1gil, que pode facilitar muito a forma como voc\u00ea pode proteger suas APIs, vamos agora saber mais sobre estas suas abordagens.<\/p>\n
Intelig\u00eancia Artificial<\/strong><\/h3>\n
Ferramentas que seguem esta abordagem tem a vantagem de serem adicionadas as infraestruturas de forma mais r\u00e1pida, entretanto, a possibilidade de falsos positivos \u00e9 enorme, e isto se d\u00e1 muitas vezes, como dito anteriormente: A falta de contexto quando o caso \u00e9 API<\/i>. Al\u00e9m disso, a descoberta de um problema j\u00e1 em produ\u00e7\u00e3o, de acordo com o NIST tem um custo de corre\u00e7\u00e3o 30x quando levado em considera\u00e7\u00e3o ao custo de desenvolvimento, se comparados as fases de desenvolvimento e testes, onde possuem os custos de 5x a 10x do custo inicial .<\/p>\n
![\"\"](\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/07\/Relative-Cost-Of-Fixing-A-Flaw-in-the-development-lifecycle-768x579-1.png\")
<\/p>\n<\/p>\n
Analogia para entendimento<\/strong><\/p>\n
Fazendo a analogia de seguran\u00e7a, quando comparamos nossos recursos a serem protegidos como uma casa, existem mecanismos que funcionam como grades, cadeados etc, que servem para prote\u00e7\u00e3o, mas que sim, s\u00e3o pass\u00edveis de falhas.<\/p>\n
Prote\u00e7\u00e3o de acordo com os contratos das APIs<\/h3>\n
Rezam as boas pr\u00e1ticas 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\u00e7\u00f5es e dados da API em quest\u00e3o, ou seja, tudo que a API deve fazer e como est\u00e3o descritos nesses documentos.<\/p>\n
Com isto em mente, \u00e9 poss\u00edvel implementar o Modelo Positivo de Seguran\u00e7a, <\/i><\/b>que consiste na capacidade de aceitar somente opera\u00e7\u00f5es e dados descritos neste contrato, e tudo, absolutamente tudo que estiver fora deste contrato ser\u00e1 recha\u00e7ado. Desta maneira, a redu\u00e7\u00e3o de falso-positivos \u00e9 reduzida drasticamente, fazendo com que as API possam ter uma prote\u00e7\u00e3o mais efetiva.<\/p>\n
Analogia para entendimento<\/strong><\/p>\n
Fazendo a analogia do cart\u00e3o de embarque no aeroporto, apenas ser\u00e3o permitidos no avi\u00e3o, aqueles que possuem as credenciais(cart\u00e3o) e ainda provem que eles s\u00e3o eles mesmos, o que \u00e9 comparado com a lista de passageiros esperados. Qualquer outra pessoa, sem o cart\u00e3o de embarque espec\u00edfico, ou de outro voo, ser\u00e3o barrados no embarque em quest\u00e3o, n\u00e3o existe desta forma \u201cachismo\u201d ou potenciais pontos de falhas, dadas as diversas confer\u00eancias que existem.<\/p>\n
Usando essa abordagem de melhorar, testar e proteger com base no contrato, \u00e9 poss\u00edvel ent\u00e3o levar em considera\u00e7\u00e3o todo o ciclo de desenvolvimento das APIs. E esta \u00e9 a abordagem da 42Crunch:<\/p>\n
![\"\"](\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/07\/42Crunch-process-1024x267-1.png\")
<\/p>\n<\/p>\n
A abordagem da 42Crunch parte do princ\u00edpio de empoderamento de todos os times envolvidos no desenvolvimento e lan\u00e7amento \u00e0 produ\u00e7\u00e3o das APIs.<\/p>\n
![\"\"](\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/07\/42Crunch-platform-in-the-SDLC.png\")
<\/p>\n<\/p>\n
Para Desenvolvimento<\/strong><\/p>\n
Para os desenvolvedores, \u00e9 disponibilizado de forma gratuita uma extens\u00e3o para Visual Studio Code, IntelliJ e Eclipse, e com esta extens\u00e3o \u00e9 poss\u00edvel ajudar o desenvolvedor a verificar o Score de seguran\u00e7a e vulnerabilidades das APIs. Em algumas investiga\u00e7\u00f5es de APIs de seguradoras que s\u00e3o abertas, j\u00e1 capturamos APIs com o Score de 18 (0 a 100), ou seja, estas API possuem in\u00fameros pontos de vulnerabilidades:<\/p>\n
![\"\"](\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/07\/42Crunch-OpenAPI-Editor.png\")
<\/p>\n<\/p>\n
Com esta extens\u00e3o \u00e9 poss\u00edvel identificar:<\/p>\n
- \n
- Vulnerabilidade<\/li>\n
- Poss\u00edveis pontos que podem ser explorados<\/li>\n
- Como remediar<\/li>\n<\/ul>\n
Esta extens\u00e3o n\u00e3o analisa o c\u00f3digo fonte (linguagem de programa\u00e7\u00e3o) e sim, apenas o contrato. Por este motivo, este componente n\u00e3o substitui<\/b> ferramentas como SonarQube, Veracode etc.<\/p>\n
Para o DevOps 1: An\u00e1lise de Score do contrato nas etapas de CI\/CD\u00a0<\/strong><\/h3>\n
Caso o desenvolvedor tente \u201ccommitar\u201d um contrato que o Score n\u00e3o esteja de acordo com o m\u00ednimo aceit\u00e1vel, (por exemplo: 85%), automaticamente o processo de execu\u00e7\u00e3o do pipeline vai devolver pros desenvolvedores a negativa da execu\u00e7\u00e3o.<\/p>\n
Para o DevOps 2: An\u00e1lise de Conformidade\u00a0<\/strong><\/h3>\n
Automaticamente a plataforma ir\u00e1 criar testes autom\u00e1ticos que realizar\u00e3o chamadas no Backends com dados e tipos de chamadas exatamente desconformes ao contrato Swagger\/OAS para verificar o comportamento do Backend, por exemplo:<\/p>\n
\n\n
\n \nTeste Automatico<\/th>\n Resultado Esperado<\/th>\n Resultado Retornado<\/th>\n Conclus\u00e3o<\/th>\n<\/tr>\n<\/thead>\n \n Envio de um valor string para um atributo que aceita apenas numeral(moeda)<\/td>\n Se houver erro de dados:
\nEnvio : HTTP 409
\nJSON:
\nTipo_erro: “cliente”
\nMsg: “Erro de formata\u00e7\u00e3o de dados”<\/td>\nHTTP 500
\nStackTraceException:…..<\/td>\nO Backend n\u00e3o est\u00e1 em conformidade com o contrato<\/td>\n<\/tr>\n \n Envio de um valor string para um atributo que aceita apenas numeral(moeda)<\/td>\n Se houver erro de dados:
\nEnvio : HTTP 409
\nJSON:
\n{“tipo_erro”: “cliente”
\n“msg”: “Erro de formata\u00e7\u00e3o de dados”<\/td>\nHTTP 201
\nExecutado com sucesso.<\/td>\nO Backend n\u00e3o est\u00e1 em conformidade com o contrato<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n <\/p>\n
Estes tipos de testes, de acordo com as expectativas do contrato, s\u00e3o extremamente dif\u00edceis de serem executados de forma manual, ou mesmo pelos desenvolvedores e testadores, desta forma, a plataforma automaticamente poder\u00e1 gerar os testes necess\u00e1rios, e mais uma vez, fazer com que o desenvolvedor possa corrigir eventuais erros na camada de backend, que s\u00e3o expostas exatamente pelo contrato Swagger\/OAS.<\/p>\n
Para Ambiente de Produ\u00e7\u00e3o<\/strong><\/p>\n
A 42Crunch entrega um componente novo na infraestrutura que \u00e9 o API Firewall, este por sua vez, analisa a requisi\u00e7\u00e3o do cliente e as respostas dos backends, se estas n\u00e3o forem de acordo com as permitidas no contrato Swagger, automaticamente ser\u00e3o bloqueadas, notificando a equipe de opera\u00e7\u00e3o e fazendo com que a camada de consumo, sendo um usu\u00e1rio malicioso ou n\u00e3o, receba o m\u00ednimo de informa\u00e7\u00f5es, fazendo com que a integridade de dados de neg\u00f3cios seja preservada.<\/p>\n
Desafio das Empresas<\/strong><\/p>\n
Possuir os contratos Swagger\/OAS pode ser uma tarefa desafiadora, uma vez que muitas empresas n\u00e3o se atentaram para estes artefatos, muitas vezes sendo gerados pelos backends de forma autom\u00e1tica, o que gera in\u00fameras discrep\u00e2ncias nos quesitos de seguran\u00e7a. Para ajudar neste aspecto, a 42Crunch est\u00e1 trabalhando em um novo componente para lan\u00e7amento no segundo semestre de 2022.<\/p>\n
Conclus\u00e3o<\/p>\n
Quando o tema \u00e9 prote\u00e7\u00e3o de APIs, estamos abordando um assunto extremamente novo, h\u00e1 muita pesquisa sobre boas pr\u00e1ticas para aprimorar a seguran\u00e7a de APIs e, para deixar alguns resumos:<\/p>\n
- \n
- Componentes tradicionais podem n\u00e3o ser suficientes para proteger suas APIs;<\/li>\n
- Solu\u00e7\u00f5es existentes n\u00e3o suportam todos os pontos de ataques;<\/li>\n
- Abordagem de prote\u00e7\u00e3o de APIs com base em Intelig\u00eancia Artificial podem gerar ainda in\u00fameros falsos positivos;<\/li>\n
- O modelo Shift-Left\/Shield Right da 42Crunch, aborda todas as fases de desenvolvimento das APIs, e protege as APIs reduzindo de forma dr\u00e1stica a gera\u00e7\u00e3o de falsos positivos.<\/li>\n<\/ul>\n
- Resposta<\/b>: Os dados de Ginger ser\u00e3o obtidos sem problema, pois se o tempo entre uma requisi\u00e7\u00e3o e outra n\u00e3o levantar suspeitas, com o Token v\u00e1lido, todos os envolvidos na requisi\u00e7\u00e3o ilustrada na Figura 1, v\u00e3o deixar com que esta e outras requisi\u00e7\u00f5es tamb\u00e9m sejam executadas, resultando num vazamento de dados em massa.<\/li>\n<\/ol>\n
- O cliente fict\u00edcio aqui nesta chamada com o CPF 123456789000 se chama Johnny Walker\u00a0<\/i><\/li>\n<\/ol>\n<\/li>\n
- http:\/\/minhaapi.empresa.com.br\/planos-comprados\/<\/a>12345689000 \u2013 Onde o n\u00famero no final da URL representa o CPF do cliente. Do ponto de vista funcional, at\u00e9 a\u00ed nenhum problema, milhares de APIs t\u00eam esse comportamento.<\/li>\n
- O canal cliente envia um payload (envelope com as informa\u00e7\u00f5es, cabe\u00e7alhos HTTP, endere\u00e7o) com o destino a um determinado backend. Neste caso, imagine que a requisi\u00e7\u00e3o foi a seguinte:\n