77% de 433 mil sites usam bibliotecas JavaScript vulneráveis

Na semana passada, lançamos nosso primeiro relatório State of Open Source Security. Entre as descobertas mencionadas no relatório, uma análise de cerca de 433 mil sites constatou que 77% deles usam pelo menos uma biblioteca JavaScript de front-end com uma vulnerabilidade de segurança conhecida. Esse número é semelhante ao que divulgamos em março, mas, agora que o Google Chrome usa o Snyk no Lighthouse para testar bibliotecas JavaScript vulneráveis, podemos obter resultados muito mais completos.

Os dados do Lighthouse são coletados como parte do HTTP Archive e podem ser consultados pelo BigQuery. Com isso, podemos consultar dados de auditoria do Lighthouse em grande escala.

Quantos sites estão vulneráveis

Os dados de 15 de outubro (a execução mais recente disponível) no BigQuery incluem informações coletadas de 439.176 URLs diferentes. Depois de desconsiderar as URLs em que o Lighthouse não conseguiu ser executado ou cuja auditoria não foi concluída por algum motivo, temos um conjunto de dados com 418.112 sites diferentes para consultar.

A primeira pergunta é: quantos desses sites têm vulnerabilidades conhecidas? Podemos consultar os relatórios para descobrir:

1SELECT
2  JSON_EXTRACT_SCALAR(report, "$.audits.no-vulnerable-libraries.score") AS score,
3  COUNT(0) AS volume
4FROM
5  [httparchive:har.latest_lighthouse_mobile]
6WHERE
7  report IS NOT NULL
8GROUP BY
9  score
10HAVING
11  score IS NOT NULL
12ORDER BY
13  score

Os resultados estão bem alinhados com nosso estudo em menor escala de março: 77,3% (323.132) desses sites não passaram na auditoria. Em outras palavras, 77,3% deles contêm pelo menos uma biblioteca JavaScript do lado do cliente com uma vulnerabilidade de segurança conhecida. A nova versão do site HTTP Archive vai mostrar como esse número muda ao longo do tempo.

Também podemos aprofundar a análise para ver quantas vulnerabilidades conhecidas essas bibliotecas apresentam:

1SELECT 
2  REGEXP_EXTRACT(JSON_EXTRACT_SCALAR(report, "$.audits.no-vulnerable-libraries.displayValue"), r'^\S*') AS knownVulnerabilities,
3  COUNT(0) AS volume
4FROM
5  `httparchive.lighthouse.2017_10_15_mobile`
6WHERE
7  report IS NOT NULL
8AND
9  JSON_EXTRACT_SCALAR(report, "$.audits.no-vulnerable-libraries.score") = 'false'
10GROUP BY
11  knownVulnerabilities
12ORDER BY
13  CAST(knownVulnerabilities as int64)

Acontece que, se um site tem pelo menos uma vulnerabilidade conhecida, é provável que tenha outras. 51,8% dos sites vulneráveis têm mais de uma vulnerabilidade de segurança conhecida. Embora a maioria tenha uma ou duas, a cauda longa é preocupante: 9,2% dos sites usam bibliotecas com quatro ou mais vulnerabilidades de segurança conhecidas no total.

Quais bibliotecas são encontradas vulneráveis com mais frequência

Com os dados de auditoria do Lighthouse, também podemos identificar quais bibliotecas são encontradas vulneráveis com mais frequência.

Primeiro, podemos consultar quais bibliotecas são detectadas com mais frequência, sejam elas vulneráveis ou não. A consulta a seguir busca as dez bibliotecas mais encontradas:

1CREATE TEMPORARY FUNCTION getLibs(items STRING)
2RETURNS ARRAY<STRING>
3LANGUAGE js AS """
4  try {
5    return  items.match(/"name":"([^"]*)"/ig);
6  } catch (e) {
7    return [];
8  }
9""";
10
11SELECT library, COUNT(0) Volume
12FROM (
13   SELECT getLibs(JSON_EXTRACT(report, "$.audits.no-vulnerable-libraries.extendedInfo.jsLibs")) AS libs
14   FROM `httparchive.lighthouse.2017_10_15_mobile`
15)
16CROSS JOIN 
17   UNNEST(libs) AS library
18GROUP BY library
19ORDER BY Volume DESC
20LIMIT 10

Sem surpresa, o jQuery está no topo da lista. Isso está de acordo com o que vimos em março e com o que você provavelmente esperaria. Nenhuma outra biblioteca chegou perto da popularidade universal do jQuery. Uma ressalva: a presença do React está sendo subestimada. Quando o script de detecção atualizado for incluído no Lighthouse, os números do React vão aumentar (e a porcentagem geral de sites vulneráveis provavelmente também terá um pequeno aumento).

Agora, vamos mudar o foco e ver quais bibliotecas são encontradas com vulnerabilidades conhecidas.

1CREATE TEMPORARY FUNCTION getLibs(items STRING)
2RETURNS ARRAY<STRING>
3LANGUAGE js AS """
4  try {
5    return  items.match(/"name":"([^"]*)"/ig);
6  } catch (e) {
7    return [];
8  }
9""";
10
11SELECT library, COUNT(0) Volume
12FROM (
13   SELECT getLibs(JSON_EXTRACT(report, "$.audits.no-vulnerable-libraries.extendedInfo.vulnerabilities")) AS libs
14   FROM `httparchive.lighthouse.2017_10_15_mobile`
15)
16CROSS JOIN 
17   UNNEST(libs) AS library
18GROUP BY library
19ORDER BY Volume DESC
20LIMIT 10

Os primeiros nomes da lista são bem parecidos.

Os percentuais não são nada animadores. Em produção, 92,5% das versões do jQuery — de longe a biblioteca mais popular da web — têm uma vulnerabilidade de segurança conhecida. Na verdade, entre as dez bibliotecas mais frequentemente encontradas com uma vulnerabilidade conhecida, seis são vulneráveis na maioria das versões em produção.

Isso acontece apesar de todas as bibliotecas dessa lista terem versões disponíveis sem essas vulnerabilidades.

As bibliotecas de front-end mais frequentemente encontradas vulneráveis estão há um a cinco anos sem vulnerabilidades conhecidas. Na prática, bibliotecas e frameworks de front-end muitas vezes deixam de ser atualizados depois que entram em produção.

Há motivos para ter esperança

O cenário atual é um tanto sombrio — não dá para negar. Esses dados não significam que todos os 77% desses sites possam ser explorados (é possível que não usem os métodos vulneráveis), mas isso é pouco consolo. Em 77% dos sites, basta um desenvolvedor fazer uma chamada a um método para que eles fiquem vulneráveis. Como vimos em 2017, é preciso levar muito a sério as vulnerabilidades de código aberto.

Mas também há um lado positivo. Embora haja muitas vulnerabilidades em produção, elas já foram corrigidas nas próprias bibliotecas. Todas as principais bibliotecas têm versões disponíveis sem vulnerabilidades de segurança conhecidas — só precisamos colocá-las em produção.

Para melhorar esse cenário, algumas coisas precisam acontecer. A primeira é aprimorar as ferramentas e ampliar sua adoção. De acordo com nossa pesquisa State of Open Source Security, 38% das pessoas que usam código aberto não recorrem a nenhuma ferramenta automatizada para manter os pacotes atualizados. Aposto que, se você analisasse especificamente o uso de JavaScript de front-end, a adoção seria ainda menor.

Esse número precisa melhorar. As melhorias no npm e no Yarn simplificaram muito o gerenciamento de pacotes de front-end para desenvolvedores. Combinar um fluxo de trabalho sólido para gerenciamento de pacotes com ferramentas como o Snyk, que ajudam você a encontrar, prevenir, corrigir e monitorar esses pacotes e suas dependências, ajuda muito a tornar a web mais segura.

A segunda necessidade é aumentar a conscientização e a compreensão geral do problema. Foi por isso que publicamos o relatório State of Open Source Security: para esclarecer os desafios de proteger o código aberto e ajudar a encontrar maneiras de melhorar.

A auditoria de bibliotecas vulneráveis no Lighthouse (e no Sonar) também ajuda. Essas ferramentas facilitam a identificação de problemas nos sites que desenvolvem. E, graças ao HTTP Archive e ao BigQuery, temos acesso fácil a dados que nos permitem entender a dimensão do problema.

Embora os dados atuais não sejam animadores, mais conscientização e ferramentas melhores podem ajudar a resolver esse problema no futuro.