Proteger APIs públicas contra abuso

Uma equipe de API ou de segurança expõe APIs públicas, móveis ou de parceiros a partir do seu próprio gateway, cloud ou data center. Ela vê scraping, uso indevido de tokens, abuso de credenciais e ondas de requisições que sobrecarregam o backend, e cada uma dessas requisições chega à origem da API antes que algo a inspecione. Esta página configura um firewall na frente da API que pontua cada requisição com WAF, verifica o seu token, pontua clientes automatizados e limita a taxa de cada cliente, e envia os eventos de segurança ao SIEM da equipe. O resultado é medido pela parcela de requisições abusivas bloqueadas antes da origem, pela taxa de erros do backend durante um ataque e pelo tempo entre a detecção e um novo bloqueio.

Este caso de uso não cobre o design nem a gestão do ciclo de vida de APIs, nem o account takeover em fluxos de login, que Bloquear account takeover em fluxos de login e checkout cobre.

Pré-requisitos

• Uma application que serve a API por meio de um connector e de um workload. Para criá-los, consulte Primeiros passos com Applications.
• Um firewall vinculado ao deployment desse workload, com WAF e Functions ativados em Main Settings › Modules. Para vinculá-lo, consulte Vincule um firewall a um workload, e para ativar o WAF, consulte Defina as configurações principais de um firewall.
• A função JWT instalada pelo Azion Marketplace. Para instalá-la, consulte Use a integração JWT no Marketplace da Azion.
• Bot Manager habilitado na conta, ou Bot Manager Lite instalado pelo Azion Marketplace. Para instalar o Bot Manager Lite, consulte Instale o Bot Manager Lite.
• Os pares de key ID e secret key com que o emissor dos seus tokens assina os tokens.
• Um personal token, para as abas de API. Para criar um, consulte Gerencie personal tokens.
• Os valores da sua API. Esta página usa api.example.com como domínio, /v1/ como o caminho com que toda rota da API começa e api como prefixo de cada objeto que cria. Substitua cada valor pelo seu em todos os passos.

Produtos necessários

Arquitetura de referência

Esta página constrói o perímetro de segurança de APIs: um firewall no workload da API que filtra cada requisição por regras, tokens, scores de bot e taxas antes que o connector a encaminhe à origem da API.

Leia o diagrama nas regras do firewall. A conexão já foi aceita quando uma requisição chega a elas, então cada verificação age sobre uma requisição, não sobre a identidade de um cliente: regras, um token, um score de bot e uma taxa. Cada verificação age pela regra que a chama, então a ordem das regras é a ordem das verificações. Só uma requisição que passa por todas chega à application, que responde as requisições GET seguras a partir do Cache e envia as demais à origem da API.

Fluxo de dados

1. A requisição de um cliente da API a api.example.com/v1/ chega ao workload. DDoS Protection a avalia antes que qualquer regra de firewall rode, e o firewall vinculado ao workload roda então as suas regras em ordem.
2. O WAF rule set pontua a requisição, incluindo o seu corpo JSON. Em Blocking, uma requisição cujo score atinge um threshold recebe 400.
3. A função JWT verifica o token que a requisição carrega no seu header Authorization. Uma requisição cujo token é inválido recebe 400 ou 401.
4. A instância do Bot Manager pontua o cliente em busca de automação. Quando a sua action é deny, um score no threshold recebe 403.
5. O rate limit conta as requisições de cada endereço IP de cliente, e uma requisição além do burst recebe 429.
6. Uma requisição que passa chega à application. Uma resposta GET cacheável vem do Cache, e toda outra requisição chega à origem da API pelo connector. Data Stream envia ao SIEM as requisições que o WAF analisou, e Real-Time Events guarda o registro de cada requisição, ligado a uma recusa pelo seu x-azion-request-id.

Componentes

• firewall: o Platform Resource que é o ponto de aplicação. As suas regras rodam o WAF, as funções e o rate limit por cliente na ordem que as regras definem, e Set Rate Limit é um dos seus comportamentos integrados.
• DDoS Protection: a Feature que mitiga ataques DoS e DDoS em todo workload, sempre ativa, antes que qualquer regra de firewall rode.
• WAF: pontua cada requisição contra oito famílias de ameaças e recusa padrões de ataque em Blocking. Ele faz o parsing de corpos JSON, então lê os campos que uma API recebe.
• Bot Manager: pontua cada requisição em busca de automação. O seu modo api é documentado para clientes que não carregam cookies, que é como a maioria dos clientes de API se comporta.
• Functions: roda a verificação de token no firewall, como a função JWT do Azion Marketplace, e qualquer verificação personalizada que a equipe escreva no ambiente de execução firewall.
• application: o Platform Resource que roteia as requisições que o firewall deixa passar e decide quais respostas o Cache pode responder.
• Cache: responde as respostas GET seguras, para que leituras repetidas nunca cheguem à origem da API.
• connector: o Platform Resource que alcança a origem da API. Toda requisição que passa pelo firewall e não encontra a resposta no Cache termina nele.
• Data Stream: envia as requisições que o WAF analisou, com o seu score, as regras correspondidas e a action, a um endpoint que o SIEM lê.
• SIEM: a integração que correlaciona os eventos de segurança da API com as outras fontes da equipe.
• Real-Time Events: guarda o registro de cada requisição, para que o relato de uma recusa feito por um cliente possa ser rastreado até a regra que a decidiu.

Outros designs para este caso de uso

• Perímetro de mutual TLS para APIs de parceiros: atende integrações B2B e de parceiros em que todo cliente é conhecido. O workload exige um certificado de cliente assinado por uma autoridade certificadora que a equipe registra no Certificate Manager, então quem chama sem um certificado válido é recusado durante o handshake TLS, antes que qualquer requisição exista, e o firewall aplica depois regras de WAF e rate limits por parceiro.

Configure o WAF nos caminhos da API

O rule set api-waf pontua as oito famílias de ameaças na sensibilidade medium, o nível em que toda família começa. A regra que o aplica corresponde a ${request_uri} starts with /v1/, então o WAF pontua só a API: o WAF é cobrado pelas requisições que pontua, e o restante do domínio não precisa de uma política específica de API. O WAF faz o parsing de um corpo de POST enviado como application/json, então lê cada campo de um payload JSON.

A regra começa em Logging. Clientes de API enviam corpos bem formados com mais frequência do que navegadores enviam corpos incomuns, mas uma integração que envia, por exemplo, um apóstrofo em um campo se transforma em erros 400 em Blocking. Mude a regra para Blocking quando 3 dias de Tuning não tiverem nenhuma requisição que deveria ter sido servida.

Toda requisição a /v1/ é pontuada contra api-waf, e o que seria bloqueado é registrado. Para mudar a regra para Blocking, consulte Mude um rule set para blocking.

Configure a verificação de token

A função JWT roda no firewall, então uma requisição sem um token válido é recusada antes de chegar à origem da API, e a origem nunca contata um autenticador por ela. O token viaja no header Authorization da requisição, no esquema Bearer. Os argumentos da instância carregam os pares de key ID e secret key com que o emissor dos seus tokens assina, para que a função possa verificar uma assinatura sem chamar o emissor. A integração JWT é configurada no Azion Console.

Para instanciar a função JWT:

Para executá-la nos caminhos da API:

Uma requisição a /v1/ com um token inválido recebe 400 ou 401, dependendo do erro. Uma rota que a sua API serve sem token precisa do seu próprio caminho fora de /v1/, ou de um critério que a exclua desta regra.

Configure o Bot Manager para clientes de API

Clientes de API não carregam cookies, então a instância define mode como api, que o Bot Manager documenta para web services e tráfego de API sem cookies. O Bot Manager Lite não documenta nenhum mode, e a sua função ignora a chave. A instância começa em modo de observação: action é allow e internal_logs é 2, então toda requisição é pontuada, servida e gravada no report log. threshold é 15, o ponto de partida que as Boas práticas de Firewall dão para endpoints de API, e enquanto action for allow ele só define o rótulo classified de cada linha. log_tag é api-bots, então cada linha nomeia esta instância.

Crie a instância e a regra como Execute Bot Manager em caminhos selecionados descreve, com estes valores:

• Instância: api-bots, com estes argumentos:

  { "mode": "api", "threshold": 15, "action": "allow", "internal_logs": 2, "log_tag": "api-bots" }

• Regra: api - score clients, com um bloco de critérios: Request Uri starts with /v1/.

• Comportamento: Run Function com api-bots.

Toda requisição a /v1/ grava uma linha de report marcada com api-bots. Depois de 24 a 72 horas, leia os scores dos clientes que você reconhece, defina threshold no intervalo entre eles e os clientes automatizados e defina action como deny. Um cliente pontuado no threshold recebe então 403. Um cliente de API não consegue responder a um desafio, então deny se encaixa melhor nestes caminhos do que redirect. Para o procedimento, consulte Recuse requisições acima do threshold.

Configure o rate limit por cliente

O rate limit conta as requisições por endereço IP de cliente em /v1/, a 10 requisições por segundo com um burst de 10. As requisições acima da taxa entram em fila e são liberadas na taxa, e só as requisições simultâneas além do burst recebem 429. Um burst de no máximo dez vezes a taxa mantém a fila em 10 segundos de tráfego, então o pico de um cliente legítimo é atrasado em vez de recusado. Defina average_rate_limit a partir da taxa de requisições que o seu cliente legítimo mais pesado envia.

Os caminhos da API já carregam uma regra Set WAF, e as regras de token e de Bot Manager precisam rodar antes do limite, então Set Rate Limit fica em uma regra própria. Crie a regra como Aplique WAF e um rate limit a um caminho descreve para um limite em uma regra própria, depois das regras de WAF, de token e de Bot Manager, para que ela ocupe a última posição nos caminhos da API. Use estes valores:

• Nome: api - rate limit per client.

• Critério: Request Uri starts with /v1/.

• Comportamento: Set Rate Limit sozinho, com Req/s, Client IP address, um Average Rate Limit de 10 e um Maximum Burst Size de 10. Na API, o comportamento é:

  { "type": "set_rate_limit", "attributes": { "type": "second", "limit_by": "client_ip", "average_rate_limit": 10, "maximum_burst_size": 10 } }

Cada endereço IP de cliente pode enviar 10 requisições por segundo a /v1/, com um pico de mais 10 em fila. A taxa se aplica em cada data center, e nenhuma resposta carrega um header de rate limit, então um cliente não tem nenhum sinal de quanto tempo esperar.

Verifique a configuração

Uma regra nova chega ao tráfego de 6 a 10 minutos depois de salva, e os argumentos de uma instância cerca de 105 segundos depois de alterados. Repita cada requisição até a resposta se manter.

• Uma requisição sem token válido é recusada. Envie uma requisição sem header Authorization:

  curl -s -o /dev/null -w '%{http_code}\n' https://api.example.com/v1/orders

  O comando imprime 400 ou 401. A mesma requisição com um header Authorization: Bearer <token> válido chega à API.

• O WAF pontua um padrão de ataque. Com um token válido, envie uma query string com formato de injeção:

  curl -i -H "Authorization: Bearer <token>" "https://api.example.com/v1/orders?q=1%27%20OR%20%271%27%3D%271"

  Em Logging, a API responde como de costume. Depois da mudança para Blocking, a mesma requisição recebe:

  HTTP/2 400

  O seu x-azion-request-id encontra o registro no Real-Time Events.

• O Bot Manager pontua clientes de API. Envie uma requisição com um token válido e sem user agent:

  curl -A "" -H "Authorization: Bearer <token>" https://api.example.com/v1/orders

  O dataset functionConsoleEvents do Real-Time Events guarda uma linha que começa com [Bot-Protection][api-bots] Report:, com o score e o matched_rules da requisição.

• Uma onda de requisições de um cliente é limitada. A partir de um endereço, envie 30 requisições simultâneas:

  seq 30 | xargs -P 30 -I{} curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer <token>" https://api.example.com/v1/orders

  Algumas respostas imprimem 429: as requisições simultâneas além do burst de 10.

• Respostas cacheáveis não chegam à origem. Requisite duas vezes uma rota que a sua cache setting cobre, com o header Pragma: azion-debug-cache. A segunda resposta carrega x-cache: HIT. Para saber como lê-lo, consulte Verifique o status de cache de uma resposta.

• Os eventos de segurança chegam ao SIEM. No Real-Time Events, a fonte de dados Data Stream lista cada envio do stream, e um Status Code 200 significa que o endpoint do SIEM aceitou o lote.

Medindo resultados

Boas práticas

• Corresponda aos caminhos da API, não à query string. ${request_uri} starts with /v1/ corresponde a toda requisição da API, com ou sem query string. ${request_args} matches .* deixa de fora todo POST cujo payload está no corpo, o que em uma API é a maioria deles.
• Envie JSON bem formado com um content type correspondente. Em Blocking, o WAF recusa com 400 um POST com Content-Type ausente ou não interpretado, um corpo JSON que não passa no parsing ou um corpo acima de 131.072 bytes. Um bug de cliente parece então um ataque. Para os formatos que o WAF interpreta, consulte Parsing do corpo da requisição.
• Escreva threshold e action em toda instância do Bot Manager. O Bot Manager Lite traz deny em 30, e o Bot Manager documenta allow em Infinity, então uma instância que não define nenhum dos dois recusa requisições em uma edição e as deixa passar na outra.
• Negue clientes de API em vez de redirecioná-los. Um redirect envia o cliente a um desafio que uma pessoa resolve, e um consumidor de API, um health check ou um monitor não consegue resolvê-lo.
• Mantenha o burst em até dez vezes a taxa. Um burst menor que os picos dos seus clientes recusa requisições simultâneas legítimas, e um maior atrasa por mais tempo a última delas. Para o raciocínio, consulte Mantenha o burst de um rate limit em até dez vezes a taxa média.

Guias deste caso de uso