0
0
As empresas que procuram modernizar suas APIs estão mudando cada vez mais da arquitetura REST para a consulta de dados de código aberto e a linguagem de manipulação GraphQL. Embora a transição faça sentido – o GraphQL é mais flexível, escalável e mais fácil de usar para os desenvolvedores – os invasores também estão vendo novas oportunidades de travessuras. As equipes de desenvolvedores devem evitar o erro que muitas organizações cometem com o Kubernetes: correr para uma tecnologia nova, vantajosa e amigável ao desenvolvedor, deixando as considerações de segurança em segundo plano.
Aqueles que se encontram dentro do movimento GraphQL liderado pelo desenvolvedor devem entender as ameaças atuais que enfrentam e reconhecer que o GraphQL aumenta suas próprias responsabilidades de segurança. As empresas que se apressam em adotar o GraphQL sem implementar uma estratégia de segurança correm um alto risco de sofrer consequências desagradáveis, especialmente à medida que escalam.
Vejamos os principais pontos fracos de segurança do GraphQL que os invasores tentarão explorar e como os desenvolvedores e suas organizações podem minimizar os riscos.
O que os dados de vulnerabilidade do GraphQL estão dizendo agora
Os dados de vulnerabilidade provenientes do banco de dados MITRE CVE e do portal HackerOne Hacktivity oferecem informações valiosas sobre como os invasores procuram se infiltrar no GraphQL e como as equipes de desenvolvedores, DevOps e DevSecOps devem configurar sua defesa. A análise a seguir analisa de perto as explorações de vulnerabilidade disponíveis para invasores em servidores GraphQL, clientes e componentes adicionais.
Embora não seja abrangente, o banco de dados MITRE CVE fornece uma fonte de dados robusta o suficiente para ser muito útil para entender as vulnerabilidades do GraphQL. Olhando para as 45 vulnerabilidades rastreadas do GraphQL do banco de dados (a primeira identificada em 2019), as vulnerabilidades de bypass de autorização representam uma clara maioria, respondendo por 54,8% do total. As vulnerabilidades de negação de serviço (DoS) seguem com 16,7%. Completando as classes de vulnerabilidade reconhecidas, 9,5% das vulnerabilidades estão relacionadas à divulgação de informações, 7,1% à execução de código, 7,1% à falsificação de solicitação entre sites e 4,8% à injeção.
Os dados mais recentes do portal Hacktivity, que coleta vulnerabilidades relatadas por pesquisadores, revelam descobertas semelhantes. Esses dados mostram uma proeminência ainda maior dos riscos de bypass de autorização, com 87% das vulnerabilidades GraphQL conhecidas caindo nessa classe. As vulnerabilidades DoS ocupam o segundo lugar com 7%. As vulnerabilidades de condição de corrida e gerenciamento de sessão representam 2,8% cada.
A natureza baseada em recompensas de bugs do portal Hacktivity pode distorcer esses resultados até certo ponto: vulnerabilidades de autorização podem colocar diretamente em risco dados confidenciais, ganhando recompensas premium para pesquisadores. O teste de vulnerabilidades DoS também é amplamente proibido, pois esse teste pode causar danos reais, provavelmente reduzindo o número dessas vulnerabilidades representadas nesses dados.
Essas descobertas deixam claro que os desenvolvedores que usam o GraphQL devem proteger suas implantações implementando um controle de acesso baseado em esquema eficaz para limitar o acesso por função e combater os ataques de desvio de autorização. A limitação de taxa dinâmica também deve estar em vigor para derrotar ataques DoS. Apoiar esses recursos com análises granulares e manter logs de atividades para visibilidade robusta garantirá ainda mais que as equipes possam impedir o comportamento não autorizado antes que os invasores possam causar danos.
O reconhecimento do invasor da API GraphQL pode denunciar os invasores
Os invasores têm métodos sofisticados e automatizados para estimular implantações do GraphQL em busca de pontos fracos de segurança. Pesquisa passiva em uma organização, consultas inócuas para avaliar o comportamento do aplicativo e localização de APIs GraphQL por simples dedução fazem parte da caixa de ferramentas de um invasor no momento. Ao fazer isso, eles estão identificando as tecnologias em uso e mais pistas sobre como moldar um ataque bem-sucedido.
Essas atividades do invasor não são detectadas porque os gateways de segurança da API padrão não fazem nada para contextualizar as consultas de solicitação GraphQL recebidas. Isso representa um ponto cego para as equipes que trabalham com APIs e aumenta significativamente o risco de falhas de conformidade.
Por exemplo, se os desenvolvedores acidentalmente deixarem credenciais de acesso dentro do código disponível em repositórios públicos, os invasores que as descobrirem terão bons motivos para comemorar. As consultas do GraphQL enviadas para um aplicativo, mesmo que inválidas, informarão aos invasores se o GraphQL está em uso. Os invasores também podem consultar automaticamente vários pontos de extremidade onde o GraphQL provavelmente residirá (como /graphql, /query, /api, /playground, /console e /graphiql) e as respostas do servidor informarão aos invasores quando eles encontrarem o que estão procurando. está procurando.
Mas as consultas automatizadas nas quais os invasores confiam aparecerão como comportamento anômalo se a estratégia de segurança GraphQL correta estiver em vigor. Ao implementar proteções que sinalizam consultas inválidas e tráfego em massa direcionado a vários endpoints — muitos dos quais não existem —, desenvolvedores e organizações podem detectar e bloquear (ou mitigar) ataques antes que as explorações aumentem.
Limitar a taxa do número de solicitações de objeto e operações que um aplicativo pode fazer é uma medida eficaz para proteger os endpoints da API GraphQL (e deve ser feito no nível do objeto, não no nível da chamada). Os invasores podem jogar o jogo de detecção e encontrar alvos GraphQL maduros, mas as equipes com a segurança certa podem jogá-lo melhor e interromper os ataques.
A segurança do GraphQL exige priorização
Para organizações que usam o GraphQL, é crucial entender a natureza das ameaças específicas às APIs e aplicativos do GraphQL e ter medidas de segurança específicas preparadas para lidar com esses riscos.
Proteger o GraphQL só é difícil se não receber a prioridade que merece desde o início da adoção. Com a estratégia e os processos corretos monitorando ativamente o tráfego em busca de atividades anômalas enquanto protegem o controle de acesso (e outras vias de ataque conhecidas), os desenvolvedores podem aproveitar com segurança os benefícios do GraphQL que procuram – e fazê-lo em escala.
FONTE: HELPNET SECURITY