GraphQL, introspección, profundidad y alias

La introspección es una función estándar de GraphQL: el cliente puede preguntar al propio servidor qué tipos, campos y argumentos tiene. Es útil para el desarrollo y las herramientas, y a la vez entrega a quien la use el mapa completo, incluidas operaciones que ninguna pantalla muestra. La documentación oficial de GraphQL recomienda desactivarla en producción para las APIs que solo usan las propias aplicaciones del equipo, porque las operaciones ya están fijadas en esas aplicaciones y reduce la superficie.

Para el pentester, la introspección es una fuente de lectura: se pide una vez dentro del alcance, se guarda la salida y se trabaja con ella. No es un fallo por sí sola, pero un esquema legible más una autorización floja multiplica el efecto de cualquier descuido.

En GraphQL no hay rutas distintas que proteger: cada campo de consulta y cada mutación debe comprobar quién llama. El fallo clásico de BFLA se ve aquí como una mutación de un rol que acepta a otro. La tabla matriz_de_roles dice quién debe poder invocar cada operación y registro_de_operaciones dice quién la invocó y qué respondió el servidor.

Cruza ambas y encuentra la operación reservada a un rol que respondió 200 a una cuenta de otro rol.

El esquema de Tamarindo tiene una referencia circular: un cliente tiene envíos y cada envío tiene un cliente. Sin límite, una consulta puede encadenar esa relación tantas veces como quiera, y el trabajo del servidor crece con cada nivel. Por eso la guía de seguridad de GraphQL recomienda un límite de profundidad de consulta aplicado antes de ejecutar, y uno más estricto para el anidamiento de listas.

En registro_de_operaciones la columna profundidad dice cuántos niveles de anidamiento declaró cada operación, y duracion_ms cuánto tardó. Localiza la que más niveles anidó.

Un alias permite pedir el mismo campo varias veces en una sola operación con nombres distintos. Es legítimo para una pantalla, pero se puede usar para que una única petición equivalga a muchas: un límite de tasa que cuenta peticiones HTTP no ve la diferencia. Por eso se limita también el número de alias por operación y se calcula el coste de cada consulta, no solo su número.

Mira controles_del_servidor y registro_de_operaciones. El límite es de peticiones por minuto por cuenta, y la operación con más alias del registro pidió un número de alias en una sola petición. Calcula cuántas búsquedas cabrían en un minuto con ese límite si cada petición llevara tantos alias.

El informe termina en recomendaciones que se puedan ejecutar. Para GraphQL, las que recoge la guía oficial son: comprobar autorización en cada operación y en la capa de negocio, limitar profundidad, limitar alias, limitar lotes, calcular un coste de consulta con un presupuesto por cliente, paginar las listas con un máximo, y desactivar la introspección cuando no hace falta. Ninguna depende de ocultar el esquema: sin comprobación de roles, el secreto del esquema no protege.