Advertisement
  1. Code
  2. Security

¿Qué Tan Seguras Son Tus Dependencias de JavaScript de Código Abierto?

by
Read Time:7 minsLanguages:

Spanish (Español) translation by Alfonso Mora (you can also view the original English article)

Los desarrolladores de JavaScript del moderno-día encantan MNP. GitHub y el registro de la nueva gestión pública son primera opción de los desarrolladores el lugar para encontrar un paquete particular. Módulos de código abierto añadir a la productividad y la eficiencia proporcionando a los desarrolladores con una serie de funcionalidades que se pueden reutilizar en su proyecto. Es justo decir que si no fuera por estos paquetes de código abierto, la mayoría de las estructuras hoy no existirían en su forma actual.

Una completa aplicación de nivel empresarial, por ejemplo, podría depender de cientos si no miles de paquetes. Las dependencias habituales incluyen dependencias directas, las dependencias de desarrollo, incluidas dependencias, dependencias de producción y dependencias opcionales. Eso es genial porque todo el mundo es aprovechar al máximo el ecosistema de código abierto.

Sin embargo, uno de los factores que haz pasado por alto es la cantidad de riesgos. Aunque estos módulos de terceros son particularmente útiles en su dominio, también introducen algunos riesgos de seguridad en su aplicación.

¿Bibliotecas de Código Abierto Son Vulnerables?

Dependencias de OSS son de hecho vulnerables a ataques y compromisos. Echemos un vistazo a algunos ejemplos:

Una vulnerabilidad fue descubierta recientemente en un paquete llamado eslint-scope, que es una dependencia de varios paquetes de JavaScript populares como babel-eslint o webpack. La cuenta del responsable del paquete fue comprometida, y los hackers ha añadido algunos malintencionados en él. Afortunadamente, alguien descubrió el exploit pronto suficiente que el daño se habría limitado a unos pocos usuarios.

Moment.js, que es una de las bibliotecas más utilizadas para analizar y mostrar las fechas en JavaScript, recientemente fue encontrado para tener una vulnerabilidad con una puntuación de severidad de 7.5. El exploit hecho vulnerable a los ataques de rehacer. Parches fueron rápidamente liberados, y fueron capaces de arreglar el problema rápidamente.

Pero eso no es todo. Un montón de nuevas hazañas Haz descubierto cada semana. Algunos de ellos Obten divulgadas al público, pero otros hacen encabezados sólo después de una infracción grave.

Entonces, ¿cómo nos mitigar estos riesgos? En este artículo voy a explicar algunas de las mejores prácticas estándar de la industria que puede utilizar para garantizar sus dependencias de código abierto.

1. Realizar un Seguimiento de las Dependencias de Su Aplicación

Lógicamente hablando, como el número de dependencias, el riesgo de acabar con un paquete vulnerable también puede aumentar. Esto es válido igualmente para las dependencias directas e indirectas. Aunque no es necesario que debe dejar de utilizar paquetes de código abierto, siempre es una buena idea hacer un seguimiento de los.

Estas dependencias son fácilmente visible y pueden ser tan simples como ejecutar npm ls en el directorio raíz de la aplicación. Se puede utilizar –prod argumento que muestra todas las dependencias de producción y el –long argumento para un resumen de la descripción de cada paquete.

Además, puede utilizar un servicio para automatizar el proceso de gestión de la dependencia que ofrece monitorización en tiempo real y actualización automática de pruebas para sus dependencias. Algunas de las herramientas familiares incluyen GreenKeeper, Libraries.io, etcetera. Estas herramientas recopilar una lista de las dependencias que actualmente estás utilizando y pista información relevante con respecto a ellos.

2. Deshacerse de los Paquetes Que No Necesita

Con el paso del tiempo y los cambios en el código, es probable que te deje de usar algunos paquetes en conjunto y en su lugar añadir nuevos. Sin embargo, los desarrolladores no suelen eliminar paquetes antiguos como van a lo largo.

Con el tiempo, su proyecto podría acumular un montón de dependencias sin usar. Aunque esto no es un riesgo directo de seguridad, estas dependencias seguramente añadir a la superficie de ataque de su proyecto y llevan a confusión innecesaria en el código. Un atacante puede ser capaz de encontrar una escapatoria por la carga de un paquete viejo pero instalado que tiene un cociente más alto de vulnerabilidad, aumentando así el daño potencial que puede causar.

¿Cómo revisas para tales dependencias sin usar? Puede hacer esto con la ayuda de la herramienta depcheck. Depcheck analiza el código entero para requires y los comandos de import. A continuación se correlaciona estos comandos con paquetes instalados o los mencionados en su package.json y le proporciona un informe. El comando se puede modificar usando los parámetros de comandos diferentes, lo que sea más sencillo automatizar la comprobación de dependencias sin usar.

Instalar depcheck con:

3. Encontrar y Solucionar las Vulnerabilidades de Seguridad Crucial

Casi todos los puntos tratados anteriormente se refieren principalmente a los posibles problemas que pueden surgir. Pero ¿qué pasa con las dependencias que estás usando ahora?

Basado en un estudio reciente, casi el 15% de los paquetes actuales incluyen una vulnerabilidad conocida, en los componentes o las dependencias. Sin embargo, la buena noticia es que hay muchas herramientas que puede utilizar para analizar el código y encontrar los riesgos de seguridad de código abierto dentro de su proyecto.

La herramienta más conveniente es npm audit de npm. Auditoría es un script que fue lanzado con la versión de MNP 6. Plataforma de seguridad de nodos había desarrollado inicialmente auditoría de gestión, y MNP registro lo adquirió más tarde. Si tienes curiosidad saber qué gestión de auditoría es todo sobre, aquí es una cita del blog oficial:

Una auditoría de seguridad es una evaluación de las dependencias de paquete para vulnerabilidades de seguridad. Auditorías de seguridad ayuda que proteger los usuarios de su paquete por lo que le permite encontrar y reparar vulnerabilidades conocidas en las dependencias. El comando de la auditoría de gestión presenta una descripción de las dependencias en su paquete en su registro de forma predeterminada y pide un informe de vulnerabilidades conocidas.

El informe generado generalmente consta de los siguientes datos: el nombre del paquete afectado, gravedad de la vulnerabilidad y descripción, ruta de acceso y otra información y, si está disponible, ordena aplicar parches para solucionar vulnerabilidades. Incluso, pueden obtener el informe de auditoría en JSON ejecutando npm audit --json.

Aparte de eso, MNP también ofrece asistencia en la forma de actuar basada en el informe. Puede usar npm audit fix para fijar cuestiones que ya han sido encontradas. Estas correcciones se logran comúnmente mediante actualizaciones guiadas o a través de parches de código abierto.

No dude en para más información, consulte la documentación de npm.

4. Reemplazar Bibliotecas Caducado Con Alternativas Internas

El concepto de seguridad de código abierto es pesadamente dependiente en el número de ojos que están viendo en eso Biblioteca particular. Paquetes que se utilizan activamente son mirados más de cerca. Por lo tanto, hay una mayor probabilidad que el desarrollador podría han abordado todos los problemas de seguridad conocidos en ese paquete en particular.

Tomemos un ejemplo. En GitHub, hay muchos JSON web token las implementaciones que se pueden utilizar con la biblioteca de Node.js. Sin embargo, los que no están en desarrollo activo podrían tener vulnerabilidades críticas. Un tal vulnerabilidad, que fue reportado por Auth0, nadie permite crear sus propios símbolos "firmado" con cualquier carga que deseen.

Si un paquete razonablemente popular o bien utilizado tenía este defecto, las probabilidades de que un desarrollador encontrar y remendar el error sería mayores. Pero, ¿un proyecto inactivo/abandonado? Vamos a hablar en el punto siguiente.

5. Siempre Elegir una Biblioteca que Está en Desarrollo Activo

Tal vez es la forma más rápida y más eficiente para determinar la actividad de un paquete específico comprobar su tasa de descarga en la nueva gestión pública. Usted puede encontrar esto en la sección de Estadísticas de la página del paquete de npm. También es posible extraer estas cifras automáticamente usando las estadísticas de npm API o navegando estadísticas históricas en npm-stat.com. Para paquetes con repositorios GitHub, usted debe comprobar fuera la historia de commit, el issue tracker de y las solicitudes de extracción pertinente para la biblioteca.

6. Actualizar las Dependencias Con Frecuencia

Hay muchos errores, incluyendo un gran número de errores de seguridad que sean continuamente desenterradas y, en la mayoría de los casos, inmediatamente parchada. No es raro ver vulnerabilidades recientemente divulgadas se fija únicamente en la rama/la versión más reciente de un determinado proyecto.

Por ejemplo, tomemos la vulnerabilidad de la expresión de denegación de servicio Regular (rehacer) informada sobre el paquete HMAC 'Halcón' en 2016 temprano. Este fallo en Halcón fue resuelto rápidamente, pero sólo en la última versión, 4.x. versiones antiguas como 3.x fueron parcheadas mucho más tarde aunque igualmente estaban en riesgo.

Por lo tanto, como regla general, sus dependencias son menos propensos a tener algún error de seguridad Si utiliza la última versión disponible.

La forma más fácil de confirmar si usted está utilizando la versión más reciente es mediante el comando de npm outdate. Este comando admite la bandera -prod ignorar cualquier dev dependencias y --json, para simplificar la automatización.

Inspeccione regularmente los paquetes que utilice para verificar su fecha de modificación. Usted puede hacer esto de dos maneras: vía el MNP interfaz de usuario, o ejecutando npm view <package> time.modified.

Conclusión

La clave para asegurar la aplicación debe tener una cultura de seguridad-primero desde el principio. En este post, hemos cubierto algunas de las prácticas estándar para mejorar la seguridad de los componentes de JavaScript.

  1. Utilizar dependencias de código abierto que están en desarrollo activo.
  2. Actualizar y monitorear sus componentes.
  3. Revisar el código y escribir ensayos.
  4. Quite las dependencias no deseadas o utilizar alternativas.
  5. Utilizar herramientas de seguridad como npm audit para analizar sus dependencias.

Si tienes alguna idea sobre la seguridad de JavaScript, dude en compartirlos en los comentarios.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.