Um guia para iniciantes sobre segurança da interface de programação de aplicativos (API)

Este artigo analisa brevemente o histórico de desenvolvimento da API, seus conceitos básicos, funções, protocolos relacionados e cenários de uso, e se concentra em diferentes elementos de segurança, ameaças, métodos de autenticação e doze boas práticas relacionadas a ela.

De acordo com a história registrada, a primeira API da Web apareceu no final de 1990 com a introdução da solução de automação de vendas da Salesforce. Naquela época, era um recurso aberto acessível a todos. As ferramentas de automação do Salesforce são orientadas por XML. O formato de dados usado para trocar as informações da ferramenta foi posteriormente reconhecido como o padrão SOAP API. Possui especificações de formato de mensagem associadas à permissão ou não de várias solicitações, bem como regras específicas de código. Ou seja, a maioria dos desenvolvedores precisa usar documentos XML manualmente com RPC, além do processamento SOAP necessário para o desenvolvimento e criação da API. Posteriormente, o desenvolvedor precisa interpretar o endpoint da API e publicar o conjunto SOAP nesse endpoint. Este não é apenas o nascimento da API, mas também o início do conceito de SaaS.

Os principais eventos que moldaram as APIs modernas foram a introdução das APIs do Flicker e do Facebook. O Flicker desenvolveu uma plataforma para armazenar imagens digitais por meio da nuvem, que oferece suporte ao compartilhamento de imagens em diferentes plataformas por meio do desenvolvimento de APIs e integra novos serviços de vários recursos de compartilhamento de fotos.

Em 2008, as APIs evoluíram para operar de forma independente e lidar com grandes quantidades de informações interconectadas. Ao lançar uma API, o Twilio facilita para os usuários conectar várias partes de todo o produto, como chamadas e mensagens de texto.

O que são APIs?

Para começar, uma API refere-se a uma interface de programação de aplicativo projetada para permitir a comunicação fluida entre dois aplicativos diferentes. Muitas vezes, é referido como o "intermediário" do aplicativo. Como precisamos proteger os dados mantidos pelos usuários e a integridade do próprio aplicativo, a segurança da API é uma "necessidade justa".

E para desenvolvedores, a API é uma ótima ferramenta. Ele pode trocar informações entre microsserviços e contêineres e permitir uma comunicação rápida. Assim como a integração e a interconexão são importantes para o desenvolvimento de aplicativos, as APIs, de certa forma, impulsionam e aprimoram o design de aplicativos.

As APIs tomam a Internet como uma tempestade

Nos primórdios da Internet, a API, como protocolo proprietário, era frequentemente utilizada em áreas, finalidades ou organizações restritas na rede, possibilitando a comunicação e a computação em diferentes arquiteturas de rede. Após o surgimento da Web 2.0, as ferramentas baseadas na Web surgiram amplamente e as pessoas começaram a usar REST (REpresentational State Transfer Framework), uma especificação de desenvolvimento da comunidade, para construir interfaces de API para aplicativos práticos, como nosso OpenAPI comum.

Na atual era da Web 3.0, as APIs desempenham um papel vital na comunicação entre a IoT e os dispositivos baseados em IA. O paradigma regular de solicitação-resposta das APIs também mudou para uma abordagem orientada a eventos.

casos de uso da API

Como elemento básico para facilitar a troca de informações, a API é amplamente utilizada na área de desenvolvimento de aplicações Web. Atualmente, os casos de uso de API mais usados e importantes no setor são os seguintes:

Aplicativo de página única (SPA)

As APIs REST não apenas aceleram o desenvolvimento de aplicativos de página única, mas também ajudam os aplicativos a colocar todo o conteúdo em uma página para fornecer uma experiência de usuário completa. Durante o desenvolvimento do aplicativo, os programadores podem usar arquivos CSS, JavaScript e HTML predefinidos para iniciar a comunicação entre os servidores da Web. Observe que as estruturas REST são frequentemente usadas para comunicação do lado do servidor e para troca de informações do lado do cliente para certos tipos de estruturas.

As estruturas de API REST comumente usadas para desenvolvimento de SPA incluem: NancyFx, Express.js e ASP.Net WebAPI. Como uma estrutura sem estado, as APIs REST não são incomodadas por clientes que chamam um ou mais servidores para cada solicitação. Portanto, usar a API REST para desenvolvimento de SPA pode melhorar a escalabilidade do aplicativo. Obviamente, isso não apenas reduz o custo de extensão do aplicativo para o desenvolvedor, mas também elimina a necessidade do aplicativo acessar recursos específicos.

No desenvolvimento do SPA, além da documentação da API REST, nenhum outro elemento é vinculado ao cliente e ao servidor. Portanto, essa independência promove flexibilidade no desenvolvimento, teste e implantação de aplicativos. E é exatamente isso que a estrutura dinâmica da Web não pode alcançar.

API pública, B2B de nível empresarial

Chamadas telefônicas, faxes e e-mails têm sido os principais meios de comunicação para operações B2B. No entanto, para atender às necessidades de troca de informações baseadas em IoT, as APIs RESTful podem desempenhar um papel fundamental na automação da comunicação B2B em nível empresarial.

Do ponto de vista do cliente, a publicação de APIs públicas permitirá que as empresas criem aplicativos voltados para o consumidor e maximizem a comunicação com o mundo externo. Ao mesmo tempo, uma vez que a API pública permite que os clientes B2B estendam vários comportamentos baseados no usuário, ela desacopla totalmente os processos de negócios e aprimora a interoperabilidade baseada em máquina sem aumentar o custo.

API privada x serviços de API internos

Usando APIs privadas, os clientes B2B podem reduzir o tempo de lançamento no mercado e acelerar a integração de novos aplicativos e ferramentas sem afunilar os fluxos de trabalho existentes. Ao gerenciar fluxos de trabalho internos, as APIs privadas podem identificar áreas combináveis para reestruturar e modernizar as empresas. E como processo criativo, os modelos de negócios combináveis podem decompor funções complexas em micropartes gerenciáveis. As APIs privadas facilitam o uso estratégico de recursos, permitindo uma comunicação eficiente em todos os níveis da organização.

Isso torna os resultados da análise de inteligência de negócios mais precisos, pois a API interna fornece informações detalhadas sobre várias possíveis causas de falhas operacionais e melhora o tempo de resposta dos componentes do sistema. E depois de usar a API privada, os recursos de colaboração e troca de informações do aplicativo se tornarão mais rápidos e seguros.

malha de serviço

Como um componente da camada de infraestrutura, uma malha de serviço é altamente configurável e de baixa latência. Normalmente, é usado em estruturas de rede para lidar com comunicações internas em grande escala. Com o uso criterioso de grades, os desenvolvedores podem garantir uma troca de informações rápida, segura e confiável para vários aplicativos efêmeros e conteinerizados.

As APIs podem ser usadas para troca de informações em uma malha de serviço. Mas as coisas ficam muito mais complicadas quando o plano de dados da malha entra em contato com cada pacote ou solicitação que passa pelo sistema. Portanto, usar APIs como o Universal Data Plane e o xDS pode simplificar esse tipo de trabalho. Eles podem verificar a integridade do sistema, monitorar seu desempenho, rotear várias solicitações de entrada ou saída, equilibrar o tráfego do sistema de maneira de compartilhamento de carga e descobrir operações incorretas relacionadas à autorização do usuário por meio da descoberta de serviço.

back-end móvel

Como um modelo emergente de entrega de serviços, os back-ends móveis são frequentemente usados no desenvolvimento de soluções de otimização móvel. O modelo de desenvolvimento, conhecido como Mobile Backend as a Service (MBaaS), oferece aos desenvolvedores a liberdade de manter servidores e ferramentas relacionadas a servidores, incluindo componentes como gerenciamento de usuários, notificações por push e plug-ins de login social.

Cada recurso do MBaaS usará um SDK flexível para se conectar ao endpoint da API. Por exemplo, o MBaaS usa tecnologias como Flutter, Unity, Iconic e React Native para desenvolver aplicativos front-end para sistemas operacionais Android e iOS. Ao mesmo tempo, várias APIs da plataforma MBaaS podem trazer automação para desenvolvedores em aspectos como gerenciamento de fluxo de trabalho, atualizações de notificação e planejamento de tarefas.

Além disso, essas APIs podem gerar uma camada de aplicativo para permitir a troca contínua de informações entre vários sistemas e serviços usados. Os desenvolvedores também podem projetar vários serviços baseados em necessidades para clusters de usuários recém-adicionados.

Internet das Coisas (IoT)

Como os dispositivos IoT precisam estar conectados a clientes ou dispositivos de outros usuários da rede para concluir a troca de informações, muitas vezes é inevitável expor as informações trocadas ao usar APIs. Para fazer isso, os desenvolvedores precisam criar aplicativos suficientemente seguros e baseados em contexto que não usem diretamente a IU para interagir com o mundo externo.

A API REST é atualmente a API mais comum usada para cenários do mundo real de dispositivos IoT e troca informações pelo protocolo da Internet. Além disso, a API REST também permite que os desenvolvedores imponham estratégias de autenticação e autorização.

API aos olhos de diferentes pessoas

A diversidade de APIs costuma ser usada em diferentes cenários de aplicativos, e os desenvolvedores com funções diferentes têm entendimentos diferentes sobre APIs.

Desenvolvimento de back-end:

Estrutura: Um plano ou estratégia bem estruturado que define como as operações e os processos funcionam.
Especificação: Um documento baseado no Swagger que descreve funcionalidades como REST ou OpenAPI. Por exemplo, algum tipo de esquema GraphQL relacionado ao conteúdo do Geo PC.
Dados e lógica de negócios: os desenvolvedores de back-end preferem separar dados e lógica entre clientes (por exemplo, aplicativos móveis ou navegadores). Isso beneficiará seu próprio código ou dados, por exemplo, aplicativos de página única e aplicativos móveis podem usar os mesmos dados e API para lidar com várias integrações personalizadas.
Um back-end unificado para dispositivos móveis, web e integração melhora e simplifica o processo de sincronização.

DevOps:

Atenda às especificações do ambiente de produção: por exemplo, se o endpoint retornar erros 502 com frequência, você deve considerar o uso da API para corrigi-lo.
Escalabilidade: se o endpoint precisar escalar para resolver erros 504, você precisará descobrir os microsserviços associados a isso, o melhor fluxo e a direção a seguir para resolver o problema (por exemplo, uma API REST para GraphQL).

Fluxograma de como a API funciona

Segurança:

Novos protocolos: como lidar com firewalls, scanners e outras ferramentas legadas que param de atualizar?
Segurança leste-oeste (leste-oeste, ou seja, entre vários aplicativos de back-end e bancos de dados, diferente do que costumamos dizer sul-norte): Falta um bom monitoramento das comunicações dentro da rede.
Requisitos de conformidade para novos componentes de segurança, rede ou outros componentes de TI.

A importância da segurança da API

Como mencionado anteriormente, API e segurança de API andam de mãos dadas. Essas APIs com pouca segurança são frequentemente expostas e atacadas por hackers. E como as APIs são usadas principalmente para trocar informações, conectar serviços e transmitir dados, uma vez que ocorra um vazamento de dados, isso trará perdas significativas para a empresa.

Vários métodos de autenticação para a API

Antes de conceder acesso aos usuários, é necessário verificar a identidade real de quem está visualizando ou editando os recursos da API para evitar o uso indevido da API.

1. Autenticação baseada em host

Esse processo garante que apenas usuários autenticados possam acessar os recursos implantados no servidor autenticando o host ou servidor. Não precisamos de nenhuma chave ou outra para iniciar o processo. No entanto, o servidor deve ter a capacidade de verificar a chave de login em tempo real para controlar eventos como falsificação de DNS, falsificação de roteamento e falsificação de IP.

A autenticação baseada em host é muito semelhante à RSA no processo e na implementação. Por padrão, não precisamos definir nenhum parâmetro. A autenticação de usuário baseada em host pode ser feita por um administrador criando uma chave privada para o host local ou extraindo uma chave pública para o host local.

2. Autenticação básica

Este é um dos esquemas de autenticação de API mais diretos. Como o cliente envia uma solicitação HTTP com cabeçalhos pré-criados, esse método usa o protocolo e o processo HTTP para solicitar e verificar credenciais, como nome de usuário e senha. Essas verificações geralmente são feitas em um ambiente controlado por navegador.

Compatível com a grande maioria dos navegadores e servidores, os detalhes da credencial usados para esse tipo de autenticação podem ser compartilhados pela rede em texto não criptografado ou simplesmente codificados usando base64. Ele não apenas pode ser executado em vários servidores proxy, mas também pode conceder acesso a recursos que não estão hospedados em um servidor IIS. Devido à falta de proteção criptografada, é vulnerável a ataques como replay.

3、OAuth

Como uma tecnologia de autenticação de API aberta personalizável, o OAuth pode realizar a interação entre aplicativos, servidores e APIs de armazenamento verificando identidades de usuários e definindo padrões de autorização.

Quando alguém faz login no sistema, ele autentica o usuário solicitando um token. Para isso, a pessoa ou criador da solicitação deve encaminhar a solicitação de acesso ao recurso ao servidor de autenticação. O servidor aceitará ou rejeitará a solicitação de acordo com o resultado da verificação.

OAuth é mais seguro do que outros processos, tornando-o a primeira escolha para muitos usuários. Os três elementos principais do OAuth incluem o provedor OAuth (como Google e Facebook), o cliente OAuth (referindo-se ao site/página que hospeda as informações) e o proprietário (referindo-se ao usuário que faz a solicitação de acesso).

4、OAuth 2.0

Uma versão atualizada do OAuth, OAuth 2.0 é um protocolo de gerenciamento de acesso API amplamente utilizado. Suas funções incluem restringir o acesso de clientes API usando serviços HTTP para iniciar aplicativos clientes. Tanto o GitHub quanto o Facebook usam o protocolo em seu código de autenticação para os principais serviços HTTP, eliminando as credenciais do usuário.

Os três elementos principais do OAuth 2.0 são: o usuário que possui os dados, o aplicativo e a própria API. Durante o processo de autenticação, esse método pode resolver facilmente os dados do usuário para usar diferentes recursos. Ele pode ser implantado em aplicativos e dispositivos baseados na Web, em dispositivos móveis e em desktop para fins de autenticação.

5, SAML

Security Assertion Markup Language (SAML) é um processo de API padronizado para autenticação usando tecnologia de logon único. Ele faz a verificação com base nos detalhes fornecidos pelo usuário. Depois de autenticados, os usuários recebem acesso a vários aplicativos ou recursos. Atualmente, SAML 2.0 é a versão comumente usada. É muito semelhante a um ID e pode auxiliar na avaliação da identidade de um usuário.

O que significa segurança de API?

A segurança da API não se concentra apenas na proteção de APIs direta ou indiretamente expostas aos usuários, mas também envolve princípios de segurança de rede, como limitação e limitação de taxa, análise de segurança baseada em identidade e os seguintes conceitos-chave de controle de segurança:

Contrato de API

A API pode ser usada de várias formas e estilos de acordo com diferentes necessidades. Diferentes formas de uso também determinam a segurança da implementação da API.

SABÃO

Simple Object Access Protocol (Simple Object Access Protocol, SOAP) é um protocolo de mensagens e comunicação baseado em XML. O protocolo estende o HTTP e fornece transporte de dados para serviços da Web. Usando este protocolo, podemos facilmente trocar arquivos contendo tudo, ou chamar procedimentos remotamente. Ao contrário de outras estruturas, como CORB, DCOM e Java RMI, toda a mensagem do SOAP é escrita em XML, portanto, é independente da linguagem.

DESCANSAR

Como uma arquitetura padrão da Web baseada no protocolo HTTP, o REST pode usar quatro verbos para cada solicitação HTTP pendente: GET, POST, PUT e DELETE. Para desenvolvedores, a arquitetura RESTful é uma das ferramentas mais fáceis para entender a funcionalidade e o comportamento da API. Isso não apenas torna a arquitetura da API fácil de manter e expandir, mas também facilita o acesso de desenvolvedores internos e externos à API.

gRPC

Como uma estrutura de alto desempenho de software livre, o gRPC aprimora o antigo protocolo Remote Procedure Call (RPC). Ele usa HTTP/2, um protocolo de transferência de quadro binário, que simplifica o processo de comunicação e mensagens entre clientes e serviços de back-end.

O gRPC completamente leve é mais de 8 vezes mais rápido que o JSON. Ele pode chamar o buffer por meio de um protocolo de tecnologia de código aberto e adota um formato de serialização independente de plataforma para mensagens estruturadas. No uso da API, os desenvolvedores podem descobrir os diversos procedimentos que devem ser chamados e avaliar os valores dos parâmetros por meio do gRPC.

Webhook

Webhooks podem enviar mensagens geradas automaticamente de um aplicativo para outro. Em outras palavras, ele pode estabelecer, enviar e buscar comunicação atualizada entre dois aplicativos em tempo real.

Como os webhooks podem conter informações críticas e transmiti-las a um servidor de terceiros, podemos garantir as práticas de segurança relevantes da API realizando autenticação HTTP básica ou autenticação TLS em webhooks.

WebSocket

WebSocket é um protocolo de comunicação bidirecional que pode fornecer um canal de comunicação bidirecional maduro entre o cliente e o servidor, compensando assim as limitações do protocolo HTTP.

O aplicativo cliente pode usar o WebSocket para criar uma solicitação de conexão HTTP e enviá-la ao servidor. Depois que a conexão de comunicação inicial é estabelecida, tanto o cliente quanto o servidor podem usar a conexão TCP/IP atual para transmitir dados e informações de acordo com o protocolo básico da estrutura de mensagens.

XML-RPC

O XML-RPC pode se comunicar entre o WordPress e outros sistemas por meio de um processo de comunicação padronizado. Ele usa HTTP como transporte e XML como processo de codificação. Seu código de trabalho é armazenado no arquivo xmlrpc.php localizado no diretório raiz do site. Disponível como opção padrão no WordPress versão 3.5, o XML-RPC permite que aplicativos móveis interajam perfeitamente com o processo de instalação do WordPress baseado na web.

No entanto, como o xmlrpc.php é capaz de compartilhar detalhes de autenticação para cada solicitação de acesso, ele aumenta as chances de ataques de força bruta e ataques DDoS. Nesse sentido, quando adotamos a API XML-RPC, precisamos aumentar as práticas de segurança relevantes.

JSON-RPC

Para os não iniciados, JSON-RPC é um protocolo RPC ultraleve que pode ser usado para desenvolver APIs baseadas na blockchain Ethereum. Ele usa JSON (RFC4627) como formato de dados básico e tem a capacidade de interpretar e processar várias estruturas e regras de dados. O protocolo pode ser usado repetidamente no mesmo soquete.

MQTT

O MQTT é um protocolo de mensagem aprovado pela OASIS, que tem sido amplamente utilizado no campo do desenvolvimento de dispositivos e ferramentas IoT e realiza a troca de informações do tipo HTTP. Por ser tão leve, permite que os desenvolvedores escalem para milhões de dispositivos ao mesmo tempo. Quando se trata de segurança de API, o MQTT não apenas ajuda na criptografia de mensagens, mas também facilita a aplicação de TLS e autenticação.

AMQP

Como um protocolo aberto, o Advanced Message Queuing Protocol (Advanced Message Queuing Protocol, AMQP) estipula o processo de comportamento do provedor de mensagens, que pode ser aplicado à camada de aplicativo para criar um sistema interoperável. Por ser implementado em binário, o protocolo não apenas suporta várias comunicações de middleware orientadas a mensagens, mas também pode garantir a entrega completa de mensagens.

XMPPName

Como um conjunto de tecnologias de fonte gratuita, o XMPP pode ser usado para desenvolver colaboração multipartidária, mensagens instantâneas, bate-papo multipartidário, videochamada e middleware leve. Seus quatro componentes principais incluem: PHP, MySQL, Apache e Perl.

CoAP

Como um padrão IETF definido pela RFC 7252, o CoAP pode ser usado como um protocolo de segurança de API padronizado para restringir aplicativos em dispositivos IoT. Como o CoAP pode suportar comunicação sobre LPWAN, é a melhor escolha para proteger nós de microcontroladores simples. O CoAP funciona na camada TCP/IP e usa o UDP como protocolo de transporte básico.

Segurança de API em implantações na nuvem, no local e híbridas

Avanços em tecnologias como serviços em nuvem, plataformas de integração e gateways de API permitiram que os provedores de API protegessem as APIs de várias maneiras. Pode-se argumentar que o tipo de pilha de tecnologia escolhida para construir uma API tem um impacto direto na segurança da API. Por exemplo, uma grande organização pode usar vários aplicativos com APIs autodesenvolvidas. E no processo de fusão de vários aplicativos, várias ilhas de API podem aparecer. Esses silos geralmente são onde estão os riscos de segurança.

Em um ecossistema heterogêneo, a infraestrutura específica de segurança de API nas ilhas de API pode ser configurada como agentes secundários e de banda lateral, incorporados entre a nuvem e as implantações locais. Por serem altamente portáteis, essas configurações de segurança permitem que qualquer tecnologia preparada para o futuro transfira ou extraia facilmente APIs.

Camada de segurança da API

A camada de segurança da API deve ter várias camadas. Cada camada executa suas próprias funções para fornecer proteção de segurança máxima.

descoberta de API

A primeira camada de segurança da API é a descoberta da API, afinal você não pode se proteger se não conhecer os alvos e ameaças. Conforme mencionado anteriormente, os silos de API são o problema número um que impede que o pessoal de segurança descubra as APIs. Devido à falta de visibilidade da API, isso prejudicará diretamente o gerenciamento dos direitos de acesso à API.

As Shadow APIs são a segunda maior barreira à visibilidade da API. Quando uma API é desenvolvida como parte de um aplicativo, geralmente é conhecida apenas pelos membros da equipe de desenvolvimento, enquanto o pessoal de segurança ignora os detalhes de implementação dessas "APIs de sombra".

O terceiro obstáculo é o controle de versão da API. Durante o ciclo de vida de um aplicativo de software, sua API geralmente precisa ser iterada continuamente. No entanto, a nova versão da API geralmente não pode substituir a versão antiga de forma imediata e abrangente. Como as versões do aplicativo do cliente não são as mesmas, a versão antiga da API precisa continuar em execução por um período de tempo de acordo com o requisito de compatibilidade com versões anteriores. E então, gradativamente, eles vão saindo do campo de visão da equipe de desenvolvimento, ou até mesmo esquecidos. Tudo isso aconteceu silenciosamente.

Portanto, a descoberta de API é, na verdade, uma corrida entre o provedor de API e o invasor. Se os provedores puderem descobrir os tipos de APIs acima antes dos invasores, eles poderão extrair metadados de tráfego de API de gateways de API, balanceadores de carga e tráfego de rede direto em linha e, por meio de mecanismos especializados, produzir um relatório de lista de API eficaz para comparação com o catálogo de API disponível na camada de gerenciamento da API.

As 10 principais ameaças de segurança da OWASP à segurança da API

Falhas na autorização no nível do objeto API1:2019

Normalmente, os endpoints da API exploram o plano de controle de acesso descobrindo os identificadores dos objetos processados. Precisamos verificar as informações fornecidas pelo cliente uma a uma.

Falhas na autenticação do usuário API2:2019

Os invasores costumam usar os tokens obtidos ou as falhas de execução do sistema de verificação para se passar por usuários legítimos e realizar operações ilegais.

API3:2019 Exposição excessiva de dados

Os invasores podem inferir os atributos relevantes de alguns itens por meio de chamadas de API e dados obtidos legalmente e, em seguida, filtrar várias informações úteis.

API4:2019 Recursos insuficientes e limitação atual

Geralmente, a API não impõe restrições de fluxo ou quantidade aos dados que estão sendo chamados. Isso deixa uma oportunidade para os invasores lançarem ataques de captura de recursos, como negação de serviço (DoS).

Falhas na autorização de nível de função API5:2019

Algumas APIs estão incompletas em políticas complexas de controle de acesso e até mesmo com falhas de autorização. Isso permitirá que os invasores obtenham recursos que outros usuários podem chamar por meio de chamadas de função.

API6:2019 alocação de lote

Para melhorar a eficiência, o modelo que fornece informações aos usuários na forma de JSON geralmente fornece atribuição em massa (Mass Assignment) sem triagem de atributos legais com base na lista de permissões específica. Com base nisso, um invasor pode ler cuidadosamente os documentos de suporte para inferir as propriedades do objeto, encontrar diferentes endpoints de API ou descobrir propriedades adicionais na carga útil da solicitação e, em seguida, adulterá-los.

Erro de configuração de segurança API7:2019

Os erros de configuração de segurança geralmente decorrem de design padrão incompleto, orquestração aleatória, armazenamento distribuído aberto, cabeçalhos HTTP incompatíveis, compartilhamento de ativos de origem cruzada (compartilhamento de ativos de origem cruzada, CORS) e a inclusão de aspectos confidenciais, como prompts de mensagem de erro longos para dados.

API8: injeção de 2019

As informações maliciosas de um invasor podem enganar as verificações de entrada, explorar falhas de SQL ou NoSQL, executar comandos maliciosos ou obter informações sem validação adequada.

API9:2019 Gerenciamento inadequado de ativos

As APIs costumam descobrir mais endpoints do que os aplicativos da Web comuns, o que torna ainda mais importante que a documentação que os acompanha seja atualizada adequadamente. Nesse sentido, devemos continuar aprimorando as tabelas relevantes da API e descobrir os endpoints que não foram registrados a tempo.

API10:2019 log e monitoramento insuficientes

A falta de registro e inspeção, combinada com recursos insuficientes de resposta a incidentes, pode colocar as chamadas de API em risco de ataque.

teste de penetração

Os desenvolvedores podem considerar o uso dos dados de teste de API pré-criados do agente Postman para se comunicar diretamente com a API. Ao realizar testes de penetração rápida e repetidamente para APIs, podemos obter relatórios detalhados enquanto reduzimos os custos de teste.

Como o teste de penetração requer proficiência na API de destino e até mesmo em todo o sistema, é melhor contratar uma equipe de segurança qualificada ou usar ferramentas de código aberto para simular ataques contra a API. Por meio de testes de penetração regulares e contínuos, os desenvolvedores poderão encontrar a correção em tempo hábil, consistente com o nível de proteção da API.

12 práticas recomendadas para segurança de API

A partir da discussão acima, podemos ver que a segurança da API é crucial para o desenvolvimento de aplicativos centrados em dados. Vamos discutir as práticas recomendadas de segurança para diferentes tipos e estágios de APIs.

1. Use criptografia

Para evitar ataques de cracking, precisamos usar o protocolo de criptografia TLS para as APIs usadas para comunicação interna e externa e implantar criptografia de ponta a ponta.

2. Certificação API

Conforme mencionado anteriormente, a autenticação garante que a API não possa ser usada diretamente por estranhos. Ao mesmo tempo, por meio da chave API ou autenticação de acesso, podemos rastrear as chamadas dos recursos da API. Claro, tais medidas de segurança também aumentam a dificuldade de implementação do sistema.

3. Faça pleno uso de OAuth e OpenID Connect

A combinação de OAuth e OpenID Connect pode assumir total responsabilidade pela autenticação e/ou autorização da API. Por exemplo, no processo de autorização, tanto os consumidores quanto os provedores da API não realizam operações de autorização diretamente, mas usam OAuth como um protocolo de delegação para adicionar uma camada de proteção básica à API e, com base nisso, usam o padrão OpenID Connect como uma camada de identidade adicional, usando tokens de ID para estender OAuth2.0.

4. Especialistas em segurança

Com tantas práticas de segurança de API para escolher, você pode sofrer de "síndrome de escolha". Neste ponto, especialistas em segurança experientes podem orientá-lo na construção de uma sólida postura de segurança de API com um sistema antivírus adequado e um servidor ICAP (Internet Content Adaptation Protocol).

5. Monitoramento, auditoria e registro contínuos

Como diz o ditado, é melhor prevenir do que remediar. Podemos definir os indicadores a serem monitorados e registrados no início do design da API; e durante o uso dos serviços de aplicativos, podemos rastrear as interações da API por meio de painéis apropriados e revisar registros relevantes e mensagens de erro em tempo hábil. Ao mesmo tempo, no processo subsequente de depuração e atualização de versão, não se esqueça de sincronizar todas as APIs.

6. Compartilhando apenas informações limitadas

Lembre-se, quanto menos informações você compartilhar por meio de uma API, menos risco de segurança a própria API representa. Ao mesmo tempo, você também deve garantir que o mínimo de informações possível seja divulgado nas mensagens de erro.

Além disso, usar listas brancas e listas negras de endereços IP é uma ótima maneira de limitar o acesso aos recursos da API. Ele pode garantir que apenas pessoas ou aplicativos autorizados tenham acesso limitado aos recursos da API e mantenha as principais informações na interface ocultas.

7. Limitação de corrente e proteção de cota

Limite razoavelmente o número limitado de mensagens para acessar determinadas APIs de acordo com o sistema de back-end, a largura de banda real e a capacidade do servidor, para evitar efetivamente a ameaça de ataques DDoS.

8. Dados efetivos

O servidor deve verificar e verificar todo o conteúdo recebido duas vezes. Qualquer novo conteúdo, grandes conjuntos de dados e informações compartilhadas pelos consumidores devem ser verificados. Atualmente, a validação JSON e XML são duas das ferramentas mais utilizadas para verificar a segurança dos parâmetros. Ao mesmo tempo, eles também podem controlar eventos como injeção SQL e bombas XML.

9. Forte infraestrutura

Ao implementar as mais recentes tecnologias de rede segura, novos servidores e software de balanceamento de carga, podemos manter a API segura no nível da infraestrutura, tornando-a resistente a ataques de exfiltração de grande volume de dados.

10. Siga OWASP Top 10

Por meio da análise acima, você pode ver facilmente que as dez principais ameaças de vulnerabilidade de API listadas e interpretadas pelo OWASP são algumas das formas mais comuns de impacto de ataque. Eles são extremamente prejudiciais não apenas para páginas da Web, mas também para várias vulnerabilidades em APIs. Portanto, precisamos fazer um bom trabalho de prevenção no nível do código com antecedência.

11. Use um firewall de API

Construir um firewall para sua API atende a dois propósitos:

Pode ser usado para realizar verificações básicas de segurança, como verificar o tamanho da mensagem, a possibilidade de injeção de SQL e se o ataque pode ser bloqueado imediatamente.
Ele pode ser integrado ao sistema de proteção existente na LAN para melhorar conjuntamente a situação geral de segurança.

12. Implantar API Gateway

Seja para uso na intranet ou chamadas de rede externa, o ambiente no qual as APIs estão localizadas costuma ser complexo e perigoso. Portanto, para reduzir a pressão do gerenciamento de APIs, podemos implementar controle, monitoramento e proteção abrangentes do tráfego relacionado à API, implantando gateways de API.