Segurança no Node.js: lições do grupo de segurança do Node.js na triagem de vulnerabilidades

Em uma publicação anterior do blog, falei sobre uma divulgação de segurança do framework Fastify Node.js ao grupo de segurança do Node.js no HackerOne. A divulgação tratava de uma vulnerabilidade de injeção de código JavaScript no servidor. Ao final, concluiu-se que o relato não representava risco de segurança para o framework de aplicações web Node.js Fastify nem para seu componente de validação de esquema JSON fast-json-stringify.

Por que um relato de segurança deixaria de ser classificado como tal?

Para responder, vamos analisar rapidamente as conclusões do relato e identificar alguns dos desafios enfrentados pela equipe de resposta a incidentes do grupo de segurança do Node.js.

O relato de segurança descrevia um ataque de injeção de código que ocorre quando um invasor consegue manipular um arquivo JSON usado como esquema para a lógica de validação de uma requisição. A prova de conceito confirmou o problema de segurança ao abrir um shell reverso.

No entanto, isso não constituiu, por si só, um problema de segurança no Fastify, como o mantenedor do projeto apontou desde o início. Essa vulnerabilidade de segurança não ocorre de forma dinâmica nem é causada por um bug de segurança no próprio código do framework. O problema só acontece quando código não confiável é usado como esquema de validação JSON — algo que, na maioria das vezes, é escrito pelos próprios desenvolvedores — e não vem de uma entrada do usuário.

Este relato de vulnerabilidade destaca alguns dos desafios enfrentados pelo grupo de segurança do Node.js ao responder a incidentes de segurança:

1. avaliar se um relato se aplica e deve ser considerado um bug de segurança

2. identificar a origem de uma vulnerabilidade

Problemas de segurança limítrofes no Node.js

Em uma análise rápida do relato, parece que o problema de segurança divulgado é um bug válido. Afinal, foi apresentada uma prova de conceito, e confirmou-se que o cenário de ataque podia ser reproduzido com o componente mencionado.

Ainda assim, é preciso analisar tudo com atenção para entender não só o vetor de ataque e os detalhes da vulnerabilidade, mas também o uso previsto do componente vulnerável. No caso do Fastify, a biblioteca impede deliberadamente a análise dinâmica do esquema JSON fornecido para validar requisições, a fim de mitigar ataques de injeção de código durante a execução.

No entanto, os desenvolvedores ainda podem usar um esquema de análise de JSON que contenha código malicioso, como o da prova de conceito. Mas será que isso é mesmo uma vulnerabilidade de segurança?

É aqui que as coisas ficam incertas. A equipe do Fastify deixou claras as considerações de segurança na documentação do projeto: a entrada de configuração do esquema JSON deve ser tratada como uma fonte confiável. Cabe agora ao desenvolvedor e à equipe que usa essa biblioteca garantir que a entrada seja confiável.

Onde está a vulnerabilidade de segurança no Node.js?

Outro desafio que muitas vezes passa despercebido é identificar a origem de uma vulnerabilidade de segurança. Neste relato, por exemplo, fica claro que há dois componentes envolvidos: o framework web Node.js fastify e a biblioteca de análise de JSON fast-json-stingify. Qual deles deve ser analisado e tratado como o componente vulnerável neste caso?

Por um lado, fastify é apenas um componente que usa outro componente para analisar o esquema JSON. Por outro, fast-json-stringify não declara a intenção de ser seguro contra qualquer tipo de entrada e deixa essa responsabilidade a cargo do usuário.

Um relato de segurança anterior que recebemos ajuda a esclarecer esse desafio. Nesse caso, foi descoberta uma vulnerabilidade de Cross-site Scripting (XSS) em uma aplicação que renderiza planilhas do Excel como páginas HTML e usa um componente de terceiros para analisar os dados da planilha. A vulnerabilidade de XSS afeta a própria aplicação, que não sanitiza os dados de saída enviados para uma página HTML. Ela não está relacionada ao componente de terceiros, pois esse componente não tem como saber de antemão se os dados de entrada serão usados em um contexto de saída HTML ou, talvez, em um arquivo CSV simples. Portanto, no escopo da biblioteca de análise de planilhas do Excel, esse tipo de vulnerabilidade de segurança não está relacionado.

Resumo

A triagem de vulnerabilidades de segurança exige bastante contexto e experiência. O diálogo entre o pesquisador de segurança e o mantenedor do componente vulnerável é fundamental para entender em que contexto a exploração é possível.

Outro desafio é atribuir corretamente as pontuações de vulnerabilidade de segurança, também conhecidas como Common Vulnerability Scoring System (CVSS). Se você quiser saber mais sobre esse tema para ajudar na triagem de vulnerabilidades no Node.js, já escrevi sobre os desafios do CVSS e dei dicas para acertar na avaliação.