Frecuencia de las vulnerabilidades conocidas en las bibliotecas de JavaScript

La semana pasada se presentó un interesante informe en el Simposio NDSS que analiza un esfuerzo a gran escala para determinar cuán vulnerables son las bibliotecas de JavaScript del lado del cliente.

El estudio analizó código JS de más de 133,000 sitios web. Buscaron bibliotecas populares de JavaScript (al final analizaron 72), determinaron qué versiones se usaban y luego consultaron si tenían vulnerabilidades conocidas. Las conclusiones fueron interesantes, por decir lo menos.

Es un excelente informe y recomendamos mucho dedicar unos minutos a leerlo. Ya se publicaron algunos resúmenes (el de Adrian es particularmente bueno) y también queremos compartir nuestra perspectiva.

Las vulnerabilidades conocidas son comunes

Los investigadores descubrieron que el 37 % de los sitios analizados incluía al menos una biblioteca con una vulnerabilidad conocida. Esta cifra ha causado inquietud en las conversaciones que hemos visto, pero la realidad probablemente sea mucho peor.

El estudio analizó las 72 bibliotecas más populares, lo que significa que no se incluyó una larga lista de bibliotecas menos populares. El proyecto mediano que monitoreamos incluye 184 dependencias: la larga lista de bibliotecas en el desarrollo de JavaScript es considerable. Aunque cada una de estas bibliotecas se usa con menos frecuencia, en conjunto representan cifras muy grandes. Además, las bibliotecas de esta larga lista suelen tener menos colaboradores. Esto significa que, si se descubre una vulnerabilidad, una actualización con la corrección podría tardar bastante en implementarse.

La lista de vulnerabilidades que analizaron también dejó algunas fuera. Los investigadores no encontraron una base de datos de vulnerabilidades que les convenciera, así que hicieron lo posible por crear una. Hicieron un buen trabajo, pero parece que al menos algunas de las vulnerabilidades de nuestra base de datos no se incluyeron en su análisis. Por ejemplo, aunque la biblioteca moment apareció en su lista de bibliotecas populares, parece que no detectaron las dos vulnerabilidades conocidas que afectan a muchas versiones.

Tampoco intentaron identificar vulnerabilidades nuevas, lo cual es muy comprensible: descubrir vulnerabilidades nuevas requiere mucho tiempo y esfuerzo (como seguramente confirmaría nuestro equipo de investigación). Sin embargo, las vulnerabilidades nuevas se divulgan con mucha más frecuencia de la que los desarrolladores actualizan las bibliotecas. En solo diez días desde la publicación del informe, agregamos siete vulnerabilidades nuevas encontradas en bibliotecas de npm.

Al juntar todo esto, queda claro que, si el 37 % parecía una cifra preocupante, la realidad es todavía peor.

También vale la pena recordar que este 37 % se refiere solo al lado del cliente. Actualmente tenemos alrededor de 400 vulnerabilidades conocidas de paquetes npm en nuestra base de datos, y no todas son del lado del cliente. Ampliar el estudio a todo el ecosistema de JavaScript sería aún más preocupante.

Actualizar a bibliotecas nuevas es un proceso lento

En el sitio que ocupaba la posición mediana entre los analizados, se usaba una versión de la biblioteca 1177 días (¡más de tres años!) anterior a la última versión.

La adopción lenta de nuevas versiones de software y bibliotecas no es un problema nuevo ni exclusivo del ecosistema de JavaScript. Basta con observar cualquier actualización de un sistema operativo: verás que la mayoría tarda un tiempo en actualizarse, y esos sistemas suelen tener la ventaja de poder enviar notificaciones de actualización directamente al equipo.

Las bibliotecas de JavaScript enfrentan los mismos desafíos de seguridad que un sistema operativo, pero sin la ventaja de poder activar actualizaciones directamente y con más trabajo manual.

Actualizar una biblioteca requiere esfuerzo y conlleva riesgos. Toma tiempo enterarse de que hay una actualización, descargarla, probarla y, posiblemente, hacer cambios en la forma de usar la biblioteca. Si la actualización incluye cambios menores y no modifica sustancialmente las funciones, el esfuerzo es algo menor, pero también lo es el incentivo para que muchos actualicen.

El versionado semver adecuado puede indicar la complejidad de una actualización, pero no ofrece una indicación clara de la urgencia de una actualización. Como explica el informe, las notas de lanzamiento de una biblioteca no siempre comunican con claridad las correcciones de vulnerabilidades. Para entender la urgencia de una versión, hay que monitorear las bibliotecas para detectar vulnerabilidades conocidas, y la gran mayoría de los desarrolladores todavía no lo hace.

Mantener la esperanza

Los hallazgos del informe son un duro llamado de atención. En general, nuestra industria ha aprovechado rápidamente la gran cantidad de recursos que ofrece el desarrollo de código abierto, pero ha tardado mucho más en reconocer y protegerse de los riesgos que esto puede implicar.

Aunque a primera vista los hallazgos pueden desanimar (sin duda, los autores del informe se sintieron así con lo que encontraron), somos optimistas. Últimamente, ha aumentado poco a poco la conciencia general sobre la importancia de la seguridad. Se han desarrollado estándares web más sólidos e inteligentes para agregar capas de seguridad. Y las herramientas están mejorando. Es totalmente posible monitorear tus aplicaciones de JavaScript para detectar problemas conocidos de una forma práctica para desarrolladores y recibir alertas cuando se publiquen actualizaciones importantes.

Es cierto que aún nos queda mucho camino por recorrer, pero proteger JavaScript es un problema que tiene solución.