Riesgos de seguridad de los scripts JavaScript de terceros

En su charla sobre seguridad web en SnykCon 2020, Liran Tal y Eric Graham hablaron sobre aspectos de seguridad del frontend relacionados con la superficie de ataque. Describieron los riesgos derivados de las vulnerabilidades de seguridad en dependencias de terceros y luego ampliaron el análisis para incluir el riesgo potencial de los scripts de terceros agregados por marketing, como Google Tag Manager.

En este artículo, analizamos los riesgos de seguridad que generan los scripts relacionados con marketing que se agregan a un sitio web, como los servicios de pruebas A/B, Google Analytics y otros, y mostramos cómo mitigarlos.

Play Video: Securing Front-end Attack Surfaces - Eric Graham and Liran Tal

¿Qué riesgos de seguridad plantean los scripts de terceros en la seguridad web?

Para responder esa pregunta, en el video Eric Graham explora paso a paso cómo se agrega código de terceros a aplicaciones web y sitios web estáticos. Muestra hasta qué punto estos incluyen código fuente de distintos proveedores y mantenedores de código abierto.

Como puedes ver, el código que escriben los desarrolladores de tu equipo representa solo una pequeña parte del código total que se entrega a tus clientes. También hay scripts para pruebas A/B o de usabilidad, o para actividades de marketing y ventas, como segmentar usuarios o mejorar el embudo de ventas.

¿Cómo y por qué se agregan scripts de terceros a un sitio web?

Para empeorar las cosas, suelen agregarlos los equipos de marketing y los administradores web, fuera del ciclo de vida del desarrollo de software y del pipeline de CI/CD, por lo que evitan por completo las revisiones de código y las pruebas de los desarrolladores. El software que se usa para esto se llama administrador de etiquetas. Entre los proveedores más conocidos están Google (GTM) y Adobe, que usa Launch (sucesor de Dynamic Tag Manager o DTM).

A su vez, esos administradores de etiquetas cargan otros scripts, lo que abre aún más conexiones HTTP a distintos dominios. Esos dominios podrían ser vulnerados, lo que permitiría distribuir malware. Esto nos lleva al terreno de la publicidad maliciosa, por así decirlo.

Los profesionales de marketing y los ingenieros de analítica usan habitualmente scripts JavaScript de terceros para ampliar las capacidades de un sitio web con el fin de impulsar el crecimiento, segmentar usuarios y mejorar el embudo de ventas. Un ejemplo popular es la herramienta GTM o Launch de Adobe, una mejora considerable respecto de su predecesora, Dynamic Tag Manager (DTM).

Debido al impacto que estos scripts tienen en el pipeline de marketing, los equipos de marketing de producto y analítica suelen preferir experimentar rápidamente e insertar scripts adicionales en un sitio web o una aplicación web.

¿Se auditan estos scripts de marketing de terceros para revisar su seguridad?

¿Estos equipos se acuerdan de eliminar los scripts de terceros de la aplicación web cuando dejan de usarlos? No siempre está garantizado y pueden pasar desapercibidos. Por lo tanto, podrías estar ejecutando código no confiable sin siquiera saberlo.

Las actividades de estos scripts JavaScript de terceros agregados a una página web evaden por completo el pipeline de DevOps y cualquier proceso o pauta de seguridad incorporados durante el desarrollo.

Además, como se inyectan directamente en el DOM, los terceros obtienen acceso a todas las funciones que también tendrían a su disposición tus desarrolladores. Esto puede causar estragos en tus clientes.

Los medios han cubierto varios incidentes de seguridad relacionados con la inyección maliciosa de scripts JavaScript de terceros en aplicaciones web, e incluso casos en los que hackers ocultan un capturador de datos de tarjetas en los archivos CSS de un sitio web. Esto ocurrió después de otros incidentes de seguridad relacionados con scripts Magecart incluidos en favicons, mensajes de chat en vivo y botones para compartir en redes sociales.

¿Podemos resolver los problemas de seguridad de JavaScript de terceros?

Para resolver nuestros problemas de seguridad de JavaScript, exploremos mejores maneras de admitir JavaScript de terceros en el código de un sitio web y mitigar o reducir los riesgos de seguridad.

Enfoques técnicos

Una opción es incluir JavaScript de terceros en un iFrame y luego restringirlo mediante los atributos allow o sandbox, o ambos. Ten en cuenta que esto puede impedir que funcione como se espera.

Otra alternativa sería aplicar integridad de subrecursos (SRI), pero para eso, el proveedor de esos scripts debe compartir los valores hash del contenido de las bibliotecas. Sin embargo, el contenido suele estar personalizado y, por lo tanto, es dinámico.

El grupo de trabajo del W3C propuso un estándar para recopilar métricas sobre el comportamiento de los usuarios y otras necesidades en el siguiente documento: Customer Experience Digital Data Layer 1.0. En la sección 6.11 se declara qué grupo de scripts de terceros debería acceder a ciertos tipos de datos. Sin embargo, la aplicación de esta norma queda a cargo de quien mantiene la capa de datos.

Enfoques culturales

Como los enfoques técnicos no son suficientes, exploremos los culturales.

¿Debería marketing formar parte del proceso del ciclo de vida del desarrollo de software y tener que enviar sus cambios a través de un pipeline de DevOps? La colaboración con los ingenieros es ideal, pero no es fácil superar las diferencias de prioridades del negocio ni lograr la comunicación entre departamentos.

¿Monitoreas activamente todas las solicitudes HTTP que realiza tu aplicación web o dominio? Puedes usar herramientas como Page Integrity Manager de Akamai o la herramienta web gratuita y de código abierto WebPageTest para monitorear las solicitudes HTTP e incluso integrarla en tu pipeline de integración continua (CI).

Por último, una cultura organizacional puede ayudar a reforzar una mentalidad centrada en la privacidad entre ingenieros y profesionales de marketing al implementar analítica y otros widgets JavaScript de terceros.

Conclusión

La superficie de ataque del frontend es amplia: comienza con el código fuente de tu propia aplicación web y sus dependencias, y se extiende a los scripts de terceros que se agregan fuera del proceso de desarrollo.

Además de adoptar enfoques técnicos, promueve un cambio cultural para mantener la seguridad en Internet.

Para obtener más información, consulta estos recursos:

1. Explora la tendencia de la arquitectura basada en eventos que Jim Gordon describe en su publicación: https://jimalytics.com/tag-management/the-event-driven-data-layer.

2. Lee el blog de Jan Exner en https://webanalyticsfordevelopers.com, donde explica la analítica web para desarrolladores en términos que los ingenieros pueden entender.

3. Mira la charla de SnykCon Cómo proteger las superficies de ataque del frontend, que explica el alcance de este riesgo de seguridad.