Segurança no seu pipeline de DevOps

No desenvolvimento de software e nos seus processos DevOps - desde a conceção até à implementação - a segurança tem de estar na vanguarda da sua mente. Se não pensar nisso, os incidentes de segurança voltarão para o atormentar.

Neste post, vamos abordar um descuido comum, mas crítico, cometido por desenvolvedores de APIs GraphQL - a habilitação de recursos de introspeção em ambientes de produção. A introspeção é um recurso incrível para entender e testar os recursos da sua API quando você está no estágio de desenvolvimento. Mas se você não a desabilitar antes de entrar em produção, você abre seu aplicativo para vulnerabilidades significativas. Discutiremos como isso pode se transformar em um grande risco de segurança, juntamente com as etapas preventivas que você pode tomar para reforçar a segurança em seu pipeline de DevOps.

O cenário

Imagine uma equipa de desenvolvimento a liderar a implementação da API GraphQL da sua organização. GraphQL é uma poderosa linguagem de consulta projetada para permitir que os clientes solicitem exatamente o que precisam em uma única consulta. Isso é diferente das APIs REST tradicionais que podem exigir várias solicitações para reunir dados e relacionamentos complexos. A estrutura dos dados no GraphQL é definida em um esquema, que descreve os tipos de dados, as consultas e as mutações disponíveis.

A equipa de desenvolvimento empenhou-se num esforço enorme e construiu algo bastante impressionante. Esta API não é apenas robusta; é escalável, capaz de lidar com milhões de transacções por minuto, tudo graças às capacidades de auto-escalonamento que a equipa concebeu e construiu. Com o foco no desempenho e na escalabilidade, eles garantiram que essa API possa lidar com uma carga enorme sem nenhum problema.

No entanto, na pressa de implantar e impressionar com essa nova e brilhante API GraphQL, eles esqueceram um pequeno detalhe - a introspeção ainda está ativada no ambiente de produção. A introspeção é uma ferramenta poderosa para os desenvolvedores, dando a eles uma maneira de consultar quais recursos estão disponíveis na API. Só que não é algo que deva ser aberto para acesso na produção.

Quais são as consequências?

Bem, à medida que a API se expande para satisfazer a procura, cada nova instância multiplica o risco potencial. Agora, a vulnerabilidade de segurança significativa espalhou-se por um número crescente de nós. Com isso, preparámos o terreno para uma potencial exploração por parte de maus actores. Eles têm tudo o que precisam para descobrir informações detalhadas sobre a estrutura e a capacidade dessa nova e brilhante API.

Ao esquecer-se de um simples botão, a equipa transformou uma funcionalidade bem-intencionada numa falha de segurança.

Compreender a vulnerabilidade

Com a introspeção ativada, um desenvolvedor pode consultar a API GraphQL para ver o esquema completo - com todos os seus tipos de dados, campos, consultas e mutações. Isso é como ter um mapa detalhado de todos os pontos de extremidade operacionais e estruturas de dados de uma API. É um ótimo recurso para ter nas mãos de um programador. Mas não é algo que se queira colocar nas mãos de um ciberatacante.

Considere como um invasor pode explorar os recursos de introspeção para aprender sobre sua API GraphQL. Primeiro, ele pode definir Fragmentos para tornar os resultados da consulta mais amigáveis para leitura.

Depois, podem enviar uma consulta para introspeccionar o __schema que está disponível no tipo de raiz de uma consulta. A consulta GraphQL pode ter a seguinte aparência:

Ao enviar essa consulta, juntamente com as definições de fragmento, para uma API GraphQL com introspeção activada, um atacante receberá uma resposta com um objeto JSON abrangente com todos os detalhes da sua API. Em seguida, ele pode usar uma ferramenta como o GraphQL Voyager para mostrar a API GraphQL como um gráfico interativo.

Aqui está um exemplo de visualização de uma API GraphQL com base na resposta à consulta de introspeção que mostramos acima:

Como pode ver, isto revela muita da estrutura e detalhes relacionados com operações de pagamento sensíveis. Esta é uma informação extremamente útil para um atacante que tenta penetrar na sua API. Mais uma vez, ótimo para os programadores e, infelizmente, também ótimo para os atacantes.

Quando se deixa a introspeção activada na produção, eis os riscos que se correm:

• Exposição de informações: As informações detalhadas sobre o esquema podem fornecer aos atacantes informações sobre os seus sistemas de backend, modelos de dados e lógica empresarial. Ao entregar-lhes as plantas do seu castelo, facilita-lhes a criação de ataques direcionados.
• Facilitação de ataques: Armados com estes detalhes sobre a sua API, os atacantes podem criar consultas que exploram vulnerabilidades. Isto pode levar a violações de dados ou interrupções de serviço.
• Drenagem de recursos: Os atacantes também podem utilizar este conhecimento para criar consultas maliciosas como ataques de negação de serviço (DoS). Estes ataques irão drenar recursos e potencialmente fazer com que o seu sistema fique completamente em baixo.

Mas não desespere! Os passos para mitigar este risco são simples e diretos. Como primeiro passo para nos protegermos, vamos ver o que a OWASP tem a dizer.

Orientação da folha de dicas do OWASP GraphQL

O OWASP GraphQL Cheat Sheet é um recurso valioso para proteger suas APIs GraphQL. Ele fornece orientação para ajudá-lo com as seguintes áreas:

• Validação de entradas
• Limitar ou evitar consultas dispendiosas
• Garantir verificações adequadas do controlo de acesso
• Desativação de configurações inseguras, como a introspeção

A folha de dicas tem uma secção dedicada à Introspeção e ao GraphiQL. O GraphiQL é um IDE no navegador para explorar o GraphQL. Semelhante aos recursos de introspeção, o GraphiQL pode expor informações detalhadas sobre o funcionamento interno e o design da sua API.

Se estiver a construir uma API GraphQL, recomendamos que se familiarize com a folha de consulta OWASP.

Como atenuar a vulnerabilidade de segurança Introspeção

Seguindo as dicas da folha de dicas do OWASP, vamos seguir as instruções para desativar as consultas de introspeção em ambientes de produção ou acessíveis ao público. Isso é fundamental para evitar o acesso não autorizado a informações detalhadas do esquema que podem ser exploradas por invasores.

Como é que o fazemos?

Aqui está um trecho de código simples em JavaScript que demonstra como desativar a introspeção na produção se você usar o Apollo Server:

Sim, é basicamente isso que está em causa. Este simples passo (definir introspection para false ao configurar uma nova instância do ApolloServer) impedirá os utilizadores de acederem a informações detalhadas do esquema através de consultas de introspeção. Isto reduzirá o risco de fuga de informações sensíveis.

Tornar isto uma parte do seu pipeline de DevOps seguro

Se o passo é tão simples, porque é que os programadores se esquecem dele com tanta frequência? Porque estão concentrados noutras coisas e ocupados a tentar cumprir prazos críticos. Não é de surpreender que definições de configuração aparentemente menores sejam esquecidas ocasionalmente.

É por isso que temos testes automatizados e o pipeline DevOps - para nos protegermos contra o erro humano e o esquecimento.

Como é que pode integrar esta medida de segurança na sua cadeia de DevOps? Aqui estão duas sugestões:

• Escreva um teste de pré-implantação que verifique explicitamente a configuração do servidor GraphQL para garantir que a introspeção seja desativada na implantação da produção.
• Escreva um teste pós-implantação que tente uma consulta de introspeção no ambiente de produção. Quando sua tentativa é recebida por uma resposta de erro (como Cannot query field '__schema' on type 'Query'), então o seu teste deve passar.

Aproveite as ferramentas de pipeline de CI/CD como Jenkins, GitHub Actions ou CircleCI para executar scripts que verificarão suas configurações de API GraphQL como parte do processo de CI/CD.

Conclusão

Criar APIs GraphQL pode ser uma ótima maneira de sua empresa inovar, mas exige que você seja proativo em relação às suas práticas de segurança. Um pequeno deslize pode expor sua API a grandes vulnerabilidades. Neste post, cobrimos um excelente exemplo disso: desativar a introspeção para implantações de produção, para que os invasores não tenham acesso a informações detalhadas sobre seu esquema GraphQL.

Para obter mais orientações e recursos, confira a biblioteca abrangente da Linode de guias relacionados à segurança, desenvolvimento do GraphQL e https://www.linode.com/docs/guides/platform/.