Cross-Site Scripting: Los gestores de marcadores deben proteger límites de seguridad críticos
Imagina que trabajas desde casa y necesitas acceder a algo de la red de tu empresa. Abres la misma página de VPN que has usado otras veces, inicias sesión como siempre y sigues con lo tuyo. La dirección web pertenece a tu empresa y la página forma parte del sistema que tu empleador te indicó que utilizaras. No hay ninguna razón evidente para pensar dos veces en lo que ocurre en segundo plano.
Un producto que muchas empresas utilizan para el acceso por VPN es GlobalProtect, de Palo Alto Networks, que permite acceder a redes privadas desde cualquier lugar. Mucha gente conoce las VPN como herramientas que utiliza en casa, pero GlobalProtect está diseñado para empresas. Los empleados inician sesión a través de su empresa y GlobalProtect utiliza un portal en línea para configurar la conexión a la red corporativa.
En 2025, investigadores divulgaron una vulnerabilidad de cross-site scripting en esa parte de GlobalProtect que funciona en el navegador. Para aprovecharla contra alguien, un atacante tendría que crear primero un enlace envenenado hacia el sitio VPN real. El enlace podía incluir información controlada por el atacante junto con la propia dirección, utilizando el mismo mecanismo general que las webs usan normalmente para pasar términos de búsqueda, identificadores u otros valores de una página a otra.
Ese enlace envenenado todavía tiene que llegar hasta una persona. Normalmente, un atacante necesitaría alguna forma de phishing o ingeniería social para conseguir que el usuario hiciera clic: un correo que parece venir del trabajo (véase: suplantación del correo electrónico), un mensaje que afirma que hay que revisar una configuración de la VPN, una conversación de soporte u otro motivo creíble para hacer clic.
Cuando la víctima abre el enlace, puede seguir llegando al sitio VPN real de la empresa. GlobalProtect lee la información incluida en la URL envenenada y la incorpora a la página que devuelve al navegador. Ese comportamiento no es raro por sí mismo: los sitios web leen constantemente valores de los enlaces y los utilizan para decidir qué mostrar.
El fallo está en cómo se coloca ese valor dentro de la página. La información controlada por el atacante debería seguir siendo texto normal, un identificador que deba verificarse o una configuración general, algo que no tenga más poder que lo escrito en un campo de formulario. Pero si el sitio introduce ese valor de una manera que el navegador interpreta como HTML, los caracteres proporcionados por el atacante pueden dejar de tratarse simplemente como texto y empezar a tratarse como instrucciones que modifican la página y pueden hacer que se ejecute JavaScript. La parte envenenada entró a través del enlace y el propio sitio de confianza la convirtió accidentalmente de datos en código.
Jira nos da otro ejemplo del mismo problema por una vía distinta. En 2021, Atlassian divulgó un fallo por el que podían guardarse y permanecer datos relacionados con proyectos controlados por un atacante. Más tarde, cuando un administrador abría la página afectada de Associated Projects, el navegador podía interpretar ese valor almacenado como contenido ejecutable.
Eso es XSS almacenado: el atacante planta primero el contenido malicioso, el sitio web lo conserva y otra persona lo activa más tarde simplemente cargando la página donde aparece.
Existen otras formas de XSS, pero la lista es amplia y la mayoría de los detalles solo resultan relevantes para desarrolladores. En un mundo perfecto, los desarrolladores impedirían este tipo de ataques desde el principio, pero en la realidad se cometen errores. Los usuarios deberían prestar atención a los enlaces que abren y al riesgo que representan el phishing y los ataques de ingeniería social.
Esto nos lleva a la idea básica del cross-site scripting, normalmente abreviado como XSS. Información que debería haber seguido siendo datos normales termina convirtiéndose en código ejecutable dentro de un sitio web en el que la gente confía.
Los navegadores normalmente intentan mantener separados unos sitios web de otros. Una página de un sitio no debería poder leer sin más información privada de otro sitio ni utilizar el acceso de una sesión iniciada allí. XSS evita esa protección de otra manera: es el propio sitio vulnerable el que hace que código controlado por un atacante se ejecute como parte de su página.
Una vez que el navegador ejecuta ese código como parte de la página de confianza, las consecuencias se vuelven mucho más concretas. Puede llegar a leer información que ya aparece en la página, observar o cambiar campos de formularios, sustituir botones y enlaces, enviar información a otros lugares y mucho más. El navegador puede adjuntar automáticamente la sesión iniciada del usuario a esas solicitudes, lo que significa que el código malicioso puede realizar acciones con la cuenta del usuario sin conocer su contraseña.
Si la persona que activa el código malicioso ha iniciado sesión como administrador, ese código puede llegar a utilizar la misma autoridad. Dependiendo de lo que permita el sitio, eso podría significar cambiar la contraseña de la cuenta, crear una clave API o un token de acceso, o añadir otro administrador. Es posible que el atacante no necesite conocer la contraseña del administrador, porque el navegador ya ha iniciado sesión y está autorizado para realizar esas acciones.
Un ataque XSS no tiene por qué terminar en el sitio web donde empezó. El servicio comprometido puede estar conectado a otros sistemas o controlar información que más tarde se abrirá en otro lugar. Eso puede convertir un ataque XSS exitoso en un punto de apoyo para otro ataque.
Un gestor de marcadores es un ejemplo especialmente interesante porque su trabajo consiste en guardar enlaces y ponerlos delante de las personas más tarde. El código malicioso con acceso a una cuenta de marcadores podría cambiar enlaces guardados, añadir otros nuevos, modificar Collections compartidas o plantar URLs especialmente construidas para atacar vulnerabilidades de otros servicios. Si esos enlaces se sincronizan o se comparten con otras personas, el atacante puede conseguir incluso un nuevo mecanismo de distribución. El segundo sitio web seguiría necesitando su propia vulnerabilidad para que otro ataque XSS tuviera éxito, pero comprometer el gestor de marcadores podría dar al atacante un lugar de confianza desde el que preparar y distribuir esos ataques.
A partir de aquí, los gestores de marcadores se convierten en un caso de seguridad interesante por sí mismos. Su trabajo consiste precisamente en aceptar enlaces de personas, guardarlos, sincronizarlos, importarlos y, en ocasiones, compartirlos con otras personas. Una función de Collections va un paso más allá: un enlace creado o controlado por una persona puede terminar delante del navegador de otra.
Eso significa que los enlaces no siempre pueden tratarse como simples cadenas de texto sin importancia. Un gestor de marcadores puede parecer una aplicación bastante sencilla de construir, pero en cuanto acepta enlaces controlados por usuarios y los mueve entre cuentas, importaciones o Collections compartidas, el tratamiento de las URL se convierte en un verdadero límite de seguridad. Los gestores pequeños y recién creados tienen que tomárselo tan en serio como los grandes.
Los marcadores JavaScript hacen que ese límite sea especialmente claro. Los navegadores los admiten desde hace mucho tiempo. En lugar de guardar un destino normal como https://example.com, un bookmarklet guarda JavaScript y lo ejecuta cuando la persona abre deliberadamente el marcador. Pueden ser extremadamente útiles para modificar una página, extraer información o iniciar una automatización.
El sistema de marcadores integrado del navegador también se ha explotado en el pasado, pero normalmente mediante un mecanismo muy distinto, a menudo relacionado con malware. En ese caso, la amenaza proviene de software que ya ha conseguido acceso al navegador. Un gestor de marcadores basado en la web tiene otro problema que resolver porque JavaScript o los enlaces envenenados pueden llegar por varios caminos que, por lo demás, son legítimos. ¿Procedía del propietario de la cuenta? ¿Se importó? ¿Llegó desde una Collection compartida? ¿Se pegó desde un sitio web que no es de confianza?
Es algo sobre lo que hemos pensado mucho en WebCull. Negarse por completo a admitir marcadores JavaScript es una respuesta de seguridad sencilla y durante mucho tiempo fue una decisión muy razonable. Pero los bookmarklets también son realmente útiles. Cada vez utilizo más WebCull dentro de mis flujos de desarrollo y automatización, y pequeños fragmentos de JavaScript pueden ser una forma extremadamente potente de conectar un marcador con una acción.
Por eso, en lugar de tratar los marcadores JavaScript como enlaces normales, WebCull los coloca detrás de un sistema de seguridad independiente. JavaScript en tus propios marcadores empieza desactivado. JavaScript procedente de Collections públicas tiene un permiso completamente independiente y también empieza desactivado. Activar uno no activa el otro.
Cuando uno de esos permisos está desactivado y abres deliberadamente un marcador JavaScript, WebCull se detiene y te da varias opciones. Puedes cancelar, usar Ejecutar una vez sin dejar activado el permiso o autorizar expresamente esa clase de JavaScript para futuras aperturas deliberadas. Si activas el permiso, los marcadores posteriores de esa misma categoría de confianza podrán ejecutarse cuando los abras deliberadamente sin otra advertencia. Por eso activar el permiso es una decisión de seguridad real y no una preferencia meramente cosmética.
Los marcadores JavaScript tampoco pueden abrirse nunca automáticamente, incluso después de activar el permiso correspondiente. En la aplicación web de WebCull, un bookmarklet autorizado se ejecuta en la página actual de WebCull, que es precisamente la razón por la que tratamos esta función como algo potente y etiquetamos estos controles como Menos seguro.
El límite de las Collections públicas importa todavía más porque el código puede haber sido proporcionado por otra persona y el propietario o un colaborador de la Collection puede cambiar más adelante lo que está guardado. Por eso JavaScript procedente de Collections públicas tiene su propio permiso en lugar de heredar el permiso de los marcadores que controlas tú.
También es algo útil que examinar al evaluar cualquier gestor de marcadores o herramienta de colecciones de enlaces. Pregunta qué ocurre cuando alguien guarda un marcador javascript:. Pregunta si los enlaces compartidos pueden convertirse en código ejecutable, si JavaScript puede abrirse automáticamente y si el código proporcionado por otra persona está separado del código que has guardado tú. Una herramienta que almacena información privada y acepta enlaces controlados por usuarios debe tratar esos límites como parte de su modelo de seguridad, no como un caso marginal.
Para quienes usan la web, los enlaces envenenados siguen siendo la advertencia más práctica que conviene recordar. Se construyen deliberadamente para explotar una debilidad en un sitio web real y suelen llegar mediante phishing u otra ingeniería social diseñada para que hacer clic parezca normal. El peligro no es que los enlaces corrientes sean intrínsecamente inseguros. Un enlace malicioso puede apuntar a un sitio real y aun así transportar información controlada por el atacante destinada a activar un fallo allí. Que alguien te pida pegar o ejecutar código es una enorme señal de alerta. Incluso abrir enlaces procedentes de una fuente no fiable es algo que conviene evitar.
Si crees que has abierto un enlace envenenado, no confíes en que la página vaya a parecer sospechosa. Un ataque XSS exitoso puede ser completamente invisible mientras se ejecuta código en segundo plano con el acceso que tu navegador ya tiene. Si tienes motivos para creer que un enlace era malicioso, sigue las instrucciones de seguridad o recuperación de cuenta de ese servicio. Cerrar las sesiones activas, revisar la actividad reciente de la cuenta y cambiar las credenciales que podrían haber quedado expuestas son precauciones razonables cuando correspondan. Si el problema es realmente una vulnerabilidad XSS, solo el operador del sitio puede corregirla.
Las vulnerabilidades de GlobalProtect y Jira descritas arriba fueron divulgadas públicamente. Sus informes públicos no documentaron una explotación confirmada en ataques reales, por lo que son ejemplos útiles de cómo pueden funcionar estos ataques y no relatos de incidentes conocidos. La guía de prevención de Cross Site Scripting de OWASP ofrece una referencia técnica mucho más profunda para quienes desarrollan sitios web.
Si utilizas marcadores JavaScript en WebCull, consulta la documentación de marcadores JavaScript. Explica los permisos independientes, la opción Ejecutar una vez y las comprobaciones de confianza que conviene realizar antes de abrir uno.