Cómo probar los límites de confianza entre funciones

Las pruebas de límites de confianza entre funciones comprueban si una capacidad segura en una parte de la aplicación deja de serlo cuando otra función puede acceder a ella. Empieza por lo que controla un atacante, sigue cada conexión hacia un contexto con más privilegios y prueba las combinaciones que permiten cruzar ese límite. Que una función supere sus propias comprobaciones de seguridad solo aporta una parte de las pruebas.

Para un equipo de seguridad pequeño, el resultado útil es concreto: una matriz breve de estados de las funciones, un informe que muestre la capacidad a la que se pudo acceder y una nueva prueba que cubra las variantes desplegadas. Puedes empezar con un único elemento compartido y los componentes que reciben mensajes o renderizan contenido en su nombre.

Una vista previa puede estar aislada y su receptor confiar demasiado

En su informe del 28 de octubre, Parameter describió una cadena en ChatGPT que combinaba una conversación compartida, un gráfico y una vista previa HTML. Según los investigadores, el gráfico cargaba MathLive en la página principal. La vista previa podía entonces enviar mensajes a un receptor que aceptaba HTML para la distribución del teclado sin comprobar debidamente el remitente. Esa ruta de renderizado creaba un marco sin aislamiento; un punto de acceso a scripts de terceros permitido proporcionaba una vía para superar la CSP.

Parameter demostró el acceso a datos de conversaciones privadas a través de la sesión iniciada. Su reproducción más estable requería abrir la conversación compartida y pulsar Preview. También notificó tres reproducciones en las que Preview se abría automáticamente. Parameter afirma que OpenAI confirmó el 26 de octubre que ambas versiones del frontend web rechazaban los mensajes descritos en el informe.

Estos hallazgos proceden de los investigadores; no son pruebas que hayamos realizado. La conversación en Hacker News aporta el contexto de actualidad. La lección práctica es probar cómo se transfieren permisos entre funciones independientes, incluidas las rutas que permiten publicarlas o compartirlas.

Esta tarea difiere de comprobar si un texto malicioso puede desviar a un agente. La inyección de instrucciones en la ruta de obtención de contenido de un agente de selección trata de cómo el contenido recuperado influye en un asistente que utiliza herramientas. Un receptor del navegador que acepta una instrucción no autorizada puede fallar sin que nadie tenga que persuadir a un modelo. También difiere del aislamiento entre clientes de un proveedor, donde la cuestión es si el procesamiento posterior separa correctamente a los clientes.

Localiza el punto donde los datos se convierten en permisos

Un mapa de límites debe identificar tanto la entrada no fiable como la operación privilegiada en la que puede influir. «La vista previa está aislada» describe un componente. No explica qué hará la aplicación que la contiene cuando esa vista previa envíe un mensaje.

Dibuja el recorrido con palabras sencillas:

1. Alguien ajeno a la cuenta de la víctima controla un elemento compartido.
2. Al abrirlo, se carga un componente en una página autenticada.
3. Otro componente acepta una instrucción del elemento.
4. La instrucción influye en el renderizado, una petición o una acción de la cuenta.

En cada flecha, identifica al receptor y el motivo por el que acepta la entrada. ¿Comprueba un origen exacto? ¿Una ventana concreta? ¿Un tipo de mensaje? ¿Una decisión de autorización en el servidor? Si la única respuesta es que el mensaje tiene la estructura esperada, has encontrado un supuesto que conviene examinar.

La guía de MDN sobre postMessage indica que hay que comprobar la identidad del remitente y validar los datos recibidos. También recomienda especificar un origen de destino exacto al enviar mensajes. Reconocer el formato de un mensaje no otorga permiso para utilizar las capacidades del receptor.

Distingue en el mapa los permisos del navegador de los del servidor. Un servidor puede autorizar correctamente una petición como procedente del usuario con sesión iniciada, mientras que un código controlado por un atacante ha adquirido la capacidad de emitirla. La investigación debe explicar entonces cómo entró ese código en el contexto autenticado.

Crea una matriz pequeña de combinaciones de funciones

Prueba el conjunto mínimo de combinaciones que permita determinar dónde cambia el límite. Empieza por cada componente por separado y después combínalos. Incluye la ruta que otra persona utiliza realmente para abrir el elemento.

La siguiente matriz es un ejemplo de planificación para una aplicación con vistas previas compartidas. No recoge pruebas realizadas contra ChatGPT ni Kit.

Anota el comportamiento esperado antes de ejecutar cada fila. Por ejemplo: «La ventana principal rechaza un mensaje de configuración de esta vista previa porque el remitente no tiene permiso para cambiar ese ajuste». Un intento de explotación fallido por sí solo es ambiguo. Puede que el receptor lo haya rechazado o que ni siquiera se haya cargado.

Utiliza cuentas de prueba autorizadas y marcadores inocuos. Para investigar una capacidad de acceso a datos privados, crea un registro de prueba con un valor sintético inequívoco. Necesitas pruebas suficientes para demostrar el cruce del límite; recopilar registros de usuarios reales añade exposición sin mejorar la explicación.

Varía los tiempos de forma deliberada cuando los componentes se inicialicen de manera independiente. Anota si una acción solo funciona después de que se cargue otra función, si una recarga cambia el resultado y si la interfaz habitual exige un clic adicional. Estos requisitos deben figurar en el informe porque afectan a la reproducibilidad y a las condiciones en las que alguien podría encontrarse con el problema.

Aporta al triaje una capacidad demostrada, además de una alerta

Un informe útil establece qué pasó a ser posible en el contexto afectado. Una captura de una alerta puede ayudar a demostrar dónde se ejecutó JavaScript. Deja sin responder a qué datos u operaciones podía acceder esa ejecución.

Organiza el informe para que otro ingeniero pueda reproducir el resultado sin hacer suposiciones:

• Control del atacante: el elemento, campo, archivo o mensaje que puede proporcionar quien presenta el informe.
• Requisitos de la víctima: estado de la cuenta, rol, funciones activadas e interacciones necesarias.
• Límite cruzado: contexto del remitente, receptor y operación que este aceptó.
• Reproducción mínima: ruta y secuencia exactas, con datos de prueba sintéticos.
• Comportamiento esperado y observado: qué debería haberse denegado y qué ocurrió en su lugar.
• Impacto demostrado: registro privado de prueba o acción restringida concretos a los que se accedió.
• Limitaciones: tiempos inconsistentes, roles sin probar, variantes no disponibles y posibles extensiones hipotéticas.

Separa una lectura demostrada de una escritura propuesta. Si la prueba recupera un registro privado sintético, describe directamente ese impacto en la confidencialidad. Si otra acción de la cuenta parece accesible pero no se ha probado, identifícala como hipótesis. Expresiones amplias como «control total de la cuenta» no deben sustituir las pruebas concretas que el equipo necesita para evaluar el alcance.

Cuando no se pueda reproducir un informe, identifica la condición que falta antes de descartarlo. Una función complementaria, otra versión del frontend o una segunda interacción pueden explicar la diferencia. Pide ese detalle expresamente y añádelo a la matriz para que la siguiente reproducción parta del mismo estado.

Verifica la corrección del receptor en todo el recorrido

La verificación de una corrección debe establecer por qué falla ahora el cruce original. Bloquear un script en una fase posterior puede detener una demostración concreta y dejar que los mensajes no autorizados sigan influyendo en el renderizado de confianza.

Examina la decisión del receptor y vuelve a probar el recorrido desde el elemento. ¿Puede el remitente no fiable seguir cambiando el ajuste? ¿Pueden sus datos seguir llegando a un punto que los interpreta como HTML? ¿Conserva el contenido creado dinámicamente las restricciones previstas? ¿Qué control rechaza la operación y puede la prueba observar ese rechazo?

La guía de pruebas de mensajería web de OWASP aborda las comprobaciones de origen y el tratamiento de entradas. Incluso una entrada procedente de un origen permitido necesita una validación adecuada. Trata el origen, la identidad de la ventana, la estructura del mensaje y la operación permitida como cuestiones distintas.

Utiliza la matriz original para repetir las pruebas y añade variantes cercanas que justifique el código afectado. Podrían incluir otra ruta para compartir, otro componente que utilice el mismo receptor o un frontend antiguo que siga atendiendo tráfico. Evita convertir cada informe en una auditoría sin límites; sigue el mecanismo compartido y documenta dónde termina la revisión.

Comprueba también el comportamiento legítimo. Un componente autorizado debe seguir completando la operación prevista después de rechazar al remitente no autorizado. De lo contrario, una corrección que desactive la función por completo puede superar la reproducción de seguridad y romper el flujo de trabajo que necesitan los usuarios.

Distingue entre resolución y verificación

Registra por separado la corrección y las pruebas que la confirman. Un cambio desplegado demuestra que alguien ha publicado una corrección. La verificación establece qué se volvió a probar, en qué versión y con qué resultado.

El flujo de seguridad de Kit incluye estados independientes para los informes resueltos y aquellos cuya corrección se ha verificado. Esa distinción da al equipo un lugar donde seguir el traspaso entre ambos pasos. No ejecuta la matriz del navegador ni demuestra que se respete un límite; el informe sigue necesitando la reproducción, los detalles de versión y los resultados de las nuevas pruebas.

Empieza esta semana con un elemento público o que se pueda compartir. Enumera los componentes con privilegios con los que puede comunicarse, elige un receptor capaz de cambiar el estado y prueba el elemento por separado y junto con la función que carga ese receptor. El resultado debe indicar dónde se comprueban los permisos y aportar al siguiente ingeniero pruebas suficientes para verificar el mismo límite.