Pruebas de APIs con IA: OpenAPI y GraphQL

Las apps modernas son un front end delgado sobre una API, y la API es a menudo donde están los bugs de verdad. La buena noticia para quien prueba es que las APIs tienden a describirse solas: las REST APIs entregan especificaciones OpenAPI, y las GraphQL APIs responden queries de introspection. Las dos te dan un mapa que el modelo puede leer. Este post sigue a probar bugs web comunes y lleva a armar un hackbot.

#Las APIs se rompen distinto

El OWASP API Security Top 10 pone la autorización arriba. Las dos para aprender primero son broken object level authorization, donde llegas al objeto de otro usuario, y broken function level authorization, donde llamas una acción de admin como usuario normal. Las dos son la versión API de los bugs de control de acceso del post anterior, y las dos son comunes porque la API tiene muchos endpoints y uno de ellos suele olvidar el chequeo.

#Encuentra la spec OpenAPI

Muchas APIs publican su propia especificación. Ubicaciones comunes son /openapi.json, /swagger.json, /v1/openapi.json, o una página de docs que carga una. Tráela y tienes cada path, método, parámetro y schema en un archivo.

curl -s https://api.example.com/openapi.json -o openapi.json

Dale la spec al modelo y pídele que liste los endpoints, marque los que leen o escriben objetos de usuario y señale los que por su nombre sugieren un rol de admin o interno. Esa pasada de lectura vuelve un documento OpenAPI largo en una lista ordenada de qué probar primero.

#Introspection de GraphQL

Una GraphQL API suele responder una query de introspection que devuelve su schema entero: cada type, field, query y mutation. Cuando la introspection está activa, obtienes toda la superficie de ataque en un request.

curl -s https://api.example.com/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{ __schema { queryType { name } mutationType { name } types { name kind } } }"}'

Entrégale el schema al modelo y pídele que agrupe las queries y mutations, saque las que tocan datos de otros usuarios y nombre los argumentos que cada una toma. La especificación de GraphQL describe la introspection, y la OWASP Web Security Testing Guide tiene una sección sobre probar GraphQL.

#Deja que el modelo planee, y luego prueba a mano

Desde cualquiera de los dos mapas, pide al modelo un plan de prueba corto: por cada endpoint con dueño de objeto, qué dos cuentas usar y qué id cambiar; por cada operación privilegiada, desde qué sesión de bajo privilegio probarla. El modelo es bueno en volver un schema en este checklist. No puede decirte si el chequeo falta de verdad, así que corres cada caso por tu proxy con las cuentas que controlas y lees el resultado. Una mutation que deja a un usuario normal cambiar el registro de otro usuario es un BOLA limpio, probado con dos sesiones.

#Confirma y guarda evidencia

Los findings de API son fáciles de probar y fáciles de exagerar. Pruébalos con cuentas que controlas, una variable a la vez, y guarda el request y la response completos de cada uno. Para un BOLA, la evidencia son dos requests: tu propio objeto, luego el objeto de la otra cuenta devuelto a tu sesión. Para un BFLA, es la llamada privilegiada funcionando desde una sesión que no debería poder hacerla. Mantén al mínimo los datos internos a los que llegas para mostrar impacto, y describe solo lo que demostraste.

#Una nota sobre automatización y rate

Las APIs hacen tentador scriptear cientos de requests. Chequea primero las reglas del programa sobre automatización y rate, mantén bajo el volumen sobre el objetivo vivo y haz la iteración pesada contra una copia local. Una API que martillas es una API cuyo dueño nota por la razón equivocada.

#Lo siguiente en esta serie

Ya corriste el loop entero a mano. Los próximos tres posts arman un pequeño agente que corre los pasos de recon y de prueba por ti, bajo tu aprobación. Empieza con la arquitectura del hackbot.