Angular vs. React: el riesgo de seguridad de las dependencias indirectas

Te damos la bienvenida al informe de Snyk sobre el estado de la seguridad de los frameworks de JavaScript en 2019.

En esta sección, analizamos el riesgo de seguridad de las dependencias indirectas de Angular y React, y luego revisamos las dependencias directas, primero de Angular y después de React.

Descarga el informe aquí!

Los módulos analizados en esta parte no representan una lista completa de los módulos vulnerables de React y Angular; algunos pueden tener convenciones de nombres especiales (por ejemplo, todos los módulos con prefijos ng-, angular- o react-) que no aparecerían en la búsqueda basada en patrones que realizamos.

El riesgo de seguridad de las dependencias indirectas

La mayoría de las veces, los proyectos basados en React o Angular se generan con una herramienta de scaffolding que proporciona una plantilla básica para comenzar a desarrollar. En React, la práctica habitual entre desarrolladores es usar el paquete npm create-react-app, que crea un punto de partida para el proyecto con una configuración previa, por ejemplo, con el framework de pruebas Jest, procesadores CSS y otras herramientas integradas. En Angular, esto es posible gracias al paquete npm @angular/cli.

Para comparar el estado de las dependencias y la seguridad (que reflejan el nivel general de riesgo de seguridad) de las plantillas básicas de React y Angular, generamos un proyecto de muestra y obtuvimos buenas noticias: ambos incluyen dependencias de desarrollo con vulnerabilidades, pero ninguno tiene problemas de seguridad en sus dependencias de producción.

A continuación, se muestran las vulnerabilidades de seguridad que se introducen en tu código desde el principio al iniciar un proyecto con la plantilla básica de Angular o React:

Cabe señalar que Angular depende de 952 dependencias, que contienen dos vulnerabilidades en total; React depende de 1257 dependencias, que contienen tres vulnerabilidades y un posible problema de compatibilidad de licencias.

Una nota sobre las licencias de software de código abierto

En cuanto a las licencias, consideramos que el cumplimiento de las licencias es un factor importante para la salud general de las dependencias, además de los problemas de seguridad. Por eso, también incluimos verificaciones de licencias en nuestros análisis. Los resultados que obtuvimos se basaron en las configuraciones predeterminadas definidas para nuestras políticas de licencias antes del análisis.

Según esos resultados, el proyecto de React generado depende del paquete mdn-data, que a su vez usa la licencia copyleft MPL-2.0 de Mozilla. Si planeas distribuir tu aplicación de React mediante instalaciones on-premises u otras configuraciones similares que incluyan la dependencia mdn-data, debes revisar los requisitos de licencia para asegurarte de que tu proyecto los cumpla.

Además, recomendamos analizar tus proyectos según las indicaciones de las políticas específicas de tu organización, que podrían señalar o no dependencias indirectas adicionales de React.

Corrección de rutas vulnerables

Una ruta describe cómo se incorpora una dependencia de código abierto a tu proyecto. Por ejemplo, supongamos que tienes dos dependencias directas llamadas Proyecto A y Proyecto B. Ambas incorporan la dependencia Proyecto C. Proyecto C queda asociado a dos rutas distintas porque tanto Proyecto A como Proyecto B lo instalan. Si Proyecto C incluye vulnerabilidades, el desarrollador debe considerar ambas rutas para corregirlas.

En React, las tres vulnerabilidades se distribuyen en 16,293 rutas vulnerables. Corregirlas mediante actualizaciones de paquetes se vuelve una tarea abrumadora cuando hay tantos paquetes en la cadena de dependencias que requieren una actualización. En cambio, las dos vulnerabilidades de Angular se corrigen fácilmente a través de solo dos rutas vulnerables.

La siguiente imagen se tomó de un informe de análisis de seguridad de agosto de 2019 para un proyecto generado con el paquete npm create-react-app de React. El informe muestra el problema de la cadena de dependencias que debe abordarse para una sola vulnerabilidad de seguridad.

Para corregir la vulnerabilidad, hay que incorporar nuevas versiones de lodash desde cada uno de los paquetes afectados en toda la cadena de dependencias.

Debido al uso extendido de lodash en todo el ecosistema, su versión vulnerable termina utilizándose en miles de rutas de dependencias.

Vulnerabilidades en el ecosistema de módulos de Angular

En el ecosistema de Angular, las vulnerabilidades de los módulos se manifiestan en tres áreas:

• Módulos del ecosistema de Angular

• Versiones maliciosas de módulos

• Herramientas para desarrolladores. Al analizar el ecosistema de módulos de Angular, observamos que los siguientes módulos se destacan por su cantidad de descargas y las vulnerabilidades asociadas:

Si ordenamos los tipos de vulnerabilidad según la cantidad de descargas de los módulos que las contienen, vemos claramente que las vulnerabilidades XSS encabezan la lista, como también se indica en los 10 principales riesgos de OWASP de seguridad web que debes tener en cuenta:

Módulos maliciosos de Angular

En total, identificamos tres versiones maliciosas publicadas de los siguientes módulos de Angular: angular-bmap, ng-ui-library, ngx-pica.

angular-bmap quizá sea el caso menos interesante, como puede observarse en su página de estado de dependencias: tiene ocho versiones publicadas, todas de septiembre de 2017. Sin embargo, se publicó la versión 0.0.9 de angular-bmap con código malicioso que extrae de los formularios información confidencial sobre contraseñas y tarjetas de crédito y la envía a la URL controlada por el atacante https://js-metrics.com/minjs. php?pl=. Esta versión maliciosa 0.0.9 se retiró del registro de npm.

A diferencia del módulo bmap de Angular, ng-ui-library sigue en mantenimiento y tiene más de 150 versiones publicadas, siete de ellas solo en 2019. Sin embargo, se descubrió que la versión 1.0.987 de ng-ui-library contiene el mismo código malicioso que vimos en angular-bmap. ng-ui-library sigue teniendo entre 400 y 3000 descargas al mes.

Al código malicioso que recopila información de tarjetas de crédito se suma una versión maliciosa de ngx-pica, un módulo compatible con Angular v5 y Angular v7 que permite cambiar el tamaño de imágenes en el navegador y registra unas 800 descargas mensuales.

Curiosamente, todas estas versiones maliciosas se detectaron hace poco. Se divulgaron en junio de 2019, aunque para entonces el código malicioso ya se había publicado en una versión lanzada un mes antes.

Herramientas para desarrolladores de Angular

Como parte de los hallazgos sobre el ecosistema de módulos, detectamos un módulo que se usa como servidor HTTP de propósito general para servir recursos de aplicaciones de una sola página en proyectos creados con Angular, React, Vue y otros.

Se descubrió que el módulo angular-http-server era vulnerable a ataques de recorrido de directorios, en dos ocasiones. Ambas versiones vulnerables tienen un año de antigüedad y ya se publicaron media docena de versiones más recientes. Aunque el responsable del mantenimiento del módulo afirma claramente que no se recomienda usar esta herramienta como servicio listo para producción, sus descargas han aumentado este año: en mayo de 2019 se registraron 20,670.

Dado el creciente uso de esta herramienta de servidor HTTP para Angular, cabe señalar que existe un exploit público para esta vulnerabilidad.

Vulnerabilidades en el ecosistema de módulos de React

Al igual que en Angular, descubrimos que en algún momento se publicaron varios módulos maliciosos en el ecosistema de React. A continuación, se muestra la distribución de los tipos de vulnerabilidades de seguridad y su cantidad en todos los módulos vulnerables que encontramos; se destacan cuatro paquetes maliciosos: react-datepicker- plus, react-dates-sc, awesome_react_utility, react- server-native.

Los cuatro módulos maliciosos contienen el mismo código que recopila información de tarjetas de crédito y otros datos confidenciales; este ataque también comprometió módulos del ecosistema de React.

Esto refuerza la importancia de que quienes mantienen proyectos de código abierto habiliten la autenticación multifactor, como la compatibilidad con 2FA que ofrece el registro de paquetes de npm, para evitar poner en riesgo a sus usuarios si alguien compromete su cuenta y publica versiones maliciosas de su paquete.

Si aún no lo hiciste, te recomendamos habilitar 2FA en tu cuenta de desarrollador de npmjs.org y seguir otras prácticas recomendadas de seguridad de npm.

Módulos vulnerables destacados que detectamos en el ecosistema de React:

• Una vulnerabilidad XSS de gravedad alta en react-marked-markdown no tiene una solución disponible, pero este wrapper de componente React para la biblioteca JavaScript de Markdown marked sigue registrando miles de descargas: 65,790 en los últimos 12 meses.

• Si usas preact, la biblioteca preact-render-to-string es vulnerable a secuencias de comandos entre sitios en todas las versiones anteriores a la 3.7.2. Su uso ha aumentado durante los últimos 12 meses y suma 3,228,049 descargas en ese período.

• Si usas tooltips en tu aplicación frontend de React, quizá utilices react-tooltip, que estuvo a punto de alcanzar el millón de descargas (994,903) solo en julio de 2019. Sin embargo, esta biblioteca es vulnerable a ataques de secuencias de comandos entre sitios en todas las versiones anteriores a la 3.8.1, según se divulgó en septiembre de 2018.

• Si trabajas mucho con SVG, es muy probable que uses react-svg, que registra 1,446,442 descargas en los últimos 12 meses. En abril de 2018, el investigador de seguridad Ron Perris divulgó una vulnerabilidad de secuencias de comandos entre sitios de gravedad alta que afecta a todas las versiones anteriores a la 2.2.18.

• En marzo de 2019 se divulgó una vulnerabilidad de inyección CSV en mui-datatables. Esta biblioteca de React ofrece un componente de interfaz de usuario para mostrar datos en tablas basado en el framework Material UI y registra más de 350,000 descargas en los últimos 12 meses.

Al hacer un seguimiento de todos los módulos vulnerables de React que encontramos, contamos ocho vulnerabilidades de seguridad en los últimos tres años: dos en 2017, seis en 2018 y dos hasta agosto de 2019. Esto demuestra la importancia de usar el código abierto de forma responsable y de encontrar y corregir las vulnerabilidades lo más rápido posible.

En detalle: vulnerabilidades de seguridad de Next.js

Next.js es el popular framework de React desarrollado por ZEIT, que permite a los desarrolladores web aprovechar sus conocimientos de React para crear aplicaciones web optimizadas para SEO, aplicaciones con renderizado del lado del servidor, aplicaciones web progresivas (PWA) e incluso aplicaciones basadas en Electron, todo con el framework Next.js.

Next.js sigue ganando popularidad entre los desarrolladores, con 8,414,925 descargas en los últimos 12 meses. A medida que el proyecto crece, es cada vez más importante revisar su estado de seguridad.

Durante 2017 y 2018, detectamos tres vulnerabilidades graves de Directory Traversal y dos vulnerabilidades de Cross-Site Scripting de gravedad media que afectaban al framework de React Next.js. También cabe destacar que el equipo de seguridad de ZEIT solucionó rápidamente las cinco vulnerabilidades y publicó una corrección para el framework Next.js, disponible mediante una actualización, en menos de una semana.

En general, ZEIT aplica prácticas de seguridad sólidas que otros proyectos de código abierto deberían replicar. Entre las más destacadas se encuentran:

• El equipo responde rápidamente a las notificaciones de seguridad y publica correcciones oportunas. Esto reduce el período en que existe un riesgo real para la seguridad. ZEIT ofrece a los usuarios una ruta de actualización para que puedan mitigar rápidamente las vulnerabilidades.

• Para evitar regresiones de seguridad, el equipo escribió pruebas unitarias de seguridad que garantizan que los errores de seguridad no se repitan.

• Las notas de la versión comunican con claridad la información relacionada con la seguridad, su impacto y los pasos que deben seguir los usuarios para mantenerse al día con las correcciones de seguridad.

• El proyecto cuenta con una lista de correo dedicada a los reportes de seguridad, una política de divulgación responsable y una dirección de correo electrónico específica para reportar problemas.

ZEIT y la forma en que gestiona el framework Next.js son un gran ejemplo de buenas políticas de seguridad para proyectos de código abierto. ZEIT se toma estos asuntos en serio y demuestra un verdadero compromiso con la seguridad general de sus usuarios, mediante políticas y acciones que otros deberían adoptar.

Descarga el informe aquí.

Continúa con los aspectos destacados de la siguiente sección:

• Informe sobre el estado de la seguridad de los frameworks de JavaScript de 2019

• Angular vs. React: competencia de seguridad de 2019

• Comparación lado a lado de las vulnerabilidades de seguridad de Angular y React en 2019

• 10 prácticas recomendadas de seguridad para React

• Comparación de las prácticas de programación segura de React y Angular

• El 84 % de todos los sitios web se ve afectado por vulnerabilidades XSS de jQuery

También puedes descargar la versión completa del informe en formato digital.