Tópicos Comece a aprender Pesquise mais de 50.

000 cursos, even… O que há de novo

1 O que é segurança de API?

Este capítulocapas

O que é uma API?

O que torna uma API segura ou insegura?
Definindo a segurança em termos de objetivos
Identificando ameaças e vulnerabilidades
Usando mecanismos para atingir metas de segurança

As interfaces de programação de aplicativos (APIs) estão em toda parte. Abra seu

smartphone ou tablet e veja os aplicativos que você instalou. Quase sem exceção,
esses aplicativos estão se comunicando com uma ou mais APIs remotas para bai-
xar novos conteúdos e mensagens, consultar notificações, fazer upload de seu
novo conteúdo e executar ações em seu nome.

Carregue sua página da Web favorita com as ferramentas do desenvolvedor aber-

tas em seu navegador e provavelmente verá dezenas de chamadas de API aconte-
cendo em segundo plano para renderizar uma página altamente personalizada
para você como indivíduo (goste ou não). No servidor, essas chamadas de API po-
dem ser implementadaspor muitos microsserviços se comunicando entre si por
meio de APIs internas.
Cada vez mais, até mesmo os itens do dia a dia em sua casa estão conversando
com APIs na nuvem – de alto-falantes inteligentes como Amazon Echo ou Google
Home a geladeiras, medidores de eletricidade e lâmpadas. A Internet das Coisas
(IoT) está se tornando rapidamenteuma realidade tanto em ambientes de con-
sumo quanto industriais, alimentados por um número cada vez maior de APIs na
nuvem e nos próprios dispositivos.

Embora a disseminação de APIs esteja impulsionando aplicativos cada vez mais

sofisticados que aprimoram e ampliam nossas próprias habilidades, elas também
trazem riscos crescentes. À medida que nos tornamos mais dependentes de APIs
para tarefas críticas no trabalho e no lazer, nos tornamos mais vulneráveis ​se fo-
rem atacados. Quanto mais APIs forem usadas, maior será seu potencial de ata-
que. A própria propriedade que torna as APIs atraentes para desenvolvedores -
facilidade de uso - também as torna um alvo fácil para agentes mal-intencionados.
Ao mesmo tempo, a nova legislação de privacidade e proteção de dados, como o
GDPR na UE, impõe requisitos legais às empresas para proteger os dados dos
usuários, com penalidades severas se as proteções de dados forem consideradas
inadequadas.

RGPD

O Regulamento Geral de Proteção de Dados (RGPD) é uma peça significativada lei

da UE que entrou em vigor em 2018. O objetivo da lei é garantir que os dados pes-
soais dos cidadãos da UE não sejam abusados ​e sejam adequadamente protegidos
por controles técnicos e organizacionais. Isso inclui controles de segurança que
serão abordados neste livro, bem como técnicas de privacidade, como pseudoni-
mização de nomes e outras informações pessoais (que não abordaremos) e exi-
gência de consentimento explícito antes de coletar ou compartilhar dados pesso-
 ais. A lei exige que as empresas relatem qualquer violação de dados dentro de 72
horas e as violações da lei podem resultar em multas de até € 20 milhões (aproxi-
madamente US$ 23,6 milhões) ou 4% do faturamento anual mundial da empresa.
Outras jurisdições estão seguindo o exemplo da UE e introduzindo legislação se-
melhante sobre privacidade e proteção de dados.
Este livro é sobre como proteger suas APIs contra essas ameaças para que você
possa expô-las ao mundo com confiança.

1.1 Uma analogia: Fazendo o exame de direção

ParaPara ilustrar alguns dos conceitos de segurança da API, considere uma analo-
gia da vida real: fazer seu teste de direção. A princípio, isso pode não ter muito a
ver com APIs ou segurança, mas, como você verá, há semelhanças entre os aspec-
tos desta história e os principais conceitos que você aprenderá neste capítulo.

Você termina o trabalho às 17h, como de costume. Mas hoje é especial. Em vez de
ir para casa para cuidar de sua coleção de plantas carnívoras e depois se jogar na
frente da TV, você tem outro lugar para estar. Hoje você está fazendo seu exame
de direção.

Você sai correndo de seu escritório e atravessa o parque para pegar um ônibus
para o centro de testes. Ao passar tropeçando pela fila de pessoas na barraca de
cachorro-quente, você vê sua velha amiga Alice passeando com sua alpaca de esti-
mação, Horatio.

“Olá Alice!” você berra jovialmente. “Como está indo a recriação em miniatura da
Paris do século 18?”
"Bom!" ela responde. "Você deve vir e ver isso em breve."

Ela faz o gesto de mão universalmente reconhecido para “me ligue” e vocês dois
se apressam em seus caminhos separados.

Você chega ao centro de testes um pouco quente e incomodado com a viagem lo-
tada de ônibus. Se ao menos você pudesse dirigir, você pensa consigo mesmo!
Após uma breve espera, o examinador sai e se apresenta. Ele pede para ver a car-
teira de motorista do seu aluno e estuda a foto antiga de você com aquele corte de
cabelo ruim que você achou muito legal na época. Depois de alguns segundos de
olhares interrogativos, ele finalmente aceita que é realmente você, e você pode
começar o teste.

SAIBA MAIS A maioria das APIs precisa identificar os clientes que estão intera-
gindo com elas. Como ilustram essas interações fictícias, pode haver diferentes
maneiras de identificar seus clientes de API apropriados em diferentes situações.
Como no caso de Alice, às vezes há uma relação de confiança de longa data base-
ada em um histórico de interações anteriores, enquanto em outros casos é neces-
sária uma prova de identidade mais formal, como mostrar uma carteira de moto-
rista. O examinador confia na licença porque ela é emitida por um órgão confiá-
vel e você corresponde à foto da licença. Sua API pode permitir que algumas ope-
rações sejam executadas com apenas uma identificação mínima do usuário, mas
requer um nível mais alto de garantia de identidade para outras operações.

Você falhou no teste desta vez, então decide pegar um trem para casa. Na estação,
você compra uma passagem de classe padrão de volta ao seu bairro suburbano,
mas, sentindo-se um pouco despreocupado, decide se esgueirar para o vagão de
primeira classe. Infelizmente, um atendente bloqueia sua passagem e exige ver
seu ingresso. Docilmente, você corre de volta para a classe padrão e afunda em
seu assento com os fones de ouvido.

Ao chegar em casa, você vê a luz piscando na secretária eletrônica. Huh, você ti-
nha esquecido que tinha uma secretária eletrônica. É Alice, convidando você para
o novo clube quente que acabou de abrir na cidade. Você poderia sair à noite para
se animar, então decide ir.

A porteira dá uma olhada em você.

"Não esta noite", diz ela com um ar de finalidade desdenhosa.

Naquele momento, uma celebridade famosa se aproxima e é conduzida direta-

mente para dentro. Abatido e rejeitado, você volta para casa.

O que você precisa é de férias. Você reserva uma estadia de duas semanas em um
hotel chique. Enquanto você está fora, você dá a seu vizinho Bob a chave de sua
estufa tropical para que ele possa alimentar sua coleção de plantas carnívoras.
Sem que você saiba, Bob dá uma grande festa em seu quintal e convida metade da
cidade. Felizmente, devido a um erro de cálculo, eles ficam sem bebidas antes que
qualquer dano real seja causado (exceto à reputação de Bob) e a festa se dispersa.
Sua seleção de uísque premiada permanece trancada com segurança lá dentro.

SAIBA MAIS Além de apenas identificar seus usuários, uma API também pre-
cisa ser capaz de decidir que nível de acesso eles devem ter. Isso pode ser baseado
em quem eles são, como a celebridade entrando no clube, ou baseado em um to-
ken de tempo limitado, como uma passagem de trem, ou uma chave de longo
prazo, como a chave da estufa que você emprestou ao seu vizinho. Cada aborda-
gem tem diferentes trade-offs. Uma chave pode ser perdida ou roubada e depois
usada por qualquer pessoa. Por outro lado, você pode ter chaves diferentes para
fechaduras diferentes (ou operações diferentes), permitindo que apenas uma pe-
quena quantidade de autoridade seja dada a outra pessoa. Bob poderia entrar na
estufa e no jardim, mas não em sua casa e na coleção de uísque.

Ao retornar de sua viagem, você revisa as imagens de seu abrangente (alguns po-
dem dizer exagerado) sistema de vigilância por câmera. Você risca Bob da lista de
cartões de Natal e faz uma anotação mental para pedir a outra pessoa que cuide
das plantas na próxima vez.

Na próxima vez que você vir Bob, você o confrontará sobre a festa. Ele tenta ne-
gar a princípio, mas quandovocê aponta as câmeras, ele admite tudo. Ele compra
para você uma linda armadilha de Vênus para pedir desculpas. As câmeras de ví-
deo mostram a vantagem de ter bons registros de auditoria para que você possa
descobrir quem fez o quê quando as coisas dão errado e, se necessário, provar
quem foi o responsável de uma forma que eles não podem facilmentenegar.

DEFINIÇÃO Um log de auditoria registra detalhes de ações significativastoma-

das em um sistema, para que você possa descobrir quem fez o quê e quando. Os
logs de auditoria são evidências cruciais ao investigar possíveis violações de
segurança.

Agora você pode ver alguns dos mecanismos envolvidos na segurança de uma
API, mas antes de mergulharmos nos detalhes, vamos revisar o que é uma API e o
que significa ser segura.
1.2 O que é uma API?

Tradicionalmente,uma API foi fornecida por uma biblioteca de software que pode
ser vinculada a um aplicativo estaticamente ou dinamicamente em tempo de exe-
cução, permitindo a reutilização de procedimentos e funções para problemas es-
pecíficos, como OpenGL para gráficos 3D ou bibliotecas para redes TCP/IP. Essas
APIs ainda são comuns, mas um número crescente de APIs agora está disponível
na Internet como serviços Web RESTful.

De um modo geral, uma API é um limite entre uma parte de um sistema de soft-
ware e outra. Ele define um conjunto de operações que um componente fornece
para outras partes do sistema (ou outros sistemas) usarem. Por exemplo, um ar-
quivo de fotografia pode fornecer uma API para listar álbuns de fotos, para visua-
lizar fotos individuais, adicionar comentários e assim por diante. Uma galeria de
imagens on-line poderia usar essa API para exibir fotos interessantes, enquanto
um aplicativo de processador de texto poderia usar a mesma API para permitir a
incorporação de imagens em um documento. Conforme mostrado na Figura 1.1,
uma API lida com solicitações de um ou mais clientes em nome dos usuários. Um
cliente pode ser um aplicativo da Web ou móvel com uma interface de usuário
(UI) ou pode ser outra API sem interface do usuário explícita. A própria API pode
conversar com outras APIs para realizar seu trabalho.
Figura 1.1 Uma API lida com solicitações de clientes em nome dos usuários. Os cli-
entes podem ser navegadores da web, aplicativos móveis, dispositivos na Internet
das Coisas ou outras APIs. A API atende as solicitações de acordo com sua lógica
interna e, em algum momento, retorna uma resposta ao cliente. A implementação
da API pode exigir a comunicação com outras APIs de “back-end”, fornecidas por
bancos de dados ou sistemas de processamento.

Uma interface do usuário também fornece um limite para um sistema de software

e restringe as operações que podem ser executadas. O que distingue uma API de
uma interface do usuário é que uma API é explicitamente projetada para ser fácil
de interagir com outro software, enquanto uma interface do usuário é projetada
para ser fácil para um usuário interagir diretamente. Embora uma interface do
usuário possa apresentar informações em um formato rico para tornar as infor-
 mações agradáveis ​de ler e fáceis de interagir, uma API normalmente apresentará
uma visão altamente regular e simplificada dos dados brutos em um formato fácil
para um programa. para analisar e manipular.

1.2.1 Estilos de API

LáExistem várias abordagens populares para expor APIs remotas:

APIs Remote Procedure Call (RPC) expõem um conjunto de procedimentosou

funções que podem ser chamadas por clientes em uma conexão de rede. O es-
tilo RPC foi projetado para se parecer com chamadas de procedimento nor-
mais, como se a API fosse fornecida localmente. As APIs RPC geralmente usam
formatos binários compactos para mensagens e são muito eficientes, mas ge-
ralmente exigem que o cliente instale bibliotecas específicas (conhecidas como
stubs) que funcionam com uma única API. A estrutura gRPC do Google (
https://grpc.io ) é um exemplo de uma abordagem RPC moderna. A antiga es-
trutura SOAP (Simple Object Access Protocol), que usa XML para mensagens,
ainda é amplamente implantada.
Uma variante do estilo RPC conhecido comoChamada de método remoto (RMI)
usa técnicas orientadas a objetos para permitirclientes para chamar métodos
em objetos remotos como se fossem locais. Abordagens RMI costumavam ser
muito populares, com tecnologias como CORBA eEnterprise Java Beans(EJBs)
geralmente usados ​para construir grandes sistemas corporativos. A complexi-
dade dessas estruturas levou a um declínio em seu uso.
 O REST (REpresentational State Transfer) foi desenvolvido por Roy Fielding
para descrever os princípios que levaram ao sucesso do HTTP e da web e foi
posteriormente adaptado como um conjunto de princípios para design de API.
Em contraste com o RPC, as APIs RESTful enfatizam formatos de mensagem pa-
drão e um pequeno número de operações genéricas para reduzir o acopla-
mento entre um cliente e uma API específica. O uso de hiperlinks para navegar
na API reduz o risco de quebra de clientes à medida que a API evolui com o
tempo.
Algumas APIs se preocupam principalmente com a consulta e filtragem efici-
entes de grandes conjuntos de dados, como bancos de dados SQL ou a estru-
tura GraphQL do Facebook ( https://graphql.org ). Nesses casos, a API geral-
mente fornece apenas algumas operações e uma linguagem de consulta com-
plexa permite ocontrole significativo do cliente sobre quais dados são
retornados.

Diferentes estilos de API são adequados para diferentes ambientes. Por exemplo,
uma organização que adotou uma arquitetura de microsserviçospode optar por
uma estrutura RPC eficiente para reduzir a sobrecarga de chamadas de API. Isso é
apropriado porque a organização controla todos os clientes e servidores nesse
ambiente e pode gerenciar a distribuição de novas bibliotecas stub quando elas
são necessárias. Por outro lado, uma API pública amplamente utilizada pode ser
mais adequada ao estilo REST usando um formato amplamente utilizado como
JSON para maximizar a interoperabilidade com diferentes tipos de clientes.

DEFINIÇÃO Em uma arquitetura de microsserviços, um aplicativo é implan-

tado como uma coleção de serviços fracamente acoplados, em vez de um único
aplicativo grande ou monólito. Cada microsserviço expõe uma API com a qual ou-
 tros serviços se comunicam. A proteção de APIs de microsserviço é abordada em
detalhes na parte 4 deste livro.

Este livro se concentrará em APIs expostas em HTTP usando uma abordagem

RESTful vagamente, pois esse é o estilo predominante de API no momento em que
escrevo. Ou seja, embora as APIs desenvolvidas neste livro tentem seguir os prin-
cípios de design REST, às vezes você se desviará desses princípios para demons-
trar como proteger outros estilos de design de API. Muitos dos conselhos também
se aplicam a outros estilos, e os princípios gerais também se aplicam ao
projetarumabiblioteca.

1.3 Segurança da API no contexto

APIA segurança está na interseção de várias disciplinas de segurança, conforme

mostrado na figura 1.2. O mais importante deles são as três áreas a seguir:

1. Segurança da informação (InfoSec) preocupa-se com a proteção das informa-

ções durante todo o seu ciclo de vida, desde a criação, armazenamento, trans-
missão, backup e eventual destruição.
2. Segurança de redelida com a proteção de dados que fluem por uma rede e a
prevenção de acesso não autorizado à própria rede.
3. Segurança de aplicativos (AppSec) garante que os sistemas de software sejam
projetados e construídos para resistir a ataques e uso indevido.
Figura 1.2 A segurança da API está na interseção de três áreas de segurança: segu-
rança da informação, segurança da rede e segurança do aplicativo.

Cada um desses três tópicos preencheu muitos livros individualmente, portanto

não abordaremos cada um deles em profundidade. Como ilustra a figura 1.2, você
não precisa aprender todos os aspectos desses tópicos para saber como criar APIs
seguras. Em vez disso, vamos escolher as áreas mais críticas de cada uma e com-
biná-las para fornecer uma compreensão completa de como elas se aplicam à pro-
teção de uma API.
Com a segurança da informação, você aprenderá como:

Defina suas metas de segurança e identifique ameaças

Proteja suas APIs usando técnicas de controle de acesso
Informações seguras usando criptografia aplicada

Criptografia DE DEFINIÇÃOé a ciência de proteger informações para que duas

ou mais pessoas possam se comunicar sem que suas mensagens sejam lidas ou
adulteradas por mais ninguém. Também pode ser usado para proteger as infor-
mações gravadas no disco.

De segurança de rede, você aprenderá:

A infraestrutura básica usada para proteger uma API na Internet, incluindo fi-
rewalls, balanceadores de carga e proxies reversos, e as funções que eles de-
sempenham na proteção de sua API (consulte a próxima seção)
Uso de protocolos de comunicação seguros, como HTTPS, para proteger os da-
dos transmitidos de ou para sua API

DEFINIÇÃO HTTPSé o nome de HTTP executado em uma conexão segura. En-

quanto as solicitações e respostas HTTP normais são visíveis para qualquer pes-
soa que esteja observando o tráfego da rede, as mensagens HTTPS são ocultadas e
protegidas porSegurança da Camada de Transporte(TLS, também conhecido como
SSL). Você aprenderá como habilitar HTTPS para uma API no capítulo 3.

Por fim, com a segurança de aplicativos, você aprenderá:

Técnicas de codificação segura

 Vulnerabilidades comuns de segurança de software
Como armazenar e gerenciar as credenciais do sistema e do usuário usadas
para acessar suas APIs

1.3.1 Uma implantação típica de API

UmA API é implementada pelo código do aplicativo em execução em um servidor;

ou um servidor de aplicativoscomo Java Enterprise Edition(Java EE) ou um servi-
dor independente. É muito raro expor diretamente tal servidor à internet, ou
mesmo a uma intranet interna. Em vez disso, as solicitações para a API normal-
mente passarão por um ou mais serviços de rede adicionais antes de chegarem
aos servidores da API, conforme mostrado na figura 1.3. Cada solicitação passará
por um ou mais firewalls, que inspeciona o tráfego de rede em um nível relativa-
mente baixo e garante que qualquer tráfego inesperado seja bloqueado. Por
exemplo, se suas APIs estiverem atendendo a solicitações na porta 80 (para HTTP)
e 443 (para HTTPS), o firewall será configurado para bloquear qualquer solicita-
ção para qualquer outra porta. Um balanceador de cargairá então rotear o tráfego
para os serviços apropriados e garantir que um servidor não seja sobrecarregado
com muitos pedidos enquanto outros ficam ociosos. Finalmente, um proxy
reverso(ou gateway) é normalmente colocado na frente dos servidores de aplicati-
vos para executar operações computacionalmente caras, como manipulação de
criptografia TLS (conhecida como terminação SSL) e validação de credenciais em
solicitações.

Terminação SSL DE DEFINIÇÃO1 (ou descarregamento de SSL) ocorre quando

uma conexão TLS de um cliente é manipulada por um balanceador de carga ou
proxy reverso na frente do servidor de API de destino. Uma conexão separada do
proxy para o servidor de back-end é então feita, que pode ser não criptografada
(HTTP simples) ou criptografada como um separadoConexão TLS (conhecida
como recriptografia SSL).

Além desses elementos básicos, você pode encontrar vários outros serviços
especializados:

Um gateway de APIé um proxy reverso especializado que pode fazer com que
diferentes APIs apareçam como se fossem uma única API. Eles costumam ser
usados ​em uma arquitetura de microsserviços para simplificar a API apresen-
tada aos clientes. Os gateways de API geralmente também podem cuidar de al-
guns dos aspectos da segurança de API discutidos neste livro, como autentica-
ção ou limitação de taxa.
UMAfirewall de aplicação web(WAF) inspeciona o tráfego em um nível mais
alto do que um firewall tradicional e pode detectar e bloquear muitos ataques
comuns contra serviços da Web HTTP.
Umsistema de detecção de intrusão(IDS) ousistema de prevenção de
intrusão(IPS) monitora o tráfego dentro de suas redes internas. Quando de-
tecta padrões suspeitos de atividade, pode emitir um alerta ou tentar ativa-
mente bloquear o tráfego suspeito.
Figura 1.3 As solicitações para seus servidores de API geralmente passam pri-
meiro por vários outros serviços. Um firewall funciona no nível TCP/IP e permite
apenas o tráfego dentro ou fora da rede que corresponda aos fluxos esperados.
Um balanceador de carga roteia solicitações para serviços internos apropriados
com base na solicitação e em seu conhecimento de quanto trabalho cada servidor
está fazendo no momento. Um proxy reverso ou gateway de API pode cuidar de
tarefas caras em nome do servidor de API, como encerrar conexões HTTPS ou va-
lidar credenciais de autenticação.

Na prática, muitas vezes há alguma sobreposição entre esses serviços. Por exem-
plo, muitos balanceadores de carga também são capazes de executar tarefas de
um proxy reverso, como encerrar conexões TLS, enquanto muitos proxies rever-
sos também podem funcionar como um gateway de API. Certos serviços mais es-
pecializados podem até lidar com muitos dos mecanismos de segurança que você
aprenderá neste livro, e está se tornando comum permitir que um gateway ou
proxy reverso lide com pelo menos algumas dessas tarefas. Existem limites para o
que esses componentes podem fazer, e práticas de segurança inadequadas em
suas APIs podem prejudicar até mesmo o gateway mais sofisticado. Um gateway
mal configurado também pode apresentar novos riscos à sua rede. Compreender
os mecanismos básicos de segurança usados ​por esses produtos ajudará você a
avaliar se um produto é adequado para sua aplicação e exatamente quais são seus
pontos fortes elimitaçõessão.

questionário

1. Quais dos seguintes tópicos são diretamente relevantes para a segurança da

API? (Selecione tudo que se aplica.)
1. Seguro desemprego
2. segurança nacional
3. Segurança de rede
4. Segurança financeira
 5. Segurança do aplicativo
6. segurança da informação
2. Um gateway de API é uma versão especializada de qual dos seguintes
componentes?
1. Cliente
2. Base de dados
3. Balanceador de carga
4. proxy reverso
5. Servidor de aplicação

As respostas estão no final do capítulo.

1.4 Elementos de segurança da API

UmA API, por sua própria natureza, define um conjunto de operações que um
chamador pode usar. Se você não deseja que um usuário execute alguma opera-
ção, basta excluí-lo da API. Então, por que precisamos nos preocupar com a segu-
rança da API?

Primeiro, a mesma API pode ser acessada por usuários com diferentes níveis
de autoridade; por exemplo, com algumas operações permitidas apenas para
administradores ou outros usuários com uma função especial. A API também
pode ser exposta a usuários (e bots) na Internet que não deveriam ter nenhum
acesso. Sem controles de acesso apropriados, qualquer usuário pode realizar
qualquer ação, o que provavelmente é indesejável. Esses são fatores relaciona-
dos ao ambiente em que a API deve operar.
 Em segundo lugar, embora cada operação individual em uma API possa ser se-
gura por conta própria, as combinações de operações podem não ser. Por
exemplo, uma API bancária pode oferecer operações separadas de retirada e
depósito, que verificam individualmente se os limites não foram excedidos.
Mas a operação de depósito não tem como saber se o dinheiro que está sendo
depositado veio de uma conta real. Uma API melhor ofereceria uma operação
de transferência que movimenta dinheiro de uma conta para outra em uma
única operação, garantindo que sempre exista a mesma quantia de dinheiro. A
segurança de uma API precisa ser considerada como um todo, e não como ope-
rações individuais.
Por último, pode haver vulnerabilidades de segurança devido à implementa-
ção da API. Por exemplo, deixar de verificar o tamanho das entradas para sua
API pode permitir que um invasor derrube seu servidor enviando uma en-
trada muito grande que consome toda a memória disponível; um tipo de ata-
que de negação de serviço (DoS).

DEFINIÇÃO Um ataque de negação de serviço (DoS) ocorre quandoum invasor

pode impedir que usuários legítimos acessem um serviço. Isso geralmente é feito
inundando um serviço com tráfego de rede, impedindo-o de atender a solicitações
legítimas, mas também pode ser obtido desconectando conexões de rede ou explo-
rando bugs para travar o servidor.

Alguns projetos de API são mais passíveis de implementação segura do que ou-
tros, e existem ferramentas e técnicas que podem ajudar a garantir uma imple-
mentação segura. É muito mais fácil (e mais barato) pensar no desenvolvimento
seguro antes de começar a codificar, em vez de esperar até que os defeitos de se-
gurança sejam identificados posteriormente no desenvolvimento ou na produção.
Alterar retrospectivamente um ciclo de vida de design e desenvolvimento para le-
 var em conta a segurança é possível, mas raramente é fácil. Este livro ensinará
técnicas práticas para proteger APIs, mas se você quiser uma base mais completa
sobre como projetar a segurança desde o início, recomendo o livro Secure by De-
sign de Dan Bergh Johnsson, Daniel Deogun e Daniel Sawano ( Manning, 2019).

É importante lembrar que não existe um sistema perfeitamente seguro e nem

mesmo uma única definição de “segurança”. Para um profissional de saúde, ser
capaz de descobrir se seus amigos têm contas em um sistema seria considerado
uma grande falha de segurança e uma violação de privacidade. No entanto, para
uma rede social, a mesma capacidade é uma característica essencial. A segurança,
portanto, depende do contexto. Há muitos aspectos que devem ser considerados
ao projetar uma API segura, incluindo os seguintes:

Os ativos que devem ser protegidos, incluindo dados, recursos e dispositivos

físicos
Quais metas de segurança são importantes, como confidencialidade dos nomes
das contas
Os mecanismos que estão disponíveis para atingir esses objetivos
O ambiente no qual a API deve operar e as ameaças existentes nesse ambiente

1.4.1 Ativos

PorNa maioria das APIs, os ativos consistirão em informações, como nomes e en-
dereços de clientes, informações de cartão de crédito e conteúdo de bancos de da-
dos. Se você armazenar informações sobre indivíduos, especialmente se forem
confidenciais, como orientação sexual ou afiliações políticas, essas informações
também devem ser consideradas um ativo a ser protegido.
 Também há ativos físicos a serem considerados, como servidores físicos ou dispo-
sitivos nos quais sua API está sendo executada. Para servidores rodando em um
datacenter, há relativamente poucos riscos de um intruso roubar ou danificar o
próprio hardware, devido às proteções físicas (cercas, muros, fechaduras, câme-
ras de vigilância etc.) aqueles ambientes. Mas um invasor pode obter o controle
dos recursosque o hardware fornece por meio de pontos fracos no sistema opera-
cional ou no software executado nele. Se eles puderem instalar seu próprio soft-
ware, poderão usar seu hardware para executar suas próprias ações e impedir
que seu software legítimo funcione corretamente.

Resumindo, qualquer coisa relacionada ao seu sistema que tenha valor para al-
guém deve ser considerada um ativo. Dito de outra forma, se alguém sofrer danos
reais ou percebidos se alguma parte do sistema for comprometida, essa parte
deve ser considerada um ativo a ser protegido. Esse dano pode ser direto, como
perda de dinheiro, ou pode ser mais abstrato, como perda de reputação. Por
exemplo, se você não proteger adequadamente as senhas de seus usuários e elas
forem roubadas por um invasor, os usuários podem sofrer danos diretos devido
ao comprometimento de suas contas individuais, mas sua organização também
sofrerá danos à reputação se souber que você não tinha seguido a segurança
básicaprecauções.

1.4.2 Objetivos de segurança

Segurançaos objetivos são usados ​para definir o que a segurança realmente signi-
fica para a proteção de seus ativos. Não existe uma definição única de segurança e
algumas definições podem até ser contraditórias! Você pode quebrar a noção de
segurança em termos dos objetivos que devem ser alcançados ou preservados
pelo correto funcionamento do sistema. Existem vários objetivos de segurança pa-
drão que se aplicam a quase todos os sistemas. As mais famosas delas são as cha-
madas “Tríades da CIA”.”:

Confidencialidade--Garantir que as informações só possam ser lidas por seu

público-alvo
Integridade--Evitar a criação, modificação ou destruição não autorizada de
informações
Disponibilidade--Garantir que os usuários legítimos de uma API possam
acessá-la quando precisarem e não forem impedidos de fazê-lo.

Embora essas três propriedades sejam quase sempre importantes, existem outras
metas de segurança que podem ser igualmente importantes em diferentes contex-
tos, como responsabilidade (quem fez o quê) ou não repúdio(não poder negar ter
realizado uma ação). Discutiremos os objetivos de segurança em profundidade
conforme você desenvolve aspectos de uma API de amostra.

As metas de segurança podem ser vistas como requisitos não funcionais(NFRs) e

considerados juntamente com outros NFRs, como metas de desempenho ou confi-
abilidade. Em comum com outros NFRs, pode ser difícil definir exatamente
quando uma meta de segurança foi satisfeita. É difícil provar que uma meta de se-
gurança nunca é violada porque isso envolve provar uma negativa, mas também
é difícil quantificar o que é uma confidencialidade “boa o suficiente”, por
exemplo.

Uma abordagem para tornar as metas de segurança precisas é usada na criptogra-

fia. Aqui, os objetivos de segurança são considerados como uma espécie de jogo
entre um invasor e o sistema, com vários poderes atribuídos ao invasor. Um jogo
padrão de confidencialidade é conhecido como indistinguibilidade. Nesse jogo,
mostrado na figura 1.4, o invasor dá ao sistema duas mensagens de comprimento
igual, A e B, de sua escolha e, em seguida, o sistema devolve a criptografia de uma
ou da outra. O atacante ganha o jogo se puder determinar qual de A ou B foi de-
volvido a ele. O sistema é considerado seguro (para esse objetivo de segurança) se
nenhum invasor realista tiver mais de 50% de chance de adivinhar corretamente.

Figura 1.4 O jogo de indistinguibilidade usado para definir confidencialidade em

criptografia. O invasor pode enviar duas mensagens de comprimento igual, A e B.
O sistema então escolhe uma aleatoriamente e a criptografa usando a chave. O
sistema é seguro se nenhum desafiante “eficiente” puder fazer muito melhor do
que adivinhar para saber se recebeu a criptografia da mensagem A ou B.

Nem todos os cenários podem ser tão precisos quanto os usados ​na criptografia.
Uma alternativa é refinar objetivos de segurança mais abstratos em requisitos es-
pecíficos que sejam concretos o suficiente para serem testados. Por exemplo, uma
API de mensagens instantâneas pode ter o requisito funcional de que os usuários
possam ler suas mensagens. Para preservar a confidencialidade, você pode adicio-
nar restrições de que os usuários só podem ler suas próprias mensagens e que um
usuário deve estar conectado antes de poder ler suas mensagens. Nessa aborda-
gem, as metas de segurança tornam-se restrições aos requisitos funcionais exis-
tentes. Então fica mais fácil pensar em casos de teste. Por exemplo:

Crie dois usuários e preencha suas contas com mensagens fictícias.

Verifique se o primeiro usuário não consegue ler as mensagens do segundo
usuário.
Verifique se um usuário que não fez login não pode ler nenhuma mensagem.

Não há uma única maneira correta de dividir uma meta de segurança em requisi-
tos específicos e, portanto, o processo é sempre de iteração e refinamento à me-
dida que as restrições se tornam mais claras com o tempo, conforme mostrado na
figura 1.5. Depois de identificar os ativos e definir os objetivos de segurança, você
divide esses objetivos em restrições testáveis. Então, ao implementar e testar es-
sas restrições, você pode identificar novos ativos a serem protegidos. Por exem-
plo, depois de implementar seu sistema de login, você pode fornecer a cada usuá-
rio um cookie de sessão temporária exclusivo. Este cookie de sessão é em si um
novo ativo que deve ser protegido. Os cookies de sessão são discutidos no capítulo
4.
Figura 1.5 A definição de segurança para sua API consiste em um processo itera-
tivo de quatro etapas para identificar ativos, definir os objetivos de segurança que
você precisa preservar para esses ativos e, em seguida, dividi-los em restrições de
implementação testáveis. A implementação pode então identificar novos ativos ou
metas e assim o processo continua.

Esse processo iterativo mostra que a segurança não é um processo único que pode
ser assinado uma vez e depois esquecido. Assim como você não testaria o desem-
penho de uma API apenas uma vez, revise as metas e suposições de segurança re-
gularmente para garantir que elas ainda sejamválido.
1.4.3 Ambientes e modelos de ameaças

UMAUma boa definição de segurança da API também deve considerar o ambiente

em que sua API deve operar e as possíveis ameaças que existirão nesse ambiente.
Uma ameaça é simplesmente qualquer maneira pela qual uma meta de segurança
pode ser violada em relação a um ou mais de seus ativos. Em um mundo perfeito,
você seria capaz de projetar uma API que alcançasse seus objetivos de segurança
contra qualquer ameaça. Mas o mundo não é perfeito e raramente é possível ou
econômico evitar todos os ataques. Em alguns ambientes, não vale a pena se preo-
cupar com algumas ameaças. Por exemplo, uma API para registrar tempos de cor-
rida para um clube de ciclismo local provavelmente não precisa se preocupar
com as atenções de uma agência de inteligência de um estado-nação, embora
possa querer evitar que os ciclistas tentem “melhorar” seus próprios melhores
tempos ou alterar os de outros ciclistas.

DEFINIÇÃO Uma ameaçaé um evento ou conjunto de circunstâncias que anula

os objetivos de segurança de sua API. Por exemplo, um invasor que rouba nomes
e detalhes de endereço de seu banco de dados de clientes é uma ameaça à
confidencialidade.

O conjunto de ameaças que você considera relevante para sua API é conhecido
como seu modelo de ameaça, e o processo de identificação é conhecido como mo-
delagem de ameaças.

DEFINIÇÃO A modelagem de ameaças é o processo de identificação sistemática

de ameaças a um sistema de software para que possam ser registradas, rastreadas
e mitigadas.
Há uma citação famosa atribuída a Dwight D. Eisenhower:

Planos não valem nada, mas planejamento é tudo.

Geralmente é assim com a modelagem de ameaças. É menos importante exata-

mente como você faz a modelagem de ameaças ou onde registra os resultados. O
que importa é que você faça isso, porque o processo de pensar nas ameaças e fra-
quezas do seu sistema quase sempre melhorará a segurança da API.

Existem muitas maneiras de fazer modelagem de ameaças, mas o processo geral é

o seguinte:

1. Desenhe um diagrama de sistema mostrando os principais componentes lógi-

cos de sua API.
2. Identificar limites de confiançaentre as partes do sistema. Tudo dentro de um
limite de confiança é controlado e gerenciado pelo mesmo proprietário, como
um datacenter privado ou um conjunto de processos executados em um único
usuário do sistema operacional.
3. Desenhe setas para mostrar como os dados fluem entre as várias partes do
sistema.
4. Examine cada componente e fluxo de dados no sistema e tente identificar ame-
aças que possam minar seus objetivos de segurança em cada caso. Preste aten-
ção especial aos fluxos que cruzam os limites de confiança. (Consulte a pró-
xima seção para saber como fazer isso.)
5. Registre as ameaças para garantir que sejam rastreadas e gerenciadas.

O diagrama produzido nas etapas um a três é conhecido como diagrama de fluxo

de dados, e um exemplo de uma API de pedido de pizza fictícia é fornecido na Fi-
gura 1.6. A API é acessada por um aplicativo da Web em execução em um navega-
dor da Web e também por um aplicativo de telefone móvel nativo, portanto, am-
bos são desenhados como processos em seus próprios limites de confiança. O ser-
vidor de API é executado no mesmo datacenter que o banco de dados, mas eles
são executados como contas de sistema operacional diferentes para que você
possa traçar limites de confiança adicionais para deixar isso claro. Observe que os
limites da conta do sistema operacional estão aninhados dentro do limite de confi-
ança do datacenter. Para o banco de dados, desenhei o sistema de gerenciamento
de banco de dados(DBMS) separadamente dos arquivos de dados reais. Muitas ve-
zes, é útil considerar as ameaças de usuários que têm acesso direto aos arquivos
separadamente das ameaças que acessam a API do DBMS porque elas podem ser
bem diferentes.

IDENTIFICANDO AMEAÇAS

Se você prestar atenção às notícias de segurança cibernética, às vezes pode pare-

cer que há uma variedade desconcertante de ataques contra os quais você precisa
se defender. Embora isso seja parcialmente verdade, muitos ataques se enqua-
dram em algumas categorias conhecidas. Várias metodologias foram desenvolvi-
das para tentar identificar sistematicamente as ameaças aos sistemas de software,
e podemos usá-las para identificar os tipos de ameaças que podem acontecer à
sua API. O objetivo da modelagem de ameaças é identificar essas ameaças gerais,
não enumerar todos os ataques possíveis.
Figura 1.6 Um exemplo de diagrama de fluxo de dados, mostrando processos, ar-
mazenamentos de dados e o fluxo de dados entre eles. Os limites de confiança são
marcados com linhas tracejadas. Os processos internos são marcados com retân-
gulos arredondados, enquanto as entidades externas usam extremidades quadra-
das. Observe que incluímos o sistema de gerenciamento de banco de dados
(DBMS) e seus arquivos de dados como entidades separadas.

Uma metodologia muito popular é conhecida pela sigla STRIDE, que significa:

Spoofing - fingir ser outra pessoa

adulteração--Alterando dados, mensagens ou configurações que você não de-
veria alterar
Repúdio--Negar que você fez algo que você realmente fez
Divulgação de informação--Revelar informações que devem ser mantidas em
sigilo
Negação de serviço--Evitar que outras pessoas acessem informações e serviços
 Elevação de privilégio--Obter acesso a funcionalidades às quais você não deve-
ria ter acesso

Cada inicial na sigla STRIDE representa uma classe de ameaça à sua API. Mecanis-
mos gerais de segurança podem efetivamente lidar com cada classe de ameaça.
Por exemplo, ameaças de spoofing, nas quais alguém finge ser outra pessoa, po-
dem ser tratadas exigindo que todos os usuários se autentiquem. Muitas ameaças
comuns à segurança da API podem ser totalmente eliminadas (ou pelo menos mi-
tigadas significativamente) pela aplicação consistente de alguns mecanismos bási-
cos de segurança, como você verá no capítulo 3 e no restanteistolivro.

SAIBA MAIS SOBRE ISSO Você pode aprender mais sobre o STRIDE e como
identificar ameaças específicas para seus aplicativos por meio de um dos muitos
bons livros sobre modelagem de ameaças. Recomendo Threat Modeling: Desig-
ning for Security (Wiley, 2014), de Adam Shostack, como uma boa introdução ao
assunto.

questionário

3. O que significam as iniciais CIA quando se fala em objetivos de segurança?

4. Em qual dos fluxos de dados a seguir você deve prestar mais atenção ao mode-
lar ameaças?
1. Fluxos de dados em um navegador da web
2. Fluxos de dados que cruzam limites de confiança
3. Fluxos de dados entre processos internos
4. Fluxos de dados entre processos externos
5. Fluxos de dados entre um banco de dados e seus arquivos de dados
 5. Imagine o seguinte cenário: um administrador de sistema não autorizado de-
sativa o log de auditoria antes de executar ações usando uma API. Quais das
ameaças STRIDE estão sendo abusadas neste caso? Lembre-se da seção 1.1 que
um log de auditoria registra quem fez o quê no sistema.

As respostas estão no final do capítulo.

1.5 Mecanismos de segurança

Ameaçaspodem ser combatidos pela aplicação de mecanismos de segurança que

garantem que determinados objetivos de segurança sejam atendidos. Nesta seção,
examinaremos os mecanismos de segurança mais comuns que você geralmente
encontrará em todas as APIs bem projetadas:

Criptografiagarante que os dados não possam ser lidos por pessoas não autori-
zadas, seja quando estiverem sendo transmitidos da API para um cliente ou
em repouso em um banco de dados ou sistema de arquivos. A criptografia mo-
derna também garante que os dados não possam ser modificados por um
invasor.
Autenticaçãoé o processo de garantir que seus usuários e clientes sejam quem
dizem ser.
Controle de acesso (também conhecido como autorização) é o processo de ga-
rantir que todas as solicitações feitas à sua API sejam devidamente
autorizadas.
Log de auditoriaé usado para garantir que todas as operações sejam registra-
das para permitir a responsabilidade e o monitoramento adequado da API.
Limitação de taxaé usado para impedir que qualquer usuário (ou grupo de
usuários) use todos os recursos e impeça o acesso de usuários legítimos.
A Figura 1.7 mostra como esses cinco processos normalmente são colocados em
camadas como uma série de filtros pelos quais uma solicitação passa antes de ser
processada pela lógica central de sua API. Conforme discutido na seção 1.3.1, cada
um desses cinco estágios às vezes pode ser terceirizado para um componente ex-
terno, como um gateway de API. Neste livro, você criará cada um deles do zero
para poder avaliar quando um componente externo pode ser uma escolha
apropriada.

Figura 1.7 Ao processar uma solicitação, uma API segura aplicará algumas etapas
padrão. As solicitações e respostas são criptografadas usando o protocolo HTTPS.
A limitação de taxa é aplicada para evitar ataques DoS. Em seguida, os usuários e
clientes são identificados e autenticados, e é feito o registro da tentativa de acesso
 em log de acesso ou auditoria. Por fim, são feitas verificações para decidir se esse
usuário deve ser capaz de realizar essa solicitação. O resultado da solicitação tam-
bém deve ser registrado no log de auditoria.

1.5.1 Criptografia

ooutros mecanismos de segurança discutidos nesta seção tratam da proteção do

acesso aos dados por meio da própria API. A criptografia é usada para proteger os
dados quando estão fora de sua API. Existem dois casos principais em que os da-
dos podem estar em risco:

Solicitações e respostas a uma API podem estar em risco à medida que trafe-
gam por redes, como a Internet. Criptografia de dados em trânsitoé usado para
proteger contra essas ameaças.
Os dados podem estar em risco de pessoas com acesso ao armazenamento em
disco usado para persistência. Criptografia de dados em repousoé usado para
proteger contra essas ameaças.

TLS deve ser usado para criptografar dados em trânsito e é abordado no capítulo
3. Alternativas para TLS para dispositivos restritos são discutidas no capítulo 12.
Criptografar dados em repouso é um tópico complexo com muitos aspectos a se-
rem considerados e está muito além do escopo deste livro . Algumas considera-
ções para criptografia de banco de dados são discutidas emcapítulo 5.

1.5.2 Identificação e autenticação

Autenticaçãoé o processo de verificar se um usuário é quem diz ser. Normal-

mente nos preocupamos em identificar quem é esse usuário, mas em muitos ca-
sos a maneira mais fácil de fazer isso é fazer com que o cliente nos diga quem é e
verificar se está falando a verdade.

A história do teste de direção no início do capítulo ilustra a diferença entre identi-

ficação e autenticação. Quando você viu sua velha amiga Alice no parque, soube
imediatamente quem ela era devido a uma história compartilhada de interações
anteriores. Seria absolutamente bizarro (para não dizer rude) se você pedisse a
velhos amigos uma identificação formal! Por outro lado, quando fez o seu exame
de condução, não foi de estranhar que o examinador lhe pedisse para ver a sua
carta de condução. O examinador provavelmente nunca o conheceu antes, e um
teste de direção é uma situação em que alguém pode mentir razoavelmente sobre
quem é, por exemplo, para conseguir que um motorista mais experiente faça o
teste por eles. A carta de condução autentica a sua afirmação de que é uma pessoa
em particular,

Por que precisamos identificar os usuários de uma API em primeiro lugar? Você
sempre deve fazer essa pergunta para qualquer mecanismo de segurança que es-
teja adicionando à sua API, e a resposta deve ser em termos de uma ou mais das
metas de segurança que você está tentando alcançar. Você pode querer identificar
os usuários por vários motivos:

Você deseja registrar quais usuários executaram quais ações para garantir a
responsabilidade.
Você pode precisar saber quem é um usuário para decidir o que ele pode fazer,
para impor metas de confidencialidade e integridade.
Você pode querer processar apenas solicitações autenticadas para evitar DoS
anônimoataques que comprometam a disponibilidade.
Como a autenticação é o método mais comum de identificar um usuário, é comum
falar em “autenticar um usuário” como uma abreviação para identificar esse
usuário por meio de autenticação. Na realidade, nunca “autenticamos” um usuá-
rio, mas sim reivindicamossobre sua identidade, como seu nome de usuário. Au-
tenticar uma reivindicação significa simplesmente determinar se ela é autêntica
ou genuína. Isso geralmente é feito solicitando ao usuário que apresente algum
tipo de credencialque provem que as declarações estão corretas (eles fornecem
credibilidade às declarações, que é de onde vem a palavra “credencial”), como
fornecer uma senha junto com o nome de usuário que somente esse usuário
saberia.

FATORES DE AUTENTICAÇÃO

LáExistem muitas maneiras de autenticar um usuário, que podem ser divididas

em três grandes categorias conhecidas como fatores de autenticação:

Algo que você sabe, como uma senha secreta

Algo que você tem, como uma chave ou dispositivo físico
Algo que você é. Isso se refere a fatores biométricos, como sua impressão digi-
tal exclusiva ou padrão de íris.

Qualquer fator individual de autenticação pode ser comprometido. As pessoas es-

colhem senhas fracas ou as anotam em notas anexadas à tela do computador e ex-
traviam dispositivos físicos. Embora os fatores biométricos possam ser atraentes,
eles geralmente apresentam altas taxas de erro. Por esta razão, os sistemas de au-
tenticação mais seguros requerem dois ou mais fatores diferentes. Por exemplo,
seu banco pode exigir que você digite uma senha e, em seguida, use um disposi-
 tivo com seu cartão bancário para gerar um código de login exclusivo. Isso é co-
nhecido comoautenticação de dois fatores(2FA) ouautenticação multifator(MFA).

DEFINIÇÃO A autenticação de dois fatores (2FA) ou a autenticação multifator

(MFA) exige que um usuário autentique com dois ou mais fatores diferentes, de
modo que o comprometimento de qualquer um dos fatores não seja suficiente
para conceder acesso a um sistema.

Observe que um fator de autenticação é diferente de uma credencial. A autentica-

ção com duas senhas diferentes ainda seria considerada um fator único, porque
ambas são baseadas em algo que você conhece. Por outro lado, a autenticação
com uma senha e um código baseado em tempo gerado por um aplicativo em seu
telefone conta como 2FA porque o aplicativo em seu telefone é algo que você pos-
sui. Sem o aplicativo (e a chave secreta armazenada dentro dele), você não conse-
guiria geraracódigos.

1.5.3 Controle de acesso e autorização

DentroPara preservar a confidencialidade e a integridade de seus ativos, geral-

mente é necessário controlar quem tem acesso a quê e quais ações eles podem re-
alizar. Por exemplo, uma API de mensagens pode exigir que os usuários só te-
nham permissão para ler suas próprias mensagens e não as de qualquer outra
pessoa, ou que só possam enviar mensagens para usuários em seu grupo de
amizade.

OBSERVAÇÃO Neste livro, usei os termos autorizaçãoe controle de acesso de

forma intercambiável, porque é assim que eles são frequentemente usados ​na
prática. Alguns autores usam o termo controle de acesso para se referir a um pro-
cesso geral, incluindo autenticação, autorização e log de auditoria, ou AAA para
abreviar.

Existem duas abordagens principais para o controle de acesso que são usadas
para APIs:

Controle de acesso baseado em identidadeprimeiro identifica o usuário e de-

pois determina o que ele pode fazer com base em quem ele é. Um usuário pode
tentar acessar qualquer recurso, mas pode ter o acesso negado com base nas
regras de controle de acesso.
Controle de acesso baseado em capacidadeusa tokens ou chaves especiaisco-
nhecido como capacidadespara acessar uma API. A própria capacidade diz
quais operações o portador pode executar, em vez de quem é o usuário. Uma
capacidade nomeia um recurso e descreve as permissões nele, de modo que
um usuário não possa acessar nenhum recurso para o qual não tenha
capacidade.

Os Capítulos 8 e 9 abordam essas duas abordagens de controle de acesso em

detalhes.

Segurança baseada em capacidade

A abordagem predominante para o controle de acesso é baseada em identidade,

onde quem você é determina o que você pode fazer. Quando você executa um
aplicativo em seu computador, ele é executado com as mesmas permissões que
você possui. Ele pode ler e gravar todos os arquivos que você pode ler e gravar e
executar todas as mesmas ações que você pode fazer. Em um sistema baseado em
capacidade, as permissões são baseadas em referências não falsificáveis ​conheci-
das como capacidades (ou chaves). Um usuário ou um aplicativo só pode ler um
arquivo se tiver um recurso que permita a leitura desse arquivo específico. Isso é
um pouco como uma chave física que você usa no mundo real; quem tem a chave
pode abrir a porta que ela abre. Assim como uma chave real geralmente abre ape-
nas uma única porta, os recursos geralmente também são restritos a apenas um
objeto ou arquivo. Um usuário pode precisar de muitos recursos para realizar seu
trabalho, e os sistemas de capacidade fornecem mecanismos para gerenciar todos
esses recursos de maneira amigável. O controle de acesso baseado em capacidade
é abordado em detalhes no capítulo 9.
É até possível projetar aplicativos e suas APIs para não precisar de nenhum con-
trole de acesso. um wikié um tipo de site inventado por Ward Cunningham, onde
os usuários colaboram para escrever artigos sobre algum tópico ou tópicos. O wiki
mais famoso é a Wikipédia, a enciclopédia online que é um dos sites mais vistos
da web. Um wiki é incomum porque não possui nenhum controle de acesso. Qual-
quer usuário pode visualizar e editar qualquer página e até mesmo criar novas
páginas. Em vez de controles de acesso, um wiki fornece amplos recursos de con-
trole de versãopara que edições maliciosas possam ser facilmente desfeitas. Um
log de auditoria de edições fornece responsabilidade porque é fácil ver quem mu-
dou o quê e reverter essas mudanças, se necessário. As normas sociais se desen-
volvem para desencorajar o comportamento antissocial. Mesmo assim, grandes
wikis como a Wikipedia costumam ter algumas políticas de controle de acesso ex-
plícitas para que os artigos possam ser bloqueados temporariamente para evitar
“guerras de edição” quando dois usuários discordam fortemente ou em casos de
persistentevandalismo.
1.5.4 Log de auditoria

Umlog de auditoria é um registro de todas as operações realizadas usando sua

API. O objetivo de um log de auditoria é garantir a responsabilidade. Ele pode ser
usado após uma violação de segurança como parte de uma investigação forense
para descobrir o que deu errado, mas também analisado em tempo real por ferra-
mentas de análise de log para identificar ataques em andamento e outros compor-
tamentos suspeitos. Um bom log de auditoria pode ser usado para responder aos
seguintes tipos de perguntas:

Quem executou a ação e qual cliente eles usaram?

Quando o pedido foi recebido?
Que tipo de solicitação foi, como uma operação de leitura ou modificação?
Qual recurso estava sendo acessado?
A solicitação foi bem-sucedida? Se não, por quê?
Que outros pedidos eles fizeram na mesma época?

É essencial que os logs de auditoria sejam protegidos contra adulteração e, muitas

vezes, contêm informações de identificação pessoal que devem ser mantidas em
sigilo. Você aprenderá mais sobre o login de auditoriaCapítulo 3.

DEFINIÇÃO Informação pessoalmente identificável, ou PII, é qualquer infor-

mação relacionada a uma pessoa individual e pode ajudar a identificar essa pes-
soa. Por exemplo, seu nome ou endereço, ou sua data e local de nascimento. Mui-
tos países têm leis de proteção de dados como o GDPR, que controlam estrita-
mente como as PII podem ser armazenadas e usadas.
1.5.5 Limitação de taxa

oOs últimos mecanismos que consideraremos são para preservar a disponibili-

dade diante de ataques DoS maliciosos ou acidentais. um DoSO ataque funciona
esgotando algum recurso finito que sua API requer para atender a solicitações le-
gítimas. Esses recursos incluem tempo de CPU, uso de memória e disco, energia e
assim por diante. Ao inundar sua API com solicitações falsas, esses recursos ficam
presos atendendo a essas solicitações e não a outras. Além de enviar um grande
número de requisições, um invasor também pode enviar requisições excessiva-
mente grandes que consomem muita memória ou enviar requisições muito lenta-
mente para que os recursos fiquem presos por muito tempo sem que o cliente
mal-intencionado precise despender muito esforço.

A chave para evitar esses ataques é reconhecer que um cliente (ou grupo de clien-
tes) está usando mais do que sua parcela justa de algum recurso: tempo, memória,
número de conexões e assim por diante. Ao limitar os recursos que qualquer
usuário pode consumir, podemos reduzir o risco de ataque. Depois que um usuá-
rio é autenticado, seu aplicativo pode impor cotasque restringem o que eles po-
dem fazer. Por exemplo, você pode restringir cada usuário a um determinado nú-
mero de solicitações de API por hora, evitando que eles inundem o sistema com
muitas solicitações. Muitas vezes, há motivos comerciais para fazer isso para fins
de cobrança, bem como benefícios de segurança. Devido à natureza específica do
aplicativo das cotas, não as cobriremos mais neste livro.

DEFINIÇÃO Uma cotaé um limite no número de recursos que uma conta de

usuário individual pode consumir. Por exemplo, você só pode permitir que um
usuário poste cinco mensagens por dia.
Antes de um usuário fazer login, você pode aplicar uma limitação de taxa mais
simples para restringir o número geral de solicitações ou de um determinado en-
dereço IP ou intervalo. Para aplicar a limitação de taxa, a API (ou um balanceador
de carga) controla quantas solicitações por segundo está atendendo. Quando um
limite predefinido é atingido, o sistema rejeita novas solicitações até que a taxa
caia abaixo do limite. Um limitador de taxa pode fechar completamente as cone-
xões quando o limite é excedido ou retardar o processamento de solicitações, um
processo conhecido como limitação. Quando um DoS distribuído estiver em anda-
mento, solicitações maliciosas virão de muitas máquinas diferentes em diferentes
endereços IP. Portanto, é importante poder aplicar a limitação de taxa a todo um
grupo de clientes, e não individualmente. A limitação de taxa tenta garantir que
grandes inundações de solicitações sejam rejeitadas antes que o sistema seja com-
pletamente sobrecarregado e pare de funcionar completamente.

Limitação DE DEFINIÇÃOé um processo pelo qual as solicitações de um cliente

são retardadas sem desconectar o cliente completamente. A limitação pode ser
obtida enfileirando solicitações para processamento posterior ou respondendo às
solicitações com um código de status informando ao cliente para desacelerar. Se o
cliente não diminuir a velocidade, as solicitações subsequentes serão rejeitadas.

O aspecto mais importante da limitação de taxa é que ela deve usar menos recur-
sos do que seria usado se a solicitação fosse processada normalmente. Por esse
motivo, a limitação de taxa geralmente é executada em código altamente otimi-
zado em execução em um balanceador de carga, proxy reverso ou gateway de API
pronto para uso que pode ficar na frente de sua API para protegê-la contra Do-
Sataques em vez de ter que adicionar esse código a cada API. Algumas empresas
comerciais oferecem proteção DoS como um serviço. Essas empresas possuem
 uma grande infraestrutura global capaz de absorver o tráfego de um ataque DoS e
bloquear rapidamente clientes abusivos.

No próximo capítulo, colocaremos a mão na massa com uma API real e aplicare-
mos algumas das técnicas discutidas neste capítulo.

questionário

6. Contra qual das ameaças STRIDE a limitação de taxa protege?

1. Falsificação
2. adulteração
3. Repúdio
4. Divulgação de informação
5. Negação de serviço
6. Elevação de privilégio
7. O padrão WebAuthn ( https://www.w3.org/TR/webauthn/ ) permite que chaves
de segurança de hardware sejam usadas por um usuário para autenticação em
um site. Qual dos três fatores de autenticação da seção 1.5.1 melhor descreve
esse método de autenticação?

As respostas estão no final do capítulo.

Respostas para perguntas do questionário

1. c,e, e f. Embora outros aspectos da segurança possam ser relevantes para dife-
rentes APIs, essas três disciplinas são a base da segurança da API.
2. d. Um gateway de API é um tipo especializado de proxy reverso.
3. Confidencialidade, Integridade e Disponibilidade.
 4. b. Os fluxos de dados que ultrapassam os limites de confiança são o local mais
provável para a ocorrência de ameaças. As APIs geralmente existem em limites
de confiança.
5. Repúdio. Ao desabilitar o log de auditoria, o administrador do sistema invasor
poderá posteriormente negar a execução de ações no sistema, pois não haverá
registro.
6. e. A limitação de taxa protege principalmente contra ataques de negação de
serviço, impedindo que um único invasor sobrecarregue a API com
solicitações.
7. Uma chave de segurança de hardware é algo que você tem. Eles geralmente
são pequenos dispositivos que podem ser conectados a uma porta USB do seu
laptop e podem ser conectados asuachaveanel.

Resumo

Você aprendeu o que é uma API e os elementos de segurança da API, com base
em aspectos de segurança da informação, segurança de rede e segurança de
aplicativos.
Você pode definir a segurança de sua API em termos de ativos e metas de
segurança.
Os objetivos básicos de segurança da API são confidencialidade, integridade e
disponibilidade, bem como responsabilidade, privacidade e outros.
Você pode identificar ameaças e avaliar riscos usando estruturas como
STRIDE.
Mecanismos de segurança podem ser usados ​para atingir seus objetivos de se-
gurança, incluindo criptografia, autenticação, controle de acesso, log de audito-
ria elimitador de taxa.
1.
Nesse contexto, o termo mais recente TLS raramente é usado.