0
0
Existem alguns motivos pelos quais o tópico de segurança da API está surgindo cada vez mais à medida que 2022 chega ao fim.
Em julho de 2021, o Gartner previu que, até 2022, os ataques à interface de programação de aplicativos (API) se tornariam o vetor de ataque mais frequente, causando violações de dados para aplicativos da Web corporativos.
O analista estava certo? É muito cedo para saber com certeza, já que o OWASP ainda está contabilizando os resultados .
Os ataques à API estão de volta aos noticiários. Acontece que o provável ponto de entrada para a violação do Optus foi uma API REST inferior. E alguém vazou todos os dados roubados da violação do Twitter – que também envolveu uma API.
Quando falamos de segurança de API , estamos nos referindo às medidas e práticas que usamos para proteger as APIs e os dados que elas transmitem. Podemos estar preocupados com o acesso não autorizado, uma reação adversa a uma negação de serviço distribuída (DDoS) — mais de uma API caiu e deixou o sistema subjacente totalmente aberto e inseguro — ou outros ataques maliciosos.
É uma arte proteger APIs; um toque leve e uma combinação delicada de habilidades técnicas e organizacionais são necessárias para fazer isso direito.
Do lado técnico, estamos analisando medidas como autenticação e autorização, criptografia, teste automatizado e monitoramento. No lado organizacional, você precisa saber exatamente a quem no organograma a API foi projetada para atender e adaptar o acesso de acordo. Para APIs externas, você precisa saber quantos dados devem estar disponíveis para o mundo externo e como esses dados precisam ser selecionados e apresentados.
Como as APIs são protegidas?
Há uma ordem sã de operações quando você está tentando proteger as APIs da sua empresa.
Primeiro, encontre e catalogue todas as APIs. O número de empresas que realmente fazem isso e mantêm seu inventário de API atualizado é realmente pequeno. A conveniência do desenvolvedor, o desenvolvimento rápido de sites e o crescente impulso em direção a serviços federados contribuem para que APIs misteriosas surjam do nada, sem qualquer tipo de estrutura de registro compulsório.
Para evitar esse tipo de API creep, cada um deles deve ser registrado centralmente com as seguintes informações:
- Nome
- Ferramentas e pacotes usados para construir a API
- Servidores nos quais ele é executado
- Serviços que dependem dessa API
- Documentação de todos os usos válidos e códigos de erro
- Métricas de desempenho típicas
- Tempo de atividade esperado ou janelas de tempo de inatividade
Todas essas informações vão para um repositório administrado pela equipe de segurança cibernética.
Em segundo lugar, configure a automação de segurança e desempenho para cada API. É por isso que você pediu todas essas informações e é assim que você mantém tudo seguro. Usando os dados fornecidos pelos desenvolvedores (e equipe de DevOps, equipe da Web etc.), a equipe de cibersegurança e/ou teste pode montar automação que testa a API regularmente.
Os testes funcionais são importantes porque garantem que tudo está funcionando conforme o esperado. Os testes não funcionais são importantes porque eles investigam a confiabilidade e a segurança da API. Lembre-se de que as APIs devem falhar com segurança. Não basta saber que alguém caiu – você precisa saber as consequências dessa falha.
Por fim, adicione a API ao conjunto normal de prevenção contra ameaças. Se alguma das ferramentas ou pacotes usados para construir a API apresentar erros, você precisa saber. Se algum dos protocolos usados for considerado inseguro quando você detectar problemas, será necessário que a equipe desligue as APIs até que possam ser examinadas e reconstruídas.
Realizar essas ações uma vez é ótimo; criar uma cultura de programação e segurança que permita manter APIs totalmente catalogadas e documentadas é o objetivo de longo prazo.
Comportamentos específicos da API a serem observados
Ao fazer testes de penetração e proteger uma API, algumas técnicas são mais úteis do que outras.
- Comece com a análise comportamental. Isso testa se a realidade corresponde à documentação em termos de nível de acesso concedido, protocolos e portas utilizadas, resultados de consultas bem-sucedidas e malsucedidas e o que acontece com o sistema como um todo quando a própria API para de funcionar.
- Em seguida são os níveis de serviço. Isso envolve a prioridade do próprio processo no servidor, limitação de taxa para APIs transacionais, configurações mínimas e máximas de latência de solicitação e janelas de disponibilidade. Alguns desses detalhes são importantes para a prevenção de DDoS (ou embotamento). Outros são úteis para monitorar se há algum vazamento lento de memória ou problemas de coleta de lixo que possam ser uma ameaça de longo prazo à integridade do próprio servidor.
- Problemas de autenticação e saneamento falam diretamente sobre o nível de confiança que você tem para os usuários da API. Como você faria com qualquer serviço, as consultas precisam ser sanitizadas antes de serem aceitas. Isso evita injeção de código, estouros de buffer e coisas do tipo.
É necessário haver algum nível de autenticação com APIs projetadas para uma base de usuários específica. No entanto, isso pode se tornar complexo. A federação é um problema com o qual você precisa lidar, determinando quais servidores centrais de identificação e autenticação você aceitará. Você pode querer ter autenticação de dois fatores para APIs particularmente sensíveis ou poderosas. E, claro, a autenticação em si não é necessariamente uma senha hoje em dia; a biometria é uma maneira válida de bloquear uma API. Para encurtar a história: aplique os padrões que você considera razoáveis e teste as limitações que você estabeleceu regularmente.
Por fim, a criptografia e as assinaturas digitais precisam fazer parte da conversa. Se estiver na Web, estamos falando de TLS no mínimo. (Repita o mantra: não descansamos sem TLS!) Outras interfaces também precisam de criptografia, então escolha seus protocolos com sabedoria. Lembre-se de que informações estáticas, seja um banco de dados ou um pool de arquivos em algum lugar, também precisam ser criptografadas. Nenhum arquivo de texto plano em qualquer lugar, não importa o quão “inocente”; sal e haxixe devem ser o padrão. E as somas de verificação são obrigatórias ao fornecer ou receber arquivos que são entidades conhecidas (tamanho, conteúdo, etc.).
Finalmente, o gerenciamento de chaves pode ser difícil de acertar. Não espere que cada pessoa de DevOps tenha uma implementação de chave digital perfeita quando uma parte decente do pessoal de segurança cibernética está fazendo meia-boca. Em caso de dúvida, volte para a folha de dicas OWASP ! É para isso que existe.
Respondendo a um ataque de API
A regra fundamental é: se sua API falhar, bloqueie o acesso. Sob nenhuma circunstância os serviços devem falhar em um estado aberto ou acessível. Lembre-se de limitar a taxa e manter as mensagens de erro curtas e genéricas. Não se preocupe com potes de mel ou prisões de API – preocupe-se com a sobrevivência.
Ataques de API personalizados em uma base individual precisam ser tratados como qualquer outra tentativa de violação. Se você detectou a tentativa por conta própria ou por meio de análise AI/ML, siga seu SOP. Não economize porque é “apenas” uma API.
A segurança da API separa o CISO medíocre, que se concentra apenas na infraestrutura, do CISO magistral, que aborda ameaças comerciais reais e garante a capacidade de sobrevivência. Crie um sistema para segurança de API, crie automação de teste de interface reutilizável e mantenha seu inventário de API atualizado.
FONTE: DARK READING