Como los scripts de terceros entran en un sitio web
Al desarrollar un sitio web, a menudo incluirás bibliotecas para ayudar a acelerar el proceso de desarrollo y evitar reinventar la rueda. Sin embargo, hay ocasiones en las que necesitas cargar un script desde una fuente externa. Debido a ataques recientes como la toma de control del dominio Polyfill, se han planteado preguntas: ¿por qué siquiera necesitas scripts de terceros? ¿Cómo terminan en un sitio web?
Primero, establezcamos el contexto. Los scripts de terceros son archivos JavaScript servidos desde un servidor distinto al tuyo. Por ejemplo, supongamos que administro mi sitio web, cside.com. Este sitio web fue creado por un equipo de desarrolladores, quienes usaron varias bibliotecas para armarlo. Esto luego se compila / transforma / divide en archivos JavaScript más pequeños y menos numerosos de lo que originalmente era el código fuente. Esto es lo que llamamos JavaScript de primera parte: se sirve como un recurso dentro de cside.com, por ejemplo cside.com/_next/static/chunks/main-ab76c1828cff9b09.js.
Una semana después, un miembro del equipo de marketing le pide a los desarrolladores que agreguen un script al sitio para su producto de análisis preferido. Ahora, el sitio tiene su primer JavaScript de terceros. Este proceso puede continuar con el equipo legal solicitando un banner de cookies, marketing pidiendo otro script de análisis, y así sucesivamente.
Los desarrolladores conocen los riesgos del JavaScript de terceros, así que buscan en línea información sobre la herramienta, investigan un poco y la consideran confiable.
Este ciclo se repite hasta que hay una docena de scripts o más en la página. Todos legítimos, todos importantes y todos de terceros. En el peor de los casos, uno de estos dominios es comprado, se sirve tráfico malicioso y tu sitio se infecta.
Pero esto es exagerado, y no es así como suelen ocurrir los ataques. Los scripts de nivel superior en tu sitio generalmente no son los que se atacan, aunque eso es posible (consulta nuestro análisis de Polyfill aquí). A menudo, los scripts cargan otros scripts. Algunos scripts incluso pueden crear iframes y cargar aún más scripts. Así como tu código de primera parte usa varias dependencias, los scripts de terceros también tienen requisitos para hacerse funcionales y tienen su propia cadena de suministro.
A veces, incluso las bibliotecas de primera parte que agregas pueden cargar un script durante el tiempo de ejecución. Pueden proporcionar un componente React práctico para colocar en tu página, pero detrás de escena están agregando algunos scripts para hacerse funcionales. Ya sea cargando localización, sus propios análisis, temas o más, están agregando a la cadena de suministro de terceros de tu sitio web.
Entonces podrías pensar: ¿por qué no simplemente descargar estos scripts y alojarlos tú mismo? Para algunos scripts básicos, como jQuery, esta es una opción obvia, y una que recomendamos. Si estás tratando con un script estático en la cadena de suministro de tu sitio, llévalo a tu origen si es posible.
Sin embargo, muchos scripts sirven contenido dinámico basado en el solicitante. Por ejemplo, pueden mirar tu User Agent en la solicitud y decidir que necesitas una versión diferente con características adicionales. O pueden mirar tu IP y decidir enviarte una localización diferente del script.
Estos siguen siendo estáticos por usuario la mayor parte del tiempo, pero lo importante es que no son estáticos globalmente. Esto significa que al servir el script tú mismo, solo estarías sirviendo una variación, no el conjunto completo de scripts necesarios para dar a tus usuarios la mejor experiencia.
Algunos scripts incluso pueden tener URLs codificadas de forma fija a sub-scripts que cargarán. Esto significa que incluso si copias el script raíz a tu sitio, seguirá cargando scripts externos desde una URL remota.
Incluso las bibliotecas que podrías estar usando todos los días en tu aplicación siguen este patrón. Veamos algunos ejemplos:
El paquete npm de Intercom carga un montón de scripts en tiempo de ejecución:
https://developers.intercom.com/installing-intercom/web/installation#single-page-app
Incluso al usar herramientas de seguimiento de redes sociales, que son inevitables para la mayoría de las empresas que hacen marketing en redes sociales, lo primero que hacen los scripts que te dan es cargar otro script de terceros:
O usas un paquete React como @monaco-editor/react, con más de 712,000 descargas semanales, que carga un script de terceros para gran parte de su funcionalidad: https://www.npmjs.com/package/@monaco-editor/react
Entonces, ¿hacia dónde vamos desde aquí? Por eso existe cside. Hacemos proxy de cada script que se carga en la página, incluso los que se cargan durante el tiempo de ejecución. Reescribimos las URLs de los scripts para que pasen por nuestro Proxy de cside, que puede bloquear un script antes de que siquiera se sirva al cliente.
Nuestro proxy ofrece un punto de vista único: permitiendo políticas por URL, por dominio, por hash, por encabezados que pueden implementarse globalmente en segundos. Si algún script intenta cargar un script hijo, cside lo sabrá y le hará proxy. Y luego te dará el control para decidir qué sucede: permitir este script, bloquear este script, y los análisis que lo acompañan.
Por cada script que ve nuestro proxy, lo entregamos a nuestro motor de detección. Nuestro motor de detección desarma el script, hasta el nivel de AST, para descubrir qué hace. Y hacemos esto por cada pequeño cambio en un script, incluso si es un carácter. Podemos informarte de lo que está haciendo un script, cuándo cambia su acceso a tu sitio y una gran cantidad de información de confianza sobre la fuente.
Tenemos analistas de seguridad trabajando las 24 horas para detectar amenazas emergentes y bloquearlas en nuestra capa de proxy antes de que impacten a uno de tus clientes. Combina esto con el motor de detección automática mencionado anteriormente, y ahora tienes control total sobre la cadena de suministro de terceros de tu sitio.
Puedes registrarte en nuestro nivel gratuito aquí.
¿Te interesa la cadena de suministro del navegador? Si es así, únete a nosotros en la misión de proteger a cada usuario de la World Wide Web: https://cside.com/careers
