Taint Analysis for Graph APIs Focusing on Broken Access Control

Each language version is independently generated for its own context, not a direct translation.

¡Hola! Imagina que el mundo digital es una inmensa ciudad llena de edificios, calles y personas. En esta ciudad, los Graph APIs (las interfaces de programación de gráficos) son como el sistema de transporte y las llaves maestras que permiten a las aplicaciones moverse, ver y tocar los datos.

El problema es que, a veces, las cerraduras de las puertas de esta ciudad están mal puestas. Esto se llama "Control de Acceso Roto" (Broken Access Control). Significa que un vecino (un usuario) puede entrar a la casa de otro, robar sus secretos o incluso tirar la casa abajo, aunque no debería tener la llave.

Este artículo presenta una nueva herramienta para los guardias de seguridad (los analistas) que les ayuda a encontrar estas cerraduras rotas antes de que los ladrones las usen. Aquí te explico cómo funciona, usando analogías sencillas:

1. La Metáfora del "Tinte" (Taint Analysis)

Imagina que tienes un tinte mágico y peligroso.

El Tinte: Representa la información sensible (como contraseñas, datos bancarios o proyectos secretos).
La Mancha: Cuando un dato es "tintado", significa que es delicado y necesita protección.

El objetivo de los autores es rastrear este tinte desde que se crea hasta que se usa. Si el tinte llega a manos de alguien que no debería tenerlo, ¡tenemos un problema de seguridad!

2. Los Tres Pasos del Método

Los autores proponen un proceso de tres etapas para encontrar estos problemas:

Paso 1: El Preparativo (Setup)

El analista de seguridad toma el plano de la ciudad (el esquema de la API) y hace dos cosas:

Pinta de gris: Marca con el tinte mágico los datos importantes (por ejemplo, "Repositorios de código" o "Proyectos").
Identifica a los actores:
- Los Creadores (Sources): Son las reglas que crean o escriben esos datos manchados (como alguien que construye una casa nueva).
- Los Manipuladores (Sinks): Son las reglas que leen o modifican esos datos (como alguien que entra a la casa a pintar las paredes o robar).

Paso 2: La Inspección Estática (Static Analysis)

Aquí es donde entra la magia de las matemáticas y la lógica. En lugar de esperar a que ocurra un robo, los autores usan una técnica llamada "Análisis de Pares Críticos".

La Analogía del Tren: Imagina que los datos son trenes. El analista pregunta: "¿Existe alguna vía férrea que conecte directamente el tren que crea el dato manchado con el tren que lo va a robar?"
Usan un software (Henshin) que actúa como un detective super-rápido. Revisa todas las posibles combinaciones de reglas.
El resultado: El detective genera una lista de "rutas sospechosas". Por ejemplo: "Oye, el usuario que crea un proyecto (Creador) podría pasar la información directamente al usuario que borra el proyecto (Manipulador) sin que nadie lo vea".
La ventaja: Esto encuentra problemas teóricos muy rápido, incluso antes de que el código se ejecute en la vida real.

Paso 3: La Prueba en Vivo (Dynamic Analysis)

El paso anterior es teórico. A veces, el detective se equivoca y cree que hay un robo cuando en realidad hay una alarma que lo impide (un "falso positivo").

La Analogía del Ensayo General: Ahora, los analistas toman esas rutas sospechosas y las prueban de verdad. Crean un script (un robot) que intenta ejecutar las acciones: "Voy a intentar crear un proyecto como el dueño, y luego voy a intentar borrarlo como un empleado sin permiso".
Si el robot logra borrar el proyecto sin que el sistema le diga "¡Alto!", ¡Bingo! Han encontrado una vulnerabilidad real.
Si el sistema le dice "¡Alto!", entonces la cerradura funciona bien y la ruta es segura.

3. ¿Por qué es especial esto?

Antes, probar la seguridad de estas APIs gráficas (como las que usa GitHub) era como intentar encontrar una aguja en un pajar a ciegas. No había herramientas específicas para este tipo de "ciudad de datos".

Lo nuevo: Esta es la primera vez que combinan el rastreo de tinte (para ver el flujo de datos) con la lógica de los grafos (la estructura de la ciudad) para encontrar específicamente problemas de permisos.
El caso real: Los autores probaron su método en la API de GitHub (la plataforma donde los programadores guardan su código). Encontraron un problema real reportado por la comunidad: había una forma de comparar ramas de código que no pedía la contraseña correcta si se usaba un tipo de token específico. ¡Su método lo detectó!

Resumen en una frase

Los autores crearon un sistema de seguridad proactivo que primero pinta los datos sensibles, luego dibuja mapas de cómo podrían viajar esos datos ilegalmente usando matemáticas, y finalmente envía robots a intentar el robo para confirmar si la cerradura está rota o no.

Es como tener un arquitecto que diseña la ciudad, un detective que estudia los planos para ver dónde podrían entrar los ladrones, y un equipo de seguridad que va a probar esas puertas de verdad para asegurarse de que están bien cerradas.

Each language version is independently generated for its own context, not a direct translation.

Aquí tienes un resumen técnico detallado del artículo "Taint Analysis for Graph APIs Focusing on Broken Access Control", presentado en Logical Methods in Computer Science (2026).

1. Problema

Las APIs de Gráficos (como GraphQL) modelan datos basándose en un modelo de grafos (nodos y aristas), lo cual es fundamental para aplicaciones modernas y servicios en la nube. Sin embargo, la seguridad de estas APIs presenta desafíos únicos, especialmente en lo que respecta al Control de Acceso Roto (Broken Access Control - BAC).

El riesgo: El BAC ocurre cuando los usuarios pueden acceder o manipular datos fuera de sus permisos asignados (por ejemplo, un colaborador modificando un repositorio que solo debería ser de un propietario).
La brecha actual: Existen pocas herramientas y métodos sistemáticos para analizar la seguridad de las APIs de gráficos. Los enfoques tradicionales de análisis de flujo de datos a menudo no capturan la complejidad de las operaciones sobre estructuras de grafos dinámicas.
Necesidad: Se requiere un método que pueda detectar tanto vulnerabilidades directas (donde una llamada crea datos y otra los usa inmediatamente sin permiso) como indirectas (donde hay manipulaciones intermedias), utilizando una formalización nativa de grafos.

2. Metodología

Los autores proponen un enfoque sistemático de Análisis de Taint (Manchado) que combina análisis estático y dinámico, fundamentado en la Transformación de Grafos (Graph Transformation).

El proceso se divide en tres segmentos principales:

A. Configuración (Setup)

Formalización: La API de gráficos se modela como un sistema de transformación de grafos. El esquema de la API (ej. GraphQL) se representa como un Grafo de Tipos (Type Graph - TG) y las llamadas a la API (queries y mutations) como reglas de transformación.
Manchado (Tainting): El analista de seguridad identifica los nodos que representan datos sensibles (ej. Repository, Issue) y los marca como "manchados" (tainted) en el grafo de tipos.
Identificación de Origen y Sumidero:
- Reglas Fuente (Source): Reglas que crean instancias de nodos manchados.
- Reglas Sumidero (Sink): Reglas que leen o manipulan nodos manchados.
Política de Acceso: Se define una "oráculo de política" (una especificación de alto nivel, a veces informal) que dicta qué roles pueden ejecutar qué acciones.

B. Análisis Estático

El objetivo es identificar flujos de información manchada que podrían violar la política de acceso.

Análisis de Dependencia Crítica (Critical Pair Analysis - CPA): Se utiliza CPA para calcular automáticamente las dependencias entre pares de reglas (Fuente $\to$ Sumidero).
Flujo de Información Manchada: Se identifican todas las razones de dependencia donde un nodo manchado creado por una regla fuente es utilizado posteriormente por una regla sumidero.
Sonido y Completitud:
- El análisis es sonoro para vulnerabilidades directas (cuando el sumidero sigue inmediatamente a la fuente).
- Para vulnerabilidades indirectas (con reglas intermedias), el análisis es sonoro bajo ciertas condiciones: si las reglas intermedias son secuencialmente independientes de la fuente o del sumidero, y si la política de acceso es "estable bajo desplazamiento" (el orden de las llamadas no cambia el resultado de la política).
Salida: Una lista de dependencias que requieren revisión manual. Estas se clasifican en flujos seguros ( $S_f$ ) y inseguros ( $U_f$ ) basándose en la revisión del analista contra la política.

C. Análisis Dinámico

El objetivo es verificar si las vulnerabilidades potenciales detectadas estáticamente ocurren realmente en la implementación.

Generación de Pruebas (Taint Tests): Se generan casos de prueba automatizados (scripts) basados en los flujos identificados.
- Pruebas Positivas: Ejecutan la secuencia Fuente $\to$ Sumidero con roles que deberían tener permiso. Se espera que no haya excepción.
- Pruebas Negativas: Ejecutan la secuencia Fuente $\to$ Sumidero con roles que no deberían tener permiso. Se espera que se lance una excepción de BAC.
Criterios de Cobertura:
- Cobertura de Flujo: Asegura que cada dependencia (segura o insegura) tenga pruebas positivas y negativas.
- Cobertura de Roles: Asegura que se prueben combinaciones de roles (ej. Propietario $\to$ Colaborador) para validar la jerarquía de permisos.
Ejecución: Los scripts ejecutan las llamadas a la API real (usando tokens de autenticación) y verifican si se lanzan las excepciones esperadas.

3. Contribuciones Clave

Primer enfoque sistemático: Es el primer método que aplica análisis de taint estático y dinámico específicamente para APIs de gráficos centrado en el control de acceso roto.
Formalización Nativa de Grafos: Utiliza la teoría de transformación de grafos (DPO - Double Pushout) para modelar las APIs, lo que permite una representación precisa de la estructura de datos y sus manipulaciones.
Análisis de Vulnerabilidades Indirectas: Extiende el análisis más allá de las dependencias directas, proporcionando condiciones teóricas (Teorema 3.13) bajo las cuales el análisis estático puede detectar vulnerabilidades indirectas mediante la reducción a casos directos.
Cobertura de Roles: Introduce un nuevo criterio de cobertura ("Role Coverage") para asegurar que las pruebas dinámicas validen explícitamente las jerarquías de roles en la política de acceso.
Validación en Caso Real: Aplicación exitosa a una parte de la API de GitHub (GraphQL), incluyendo la reproducción de un problema de seguridad real reportado en la comunidad (issue #106598) relacionado con scopes de tokens y autenticación.

4. Resultados

Aplicación al Ejemplo de Ejecución: El análisis identificó correctamente dependencias entre reglas como createRepo y updateRepo. La revisión manual clasificó la mayoría como seguras (documentadas), pero destacó un par (createProject, deleteProject) como inseguro por falta de documentación, lo cual fue confirmado dinámicamente.
Reproducción de Vulnerabilidad Real: El método se aplicó al issue #106598 de GitHub. El análisis estático identificó el flujo de datos sensible (creación de un Ref y comparación de commits). El análisis dinámico, ejecutando pruebas con diferentes tokens (OAuth vs. Fine-grained), confirmó que un usuario podía realizar una comparación sensible sin el scope repo cuando usaba un token de tipo "fine-grained", reproduciendo la vulnerabilidad reportada.
Herramientas: Se utilizó el proyecto Henshin para el análisis estático (CPA) y scripts en Python (con Pytest y cliente GraphQL) para la ejecución dinámica.

5. Significado

Este trabajo es significativo porque cierra la brecha entre la teoría formal de grafos y la seguridad práctica de las APIs modernas.

Para la Industria: Proporciona una metodología robusta para auditar APIs complejas como GraphQL, donde la estructura de datos es dinámica y las vulnerabilidades de acceso son difíciles de rastrear con herramientas tradicionales.
Para la Investigación: Establece un marco formal para el análisis de seguridad en sistemas basados en grafos, demostrando que el análisis de dependencias críticas (CPA) puede adaptarse eficazmente para la detección de vulnerabilidades de control de acceso.
Automatización Futura: Aunque la revisión de políticas y la generación de reglas aún requieren intervención humana, el trabajo sienta las bases para la automatización completa de la traducción de esquemas GraphQL a sistemas de transformación de grafos manchados, como se ilustra en la visión de automatización del artículo.

En resumen, el artículo demuestra que el análisis de taint, combinado con la transformación de grafos, es una técnica poderosa y precisa para detectar y validar vulnerabilidades de control de acceso en APIs de gráficos, ofreciendo tanto garantías teóricas (sonido) como validación práctica (dinámica).