A frequência de vulnerabilidades conhecidas em bibliotecas JavaScript

Há um white paper interessante apresentado no simpósio NDSS da semana passada que aborda uma tentativa em larga escala de descobrir o quanto as bibliotecas JavaScript do lado do cliente são vulneráveis.

O estudo analisou código JS em mais de 133 mil sites diferentes. Os pesquisadores buscaram bibliotecas JavaScript populares (no fim, foram 72), identificaram as versões em uso e verificaram se havia vulnerabilidades conhecidas. Para dizer o mínimo, as conclusões são interessantes.

É um excelente relatório, e recomendamos muito que você reserve alguns minutos para lê-lo. Algumas pessoas já publicaram resumos (o de Adrian é especialmente bom), e também queremos compartilhar nossa perspectiva.

Vulnerabilidades conhecidas são comuns

Os pesquisadores descobriram que 37% dos sites analisados incluíam pelo menos uma biblioteca com uma vulnerabilidade conhecida. Esse número tem deixado muita gente apreensiva nas conversas que acompanhamos, mas a realidade provavelmente é bem pior.

O estudo analisou as 72 bibliotecas mais populares, o que significa que há uma longa cauda de bibliotecas menos populares que ficaram de fora. O projeto mediano que monitoramos inclui 184 dependências — a cauda longa do desenvolvimento em JavaScript é expressiva. Embora cada uma dessas bibliotecas seja usada com menos frequência, juntas elas somam números muito altos. As bibliotecas nessa cauda longa também tendem a ter menos colaboradores. Isso significa que, se uma vulnerabilidade for descoberta, uma atualização com a correção pode demorar bastante para ser disponibilizada.

A lista de vulnerabilidades analisada também deixou algumas de fora. Os pesquisadores não encontraram uma base de dados de vulnerabilidades que considerassem adequada, então fizeram o possível para montar uma. E fizeram um bom trabalho, mas parece que pelo menos algumas vulnerabilidades da nossa base não foram incluídas na análise. Por exemplo, embora a biblioteca moment tenha aparecido na lista de bibliotecas populares, os pesquisadores aparentemente não identificaram as duas vulnerabilidades conhecidas presentes em muitas versões.

Eles também não tentaram identificar novas vulnerabilidades, o que é perfeitamente compreensível: descobrir novas vulnerabilidades exige muito tempo e esforço (como nossa equipe de pesquisa certamente pode confirmar). Mas novas vulnerabilidades são divulgadas com muito mais frequência do que os desenvolvedores atualizam as bibliotecas. Nos apenas dez dias desde a publicação do relatório, adicionamos sete novas vulnerabilidades encontradas em bibliotecas npm.

Juntando tudo, fica claro que, se 37% parece ruim, a realidade é certamente pior.

Também vale lembrar que esses 37% dizem respeito apenas ao lado do cliente. Atualmente, temos cerca de 400 vulnerabilidades conhecidas em pacotes npm na nossa base de dados, e nem todas afetam o lado do cliente. Ampliar o estudo para todo o ecossistema JavaScript seria ainda mais preocupante.

A atualização para novas versões das bibliotecas é um processo lento

O site mediano analisado usava uma versão de biblioteca 1.177 dias (mais de três anos!) anterior à versão mais recente.

A adoção lenta de novas versões de softwares e bibliotecas não é um problema novo, nem se limita ao ecossistema JavaScript. Basta observar as atualizações de qualquer sistema operacional: a maioria das pessoas demora um pouco para atualizar — e esses sistemas geralmente têm a vantagem de poder enviar notificações de atualização diretamente para o dispositivo.

As bibliotecas JavaScript enfrentam desafios de segurança semelhantes aos de um sistema operacional, mas sem a vantagem de poder iniciar atualizações diretamente e com mais trabalho manual envolvido.

Atualizar uma biblioteca exige esforço e envolve riscos. Leva tempo para descobrir que há uma atualização, baixá-la, testá-la e, possivelmente, fazer mudanças na forma como você usa a biblioteca. Se a atualização envolve mudanças pequenas e não altera muito a funcionalidade, o esforço é menor — mas também diminui a motivação de muitas pessoas para atualizar.

O versionamento semântico adequado pode indicar a complexidade de uma atualização, mas não há um indicador claro da urgência de uma atualização. Como o artigo explica, as correções de vulnerabilidades nem sempre são comunicadas com clareza nas notas de versão de uma biblioteca. Para entender a urgência de uma versão, é preciso monitorar suas bibliotecas em busca de vulnerabilidades conhecidas — e a grande maioria dos desenvolvedores ainda não faz isso.

Mantendo a esperança

As descobertas do artigo são um doloroso alerta. Em geral, nosso setor aproveitou rapidamente a abundância de recursos que o desenvolvimento de código aberto oferece, mas demorou muito mais para reconhecer e se proteger dos riscos que podem vir com ele.

Embora, à primeira vista, as descobertas possam desanimar (os autores do artigo certamente ficaram desanimados com o que encontraram), estamos otimistas. Nos últimos tempos, a conscientização sobre a importância da segurança vem crescendo aos poucos. Foram desenvolvidos padrões para a web mais robustos e inteligentes, que adicionam camadas de segurança. E as ferramentas estão melhorando. É totalmente possível monitorar suas aplicações JavaScript em busca de problemas conhecidos de uma forma amigável para desenvolvedores e receber alertas quando atualizações importantes forem lançadas.

Ainda temos um longo caminho pela frente, é verdade, mas proteger JavaScript é um problema que podemos resolver.