El 77% de 433,000 sitios usa bibliotecas JavaScript vulnerables

La semana pasada publicamos nuestro primer informe sobre el estado de la seguridad del código abierto. Entre los hallazgos mencionados en el informe, un análisis de alrededor de 433,000 sitios encontró que el 77% usa al menos una biblioteca JavaScript de front-end con una vulnerabilidad de seguridad conocida. Esta cifra coincide con la que informamos en marzo, pero gracias a que Google Chrome ahora usa Snyk en Lighthouse para detectar bibliotecas JavaScript vulnerables, podemos obtener resultados mucho más completos.

Los datos de Lighthouse se recopilan como parte de HTTP Archive y están disponibles para hacer consultas a través de BigQuery. Como resultado, podemos consultar datos de auditorías de Lighthouse a gran escala.

Cuántos sitios son vulnerables

Los datos del 15 de octubre (la ejecución más reciente disponible) en BigQuery incluyen información recopilada de 439,176 URL diferentes. Si descontamos las URL en las que Lighthouse no pudo ejecutarse o en las que la auditoría no se completó por algún motivo, obtenemos un conjunto de datos de 418,112 sitios diferentes para consultar.

La primera pregunta es cuántos de esos sitios tienen vulnerabilidades conocidas. Podemos consultar los informes para averiguarlo:

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

Los resultados coinciden bastante con nuestro estudio a menor escala de marzo: el 77.3% (323,132) de esos sitios no pasó la auditoría. En otras palabras, el 77.3% de esos sitios contiene al menos una biblioteca JavaScript del lado del cliente con una vulnerabilidad de seguridad conocida. La nueva versión del sitio HTTP Archive informará cómo cambia esta cifra con el tiempo.

Podemos profundizar aún más para ver cuántas vulnerabilidades conocidas contienen esas bibliotecas:

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)

Resulta que, si tienes al menos una vulnerabilidad conocida, es probable que tengas más. El 51.8% de los sitios vulnerables tiene más de una vulnerabilidad de seguridad conocida. Aunque la mayoría de esos sitios tiene una o dos, la larga cola es preocupante. El 9.2% de los sitios tiene bibliotecas con un total de cuatro o más vulnerabilidades de seguridad conocidas.

Qué bibliotecas suelen ser vulnerables con mayor frecuencia

Con los datos de auditoría de Lighthouse, también podemos saber qué bibliotecas suelen encontrarse vulnerables con más frecuencia.

Primero, podemos consultar cuáles son las bibliotecas que se detectan con más frecuencia, sean vulnerables o no. La siguiente consulta obtiene las diez bibliotecas detectadas con mayor frecuencia:

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

Como era de esperarse, jQuery encabeza la lista. Esto coincide con lo que vimos en marzo y con lo que probablemente esperarías. Ninguna otra biblioteca se ha acercado a la popularidad universal de jQuery. Una salvedad: actualmente, React está infrarrepresentado. Cuando Lighthouse incorpore el script de detección actualizado, sus cifras aumentarán (y es probable que el porcentaje general de sitios vulnerables también aumente ligeramente).

Ahora cambiemos el enfoque y veamos qué bibliotecas tienen vulnerabilidades conocidas.

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

Los primeros nombres de la lista son muy similares.

Los porcentajes no pintan un panorama alentador. El 92.5% de las versiones de jQuery, por mucho la biblioteca más popular de la web, que están en producción tiene una vulnerabilidad de seguridad conocida. De hecho, de las diez bibliotecas que con más frecuencia se encuentran con una vulnerabilidad conocida, seis son vulnerables en la mayoría de las versiones detectadas en producción.

Esto ocurre a pesar de que hay versiones sin estas vulnerabilidades disponibles para todas las bibliotecas de esta lista.

Las bibliotecas de front-end que con más frecuencia se encuentran vulnerables llevan entre uno y cinco años sin vulnerabilidades conocidas. La realidad es que las bibliotecas y los frameworks de front-end suelen dejar de actualizarse una vez que llegan a producción.

Hay motivos para tener esperanza

El panorama es bastante sombrío ahora mismo; no hay forma de negarlo. Aunque estos datos no significan que los sitios sean explotables en los 77% de los casos (es posible que eviten los métodos vulnerables), eso consuela poco. El 77% de los sitios está a una llamada a un método por parte de un solo desarrollador de volverse vulnerable. Como hemos visto en 2017, las vulnerabilidades de código abierto deben tomarse muy en serio.

Pero también hay un lado positivo. Aunque hay muchas vulnerabilidades en producción, ya se corrigieron en las propias bibliotecas. Hay versiones de cada una de las principales bibliotecas que no tienen vulnerabilidades de seguridad conocidas; solo tenemos que implementarlas en producción.

Para mejorar la situación, deben ocurrir algunas cosas. La primera es mejorar las herramientas y su adopción. Según nuestra encuesta sobre el estado de la seguridad del código abierto, el 38% de las personas que usan código abierto no utiliza ningún tipo de herramienta automatizada para mantener sus paquetes actualizados. Me atrevo a decir que, si analizáramos específicamente el uso de JavaScript de front-end, la adopción sería aún menor.

Esa cifra debería mejorar. Las mejoras en npm y Yarn han simplificado mucho la gestión de paquetes de front-end para los desarrolladores. Combinar un flujo de trabajo sólido para la gestión de paquetes con herramientas como Snyk, que te ayudan a detectar, prevenir, corregir y monitorear las dependencias de esos paquetes, contribuirá mucho a que la web sea más segura.

Lo segundo que necesitamos es aumentar el conocimiento y la comprensión general del problema. Por eso publicamos el informe sobre el estado de la seguridad del código abierto: para visibilizar los desafíos de proteger el código abierto y ayudar a encontrar formas de mejorar.

La auditoría de bibliotecas vulnerables en Lighthouse (y Sonar) también ayuda. Estas herramientas facilitan que los desarrolladores detecten problemas en los sitios que crean. Y gracias a HTTP Archive y BigQuery, tenemos acceso fácil a los datos que nos permiten ver la magnitud del problema.

Aunque los datos actuales no son alentadores, una mayor concientización y mejores herramientas pueden convertirlo en un problema que podremos resolver en el futuro.