¿Las bibliotecas de Javascript obsoletas representan un riesgo para mi aplicación web?

El uso de cualquier software obsoleto es inherentemente un riesgo de seguridad; Se pueden explotar todas las fallas detectadas entre la versión que está ejecutando y la última versión. Por ejemplo, tal vez hay una carga útil específica que puede alimentar para causar un bucle infinito, lo que podría provocar un evento de Denegación de Servicio (DOS), o tal vez haya un error que de alguna manera puede romper la caja de arena de JavaScript y causar estragos en el sistema.

No veo ningún problema de seguridad crítico mencionado en Internet, pero eso no significa que no existan o no se hayan solucionado. Siempre que sea posible, siempre se recomienda usar la última versión, pero esto también puede incluir probar su código con la nueva versión para asegurarse de que no se rompa en cuanto a funcionalidad cuando se actualiza (por ejemplo, las versiones principales a menudo son incompatibles con versiones anteriores anteriores) ).

La mejor manera de mantener sus bibliotecas actualizadas es utilizar el paquete de una cadena de herramientas que proporciona actualizaciones con un solo clic. Por ejemplo, si copia la biblioteca a su servidor local usando npm install , puede importarlos directamente (cloudflare proporcionará protección para su sitio si los usa). A partir de ahí, actualizar sus bibliotecas es tan fácil como npm update desde el terminal de línea de comandos.

Se recomienda encarecidamente que utilice una suite TDD (Test Driven Development), como Mocha , para asegurarse de que sus scripts no se rompan cuando se actualizan las bibliotecas, además de reducir en general la posibilidad de que rompa su código durante el desarrollo. Además, recuerde usar un repositorio (como git o subversion) para poder revertir los cambios si la actualización de npm hace que las cosas se rompan.

Depende.

Si la nueva versión se publica como un parche para cualquier problema de seguridad encontrado en la biblioteca antigua, su uso es un riesgo.

Pero, JavaScript es un lenguaje del lado del cliente. Por lo tanto, arriesga tu servidor solo si hay una falla en las funciones de solicitud de Ajax.

La biblioteca JS de las fuentes http puede causar otros problemas, pero desde https no tendrá ningún otro problema.

Otra cosa a tener en cuenta es que, como desarrollador web, lee cuidadosamente el registro de migración antes de actualizar. Porque si alguna función está en desuso y la usó en su página, no funcionará correctamente.

Eso depende de las vulnerabilidades (conocidas) en la biblioteca de JavaScript desactualizada. A menudo, las versiones más nuevas solucionan problemas de seguridad (menores) también.

Una gran lista con la que comparar su biblioteca es una herramienta llamada Retire.js .

También tenga en cuenta que el uso de una red de entrega de contenido (CDN) como CloudFlare puede ser un riesgo menor en sí mismo. Porque, en teoría, pueden cambiar el contenido del JavaScript que se incluye en su página. Para mitigar este tipo de riesgo, recomendaría revisar la integridad del recurso secundario (SRI).

Yo digo que no, he aquí por qué. Las bibliotecas simplemente ejecutan el código que el navegador les permite. Nunca deben ser capaces de hacer cosas malas. Si una biblioteca revela un problema de seguridad, o bien no lo está utilizando correctamente (el manejo de entrada de un usuario en una plantilla), o si reveló una vulnerabilidad de navegador . En cualquier caso, se supone que el sandbox y las políticas protegen contra los scripts maliciosos.

La única excepción que se me ocurre sería el cifrado del lado del cliente, que se debe mantener y no realizar a la ligera. Los autores de las bibliotecas no son expertos en seguridad, por lo que es tan importante que el navegador sea la policía. Si bien tuvo un comienzo inestable, en los últimos años los navegadores han hecho un gran trabajo, especialmente ahora que los complementos como PDF y Flash están disminuidos.

Un último pensamiento: me refiero exclusivamente a las librerías de JavaScript basadas en el navegador del lado del cliente; Si tiene libretas desactualizadas para un servidor como node.js, ¡SÍ, pueden suceder cosas malas!

EDITAR: esto incluye servidores externos además del suyo; CDN, sitios asociados, anuncios, etc. Si se produjera una vulnerabilidad de la web sin un servidor, realmente no sería una vulnerabilidad. Hay problemas de apuntalamiento ocasionales con el navegador / complementos / etc, pero el código que se ejecuta sobre ellos no es responsable de corregirlos: los proveedores sí.