Riesgo de seguridad y cumplimiento de AngularJS

El software sin soporte es un hallazgo de auditoría esperando a ser escrito. Esta guía explica dónde está la exposición real y cómo responder a auditores y clientes con un plan que puedan aceptar.

Qué significa "sin soporte" para la seguridad

AngularJS llegó a su fin de soporte el 31 de diciembre de 2021. Desde esa fecha los mantenedores originales no publican correcciones. Los investigadores siguen encontrando vulnerabilidades en la línea 1.x, y esos hallazgos quedan abiertos en los paquetes oficiales. Tu escáner de dependencias los va a seguir reportando, y la lista solo puede crecer.

El efecto práctico es una debilidad conocida sin corrección del fabricante. Debes demostrar que la entiendes y que tienes un plan. Qué tan urgente es depende de tu exposición, y las secciones siguientes te ayudan a evaluarla.

De dónde viene la exposición

• El framework. Los problemas publicados en la línea 1.x incluyen debilidades en la sanitización y en expresiones regulares que se pueden usar para volver lenta o congelar la página. Ninguno se va a corregir en las versiones oficiales.
• Inyección en templates. Cuando una página renderizada en el servidor mezcla datos del usuario con markup que AngularJS luego compila, un atacante puede llegar a ejecutar expresiones en el navegador. Este patrón es común en apps que nacieron de páginas del lado del servidor.
• Las librerías alrededor. Versiones viejas de jQuery, plugins abandonados, kits de UI y routers antiguos. Muchas veces acumulan más hallazgos que el framework.
• La cadena de build. Versiones viejas de Node y herramientas que ya no reciben actualizaciones. Afectan más a tu pipeline que a tus usuarios, y los auditores igual las cuentan.

¿Qué tan expuesta está tu app?

Hazte estas preguntas antes de decidir qué tan urgente es el problema:

1. ¿La app es pública, o está detrás de SSO o VPN?
2. ¿Muestra contenido escrito por otros usuarios o por terceros?
3. ¿Maneja datos personales, financieros o de salud?
4. ¿El servidor inyecta datos dentro de templates de AngularJS?
5. ¿Hay una Content Security Policy, y bloquea los scripts inline?
6. ¿Alguien revisa hoy los resultados del escaneo de dependencias?

Una app pública que muestra contenido de usuarios y maneja datos de pago está en un extremo. Una herramienta interna detrás de SSO con fecha de retiro está en el otro.

Qué preguntan los auditores y los clientes

Los marcos son distintos y las preguntas comparten un tema: ¿sabes qué software usas, y corriges las debilidades conocidas en un plazo razonable?

Lo que trae problemas en una auditoría es no tener registro del riesgo, ni responsable, ni plan. Con las tres cosas, un framework sin soporte se puede tratar como un riesgo gestionado.

Cómo responder con un plan de migración

Un revisor puede aceptar una debilidad conocida cuando existen tres cosas por escrito.

1. Un registro del riesgo. Declara que el producto usa AngularJS, que no tiene soporte, qué datos maneja la app y quién es responsable del riesgo. Hazlo aprobar en el nivel que corresponda.

2. Controles compensatorios. Medidas que reducen la exposición mientras el framework sigue ahí:

• Una Content Security Policy que restrinja los orígenes de scripts.
• Ningún dato del usuario renderizado dentro de templates de AngularJS en el servidor.
• Escaneo de dependencias en CI, con un análisis documentado de cada hallazgo.
• Actualización a la última versión 1.x si estás en una anterior.
• Reemplazo temprano de las librerías de terceros más expuestas.
• Builds parchados de un proveedor comercial, como se describe en opciones de soporte extendido.

3. Un plan de migración con fechas. Esta es la parte que convierte un hallazgo abierto en uno gestionado. Debe incluir:

• El alcance: qué aplicaciones y qué módulos.
• Las fases, con una fecha objetivo para cada una.
• El orden, con las áreas más expuestas primero cuando sea posible.
• El responsable y la aprobación del presupuesto.
• Evidencia de avance que puedas mostrar en la próxima revisión.

La plantilla de hoja de ruta entrega la estructura, y medir el avance de la migración cubre la evidencia. Un plan que muestra pantallas migradas cada trimestre convence mucho más que una diapositiva que dice "migración planificada".

Qué decirle al directorio

Di tres cosas en lenguaje simple. El frontend usa un framework que ya no recibe correcciones. La exposición actual está limitada por controles concretos. Un plan con presupuesto la elimina en una fecha definida, en fases que se pueden verificar. Para ver el conjunto completo de alternativas, revisa Fin de soporte de AngularJS: tus opciones.

Más en esta sección

• Soporte extendido de AngularJS: un puente y sus límites
• Cómo armar el caso de negocio para modernizar el frontend
• Una hoja de ruta por fases para modernizar el frontend
• Cómo elegir un partner para migrar tu frontend