Share
Los desarrolladores de JavaScript de hoy en día aman npm. GitHub y el registro de npm son el primer lugar elegido por los desarrolladores para encontrar un paquete en particular. Los módulos de código abierto aumentan la productividad y la eficiencia al proporcionar a los desarrolladores una serie de funcionalidades que puede reutilizar en su proyecto. Es justo decir que si no fuera por estos paquetes de código abierto, la mayoría de los marcos actuales no existirían en su forma actual.
Una aplicación de nivel empresarial completa, por ejemplo, puede depender de cientos, si no de miles de paquetes. Las dependencias habituales incluyen dependencias directas, dependencias de desarrollo, dependencias agrupadas, dependencias de producción y dependencias opcionales. Eso es genial porque todos obtienen lo mejor del ecosistema de código abierto.
Sin embargo, uno de los factores que se pasan por alto es la cantidad de riesgo involucrado. Aunque estos módulos de terceros son particularmente útiles en su dominio, también introducen algunos riesgos de seguridad en su aplicación.
Las dependencias de OSS son de hecho vulnerables a las explotaciones y compromisos. Echemos un vistazo a algunos ejemplos:
Recientemente se descubrió una vulnerabilidad en un paquete llamado eslint-scope que depende de varios paquetes populares de JavaScript como babel-eslint y webpack. La cuenta del mantenedor del paquete se vio comprometida y los hackers agregaron un código malicioso en ella. Afortunadamente, alguien descubrió la vulnerabilidad lo suficientemente pronto como para que el daño se limitara a unos pocos usuarios.
Moment.js, que es una de las bibliotecas más utilizadas para analizar y mostrar fechas en JavaScript, recientemente se encontró que tenía una vulnerabilidad con una puntuación de severidad de 7.5. El exploit lo hizo vulnerable a los ataques de ReDoS. Los parches se lanzaron rápidamente y pudieron solucionar el problema con bastante rapidez..
Pero eso no es todo. Muchas nuevas explotaciones se desentierran cada semana. Algunos de ellos se divulgan al público, pero otros aparecen en los titulares solo después de una infracción grave..
Entonces, ¿cómo mitigamos estos riesgos? En este artículo, explicaré algunas de las mejores prácticas estándar de la industria que puede utilizar para asegurar sus dependencias de código abierto..
Hablando lógicamente, a medida que aumenta el número de dependencias, también puede aumentar el riesgo de terminar con un paquete vulnerable. Esto se aplica igualmente a las dependencias directas e indirectas. Aunque no hay razón para dejar de usar paquetes de código abierto, siempre es una buena idea hacer un seguimiento de ellos..
Estas dependencias son fácilmente detectables y pueden ser tan simples como correr npm ls en el directorio raíz de su aplicación. Puedes usar el -pinchar argumento que muestra todas las dependencias de producción y la -largo argumento para un resumen de cada descripción del paquete.
Además, puede usar un servicio para automatizar el proceso de administración de dependencias que ofrece monitoreo en tiempo real y pruebas automáticas de actualización para sus dependencias. Algunas de las herramientas familiares incluyen GreenKeeper, Libraries.io, etc. Estas herramientas recopilan una lista de las dependencias que está utilizando actualmente y rastrean la información relevante sobre ellas.
Con el paso del tiempo y los cambios en su código, es probable que deje de usar algunos paquetes por completo y en su lugar agregue otros nuevos. Sin embargo, los desarrolladores tienden a no eliminar los paquetes antiguos a medida que avanzan.
Con el tiempo, su proyecto puede acumular una gran cantidad de dependencias no utilizadas. Si bien esto no es un riesgo directo para la seguridad, es casi seguro que estas dependencias se agreguen a la superficie de ataque de su proyecto y provoquen un desorden innecesario en el código. Un atacante puede encontrar un vacío legal al cargar un paquete antiguo pero instalado que tiene un mayor cociente de vulnerabilidad, lo que aumenta el daño potencial que puede causar..
¿Cómo se verifican las dependencias no utilizadas? Puedes hacer esto con la ayuda de la herramienta depcheck. Depcheck escanea su código completo para requiere y importar comandos A continuación, correlaciona estos comandos con los paquetes instalados o los mencionados en su paquete.json y le proporciona un informe. El comando también se puede modificar utilizando diferentes indicadores de comando, lo que simplifica la verificación de las dependencias no utilizadas..
Instalar depcheck con:
npm install -g depcheck
Casi todos los puntos mencionados anteriormente están relacionados principalmente con los problemas potenciales que puede encontrar. Pero ¿qué pasa con las dependencias que estás usando ahora??
Según un estudio reciente, casi el 15% de los paquetes actuales incluyen una vulnerabilidad conocida, ya sea en los componentes o en las dependencias. Sin embargo, la buena noticia es que hay muchas herramientas que puede utilizar para analizar su código y encontrar riesgos de seguridad de código abierto dentro de su proyecto..
La herramienta más conveniente es npm's. npm audit. Auditoría es una secuencia de comandos que se lanzó con la versión 6 de npm. Node Security Platform desarrolló inicialmente la auditoría npm, y luego el registro npm la adquirió. Si tiene curiosidad por saber de qué se trata la auditoría de npm, aquí hay una cita del blog oficial:
Una auditoría de seguridad es una evaluación de las dependencias de paquetes para las vulnerabilidades de seguridad. Las auditorías de seguridad lo ayudan a proteger a los usuarios de su paquete al permitirle encontrar y corregir vulnerabilidades conocidas en dependencias. El comando de auditoría npm envía una descripción de las dependencias configuradas en su paquete a su registro predeterminado y solicita un informe de vulnerabilidades conocidas.
El informe generado generalmente comprende los siguientes detalles: el nombre del paquete afectado, la gravedad y la descripción de la vulnerabilidad, la ruta y otra información y, si están disponibles, comandos para aplicar parches y resolver vulnerabilidades. Incluso puede obtener el informe de auditoría en JSON ejecutando npm audit --json.
Aparte de eso, npm también ofrece asistencia sobre cómo actuar según el informe. Puedes usar revisión de la auditoría de npm para solucionar problemas que ya se han encontrado. Estas correcciones se realizan comúnmente mediante actualizaciones guiadas o mediante parches de código abierto.
No dude en consultar la documentación de npm para más información..
El concepto de seguridad de código abierto depende en gran medida de la cantidad de ojos que están vigilando esa biblioteca en particular. Los paquetes que se utilizan activamente se observan más de cerca. Por lo tanto, existe una mayor probabilidad de que el desarrollador haya abordado todos los problemas de seguridad conocidos en ese paquete en particular.
Tomemos un ejemplo. En GitHub, hay muchas implementaciones de token web JSON que puedes usar con tu biblioteca Node.js. Sin embargo, los que no están en desarrollo activo podrían tener vulnerabilidades críticas. Una vulnerabilidad de este tipo, que fue reportada por Auth0, permite a cualquiera crear sus propios tokens "firmados" con cualquier carga útil que deseen.
Si un paquete razonablemente popular o bien usado tuviera este defecto, las probabilidades de que un desarrollador encuentre y parche la falla serían mayores. Pero ¿qué pasa con un proyecto inactivo / abandonado? Hablaremos de eso en el siguiente punto..
Quizás la forma más rápida y eficiente de determinar la actividad de un paquete específico es verificar su velocidad de descarga en npm. Puedes encontrar esto en el Estadísticas sección de la página del paquete de npm. También es posible extraer estas cifras automáticamente utilizando la API de estadísticas de npm o explorando las estadísticas históricas en npm-stat.com. Para los paquetes con repositorios GitHub, debe consultar el historial de confirmaciones, el rastreador de problemas y cualquier solicitud de extracción relevante para la biblioteca..
Hay muchos errores, incluido un gran número de errores de seguridad que se desentierran continuamente y, en la mayoría de los casos, se reparan de inmediato. No es raro que las vulnerabilidades informadas recientemente se solucionen únicamente en la versión / rama más reciente de un proyecto dado.
Por ejemplo, tomemos la vulnerabilidad de Denegación de Servicio de Expresión Regular (ReDoS) reportada en el paquete HMAC 'hawk' a principios de 2016. Este error en hawk se resolvió rápidamente, pero solo en la última versión principal, 4.x. Las versiones anteriores, como 3.x, se parchearon mucho más tarde, aunque estaban igualmente en riesgo..
Por lo tanto, como regla general, es menos probable que sus dependencias tengan errores de seguridad si utilizan la última versión disponible..
La forma más fácil de confirmar si está utilizando la versión más reciente es usando el npm desactualizado mando. Este comando soporta el -pinchar bandera para ignorar las dependencias de desarrollo y --json hacer la automatización más simple.
Inspeccione regularmente los paquetes que utiliza para verificar su fecha de modificación. Puede hacerlo de dos maneras: a través de la interfaz de usuario de npm o ejecutando vista npm .
La clave para asegurar su aplicación es tener una cultura de seguridad desde el principio. En esta publicación, hemos cubierto algunas de las prácticas estándar para mejorar la seguridad de sus componentes de JavaScript.
Accentsconagua
npm audit para analizar tus dependencias.Si tiene alguna opinión sobre la seguridad de JavaScript, no dude en compartirla en los comentarios..
