{"id":5140,"date":"2023-07-04T16:23:54","date_gmt":"2023-07-04T19:23:54","guid":{"rendered":"https:\/\/base4sec.com\/nao-categorizado\/guia-de-owasp-para-apis-2023\/"},"modified":"2025-02-26T08:55:52","modified_gmt":"2025-02-26T11:55:52","slug":"guia-de-owasp-para-apis-2023","status":"publish","type":"post","link":"https:\/\/base4sec.com\/pt-br\/technical-pt-br\/guia-de-owasp-para-apis-2023\/2023\/07\/04\/","title":{"rendered":"Guia OWASP para APIs 2023"},"content":{"rendered":"
\n

Como desenvolvedores e\/ou respons\u00e1veis pela seguran\u00e7a de uma empresa, aplicativo, informa\u00e7\u00e3o e um longo etc., devemos ser capazes de definir o limite do certo e do errado ao construir e projetar suas arquiteturas. Muitas vezes acontece que no processo esquecemos de levar em conta os erros mais comuns cometidos por outros desenvolvedores ou, quando \u00e9 diferente disso, esquecemos tamb\u00e9m os principais interesses dos atacantes. Se tiv\u00e9ssemos que nos manter atualizados por conta pr\u00f3pria, seria uma tarefa tit\u00e2nica, pois as vulnerabilidades e os interesses dos atacantes por novos horizontes t\u00eam uma taxa de varia\u00e7\u00e3o exponencial.<\/p>\n

Isso levanta uma s\u00e9rie de quest\u00f5es quando se trata de propor um design seguro para um aplicativo da Web, servi\u00e7o da Web e\/ou aplicativo m\u00f3vel; Como nos mantemos atualizados, como lidamos com essa onda de not\u00edcias sem nos esquecermos do que \u00e9 mais importante? Poder\u00edamos facilmente dizer que o mais conveniente seria fazer uma lista das vulnerabilidades mais conhecidas com base na experi\u00eancia pessoal, mas a\u00ed estar\u00edamos levando em conta apenas uma \u00fanica vis\u00e3o da situa\u00e7\u00e3o, embora seja desej\u00e1vel que as empresas tenham um hist\u00f3rico de vulnerabilidades ou falhas anteriores para poder aplic\u00e1-las \u00e0 melhoria cont\u00ednua, tamb\u00e9m \u00e9 verdade que esse hist\u00f3rico ser\u00e1 baseado em um \u00fanico tipo de arquitetura e\/ou um \u00fanico tipo de aplicativo. No curto prazo, isso pode n\u00e3o ter impacto no n\u00edvel da empresa, mas se a empresa estiver constantemente imersa em processos de inova\u00e7\u00e3o, como deveria estar, ela sempre se encontrar\u00e1 no dilema de mudar constantemente a arquitetura e propor melhorias aos processos usuais desenvolvidos diariamente, levando-a a implementar novas funcionalidades e novas tecnologias que poderiam estar em risco sob a perspectiva desse hist\u00f3rico (baseado em uma arquitetura obsoleta).<\/p>\n

\u00c9 nesse ponto que temos de embaralhar e dar as cartas novamente, colocando-as em uma ordem alternativa que proporcione novos pontos de vista. Por que investir esfor\u00e7os na elabora\u00e7\u00e3o de estat\u00edsticas e na compila\u00e7\u00e3o de registros hist\u00f3ricos se pode haver algu\u00e9m que tenha feito a mesma coisa antes, mas n\u00e3o apenas com refer\u00eancia a uma arquitetura espec\u00edfica, mas tamb\u00e9m a muitas situa\u00e7\u00f5es que ocorreram em diferentes campos?<\/p>\n

Esse \u00e9 o caso do\u00a0OWASP, (Open Worldwide Application Security Project<\/b>). Um projeto que surgiu da necessidade de destacar os interesses mais comuns dos invasores com base nos erros que os desenvolvedores cometem ao longo do ciclo de desenvolvimento de software, a comunidade\u00a0OWASP<\/b>\u00a0\u00e9 formada por empresas, organiza\u00e7\u00f5es educacionais e indiv\u00edduos de todo o mundo. Juntos, eles formam uma comunidade de seguran\u00e7a de computadores que trabalha para criar artigos, metodologias, documenta\u00e7\u00e3o, ferramentas e tecnologias que s\u00e3o lan\u00e7adas e podem ser usadas gratuitamente por qualquer pessoa. Atualizando as principais tend\u00eancias, como consequ\u00eancia dos aprimoramentos existentes nos processos de desenvolvimento seguro. Essa organiza\u00e7\u00e3o, que nasceu focada em erros associados a aplicativos da Web, tem hoje v\u00e1rias vers\u00f5es, tipificando as vulnerabilidades mais exploradas e agrupando-as de acordo com a natureza do aplicativo. Atualmente, temos\u00a0o OWASP Web, o OWASP Mobile, e o OWASP API<\/b>, que ser\u00e3o detalhados neste artigo:<\/p>\n

OWASP – API 2023<\/span><\/p>\n

Um elemento fundamental da inova\u00e7\u00e3o no mundo atual orientado por aplicativos \u00e9 a interface de programa\u00e7\u00e3o de aplicativos (API). De bancos, varejo, transporte a IoT, ve\u00edculos aut\u00f4nomos e cidades inteligentes, as APIs s\u00e3o uma parte fundamental dos aplicativos m\u00f3veis, SaaS e da Web modernos e, como s\u00e3o comumente encontradas no n\u00edvel do cliente, est\u00e3o se tornando um alvo principal para os invasores quando s\u00e3o descuidados em sua implementa\u00e7\u00e3o.<\/p>\n

Embora o conceito de uma API seja simples, um servi\u00e7o que fornece um recurso e uma interface do outro lado que consome os v\u00e1rios recursos, conforme mostrado na imagem; a maioria dos desenvolvedores pula o processo de proteg\u00ea-los, talvez por uma falsa sensa\u00e7\u00e3o de seguran\u00e7a que os leva a pensar que um invasor, sem saber como funciona, n\u00e3o ter\u00e1 como alvo esses servi\u00e7os porque eles est\u00e3o fora da superf\u00edcie de ataque. Na realidade, o oposto \u00e9 verdadeiro.<\/p>\n

<\/center><\/p>\n
<\/h5>\n

Veja a seguir as 10 vulnerabilidades mais frequentes nessa \u00e1rea:<\/p>\n

API1 – Broken Object Level Authorization<\/span><\/p>\n

A autoriza\u00e7\u00e3o no n\u00edvel do objeto \u00e9 um mecanismo de controle de acesso, geralmente implementado no n\u00edvel do c\u00f3digo, respons\u00e1vel por validar que um usu\u00e1rio acesse somente os objetos que ele tem permiss\u00e3o para acessar. Supondo que um usu\u00e1rio apresente suas credenciais \u00e0 interface hospedada no telefone e depois queira acessar outro recurso fornecido pelo servi\u00e7o, como segue:<\/p>\n

<\/center><\/p>\n
Se for retorndo ao sistema qualquer objeto n\u00e3o relacionado \u00e0s suas credenciais e essa prote\u00e7\u00e3o falhar, estaremos na presen\u00e7a de uma autoriza\u00e7\u00e3o de n\u00edvel de objeto quebrada, de modo que um invasor poder\u00e1 acessar facilmente qualquer objeto.<\/h5>\n

<\/center><\/p>\n
<\/h5>\n

API2 – Broken Authentication<\/span><\/p>\n

Essa falha, comum tamb\u00e9m em aplicativos da Web, pode se manifestar em v\u00e1rias vulnerabilidades porque, quando nos deparamos com um endpoint de API, h\u00e1 um desafio inicial para consumir a API e come\u00e7ar a trocar recursos.<\/p>\n

H\u00e1 v\u00e1rios casos em que isso pode ocorrer:<\/p>\n