Como corrigir uma vulnerabilidade que contorna a proteção contra sobrescrita de protótipos no qs

No mês passado, adicionamos ao nosso banco de dados uma vulnerabilidade de alta gravidade que contorna a proteção contra sobrescrita de protótipos no pacote qs. A correção foi lançada em versões atualizadas da biblioteca cerca de uma semana atrás. Nesta publicação, explicamos a vulnerabilidade e como mitigá-la.

O qs é um pacote popular do npm — com pouco menos de 40 milhões de downloads no último mês — usado para analisar parâmetros de query string e transformá-los em objetos. Por exemplo:

1qs.parse('a=b&c=d');
2// {a:'b', c: 'd'}

Embora isso seja bastante útil, o grande diferencial do qs é a funcionalidade avançada que ele oferece. Com o qs, você pode até criar objetos aninhados nas query strings usando colchetes ([ ou ]).

1qs.parse('a[b]=c');
2// {
3//   a: {
4//     b: "c"
5//   }
6// }

A possibilidade de criar objetos aninhados nos parâmetros da query string também traz alguns riscos. Se os dados não forem validados corretamente, você pode acabar sobrescrevendo propriedades do protótipo do objeto. Por exemplo, você poderia tentar sobrescrever o método hasOwnProperty do objeto:

1qs.parse('a[hasOwnProperty]=b');

Felizmente, o exemplo acima não funcionaria. Por padrão, o qs ignora parâmetros (como hasOwnProperty) que sobrescreveriam propriedades do protótipo do objeto. Para isso, ele verifica se há colchetes de abertura e fechamento no parâmetro, extrai o trecho entre eles e o compara com o protótipo do objeto para saber se corresponde a uma propriedade nativa. Existe uma opção que permite sobrescrever protótipos, mas o qs recomenda fortemente que você não a use.

Infelizmente, uma falha na validação ainda permitia sobrescrever uma propriedade do protótipo do objeto ao prefixar o parâmetro com um caractere [ ou ] sem par correspondente.

Por exemplo, o código a seguir sobrescreveria o método hasOwnProperty do objeto, embora tenhamos configurado explicitamente o qs para impedir a sobrescrita de protótipos:

1var paramData = qs.parse("]=hasOwnProperty", { allowPrototypes: false });
2// {hasOwnProperty = true}
3
4paramData.hasOwnProperty('toString');
5// Results in Type Error: paramData.hasOwnProperty is not a function

O resultado mais provável seria uma falha e um comportamento inesperado e instável no seu aplicativo. Mas, dependendo da lógica da aplicação, o impacto poderia ser muito mais grave: em alguns casos, permitiria até que invasores alterassem o fluxo de execução do aplicativo.

A correção

Nossa equipe de pesquisa de segurança descobriu o problema em 13 de fevereiro e o reportou ao responsável pelo pacote. A resposta foi rápida: três dias depois, ele lançou uma correção nas versões 6.0.3, 6.1.1, 6.2.2 e 6.3.1.

A correção resolvia o problema quando o parâmetro começava com ]=, mas não era suficiente: descobriu-se que o qs continuava vulnerável se o invasor usasse [=. Por isso, o responsável pelo pacote atualizou a lógica e lançou uma correção mais robusta nas versões 6.4.0, 6.3.2, 6.2.3, 6.1.2 e 6.0.4.

Para resolver o problema, você precisa atualizar o pacote para uma dessas versões. Se você usa o Snyk para monitorar seu projeto, provavelmente já recebeu uma solicitação para fazer a atualização, seja por meio de um pull request gerado automaticamente ou executando snyk wizard pela CLI.

Caso contrário, verifique se seu aplicativo usa o pacote qs — seja como dependência direta listada no arquivo package.json ou como dependência indireta incluída por uma dependência direta — e atualize-o para a versão mais recente.