En el desarrollo de software y sus procesos DevOps -desde el diseño hasta el despliegue- la seguridad debe estar en primer plano. Si se deja para después, los incidentes de seguridad se volverán en su contra.
En este post, vamos a abordar un descuido común pero crítico cometido por los desarrolladores de APIs GraphQL-la habilitación de las características de introspección en entornos de producción. La introspección es una característica increíble para entender y probar las capacidades de tu API cuando estás en la etapa de desarrollo. Pero si no la desactivas antes de ponerla en producción, abres tu aplicación a vulnerabilidades significativas. Vamos a discutir cómo esto puede escalar en un riesgo de seguridad importante, junto con las medidas preventivas que puede tomar para reforzar la seguridad en su tubería DevOps.
El escenario
Imagine un equipo de desarrollo que lidera la implementación de la API GraphQL de su organización. GraphQL es un potente lenguaje de consulta diseñado para permitir a los clientes solicitar exactamente lo que necesitan en una sola consulta. A diferencia de las API REST tradicionales, que pueden requerir varias solicitudes para reunir datos y relaciones complejas. La estructura de los datos en GraphQL se define en un esquema, que describe los tipos de datos, las consultas y las mutaciones disponibles.
El equipo de desarrollo ha realizado un gran esfuerzo y ha creado algo impresionante. Esta API no sólo es robusta, sino también escalable, capaz de gestionar millones de transacciones por minuto, todo gracias a las capacidades de autoescalado que el equipo ha diseñado y construido. Con su enfoque en el rendimiento y la escalabilidad, se han asegurado de que esta API pueda manejar una carga enorme sin ningún contratiempo.
Sin embargo, en su prisa por desplegar e impresionar con esta nueva y brillante API GraphQL, pasaron por alto un pequeño detalle: la introspección sigue habilitada en el entorno de producción. La introspección es una potente herramienta para los desarrolladores, ya que les permite consultar qué recursos están disponibles en la API. Simplemente no es algo que debería estar abierto al acceso en producción.
¿Cuáles son las consecuencias?
Pues bien, a medida que la API se amplía para satisfacer la demanda, cada nueva instancia multiplica el riesgo potencial. Ahora, la importante vulnerabilidad de seguridad se ha extendido a un número cada vez mayor de nodos. Con eso, hemos preparado el escenario para la explotación potencial por parte de malos actores. Tienen todo lo que necesitan para descubrir información detallada sobre la estructura y la capacidad de esta nueva y brillante API.
Al olvidarse de un simple interruptor, el equipo ha convertido una función bienintencionada en un enorme fallo de seguridad.
Comprender la vulnerabilidad
Con la introspección activada, un desarrollador puede consultar la API GraphQL para ver el esquema completo, con todos sus tipos de datos, campos, consultas y mutaciones. Esto es como tener un mapa detallado de todos los puntos finales operativos y estructuras de datos para una API. Es un gran recurso en manos de un desarrollador. Pero no es algo que quieras poner en manos de un ciberatacante.
Considere cómo un atacante podría explotar las capacidades de introspección para aprender sobre su API GraphQL. En primer lugar, pueden definir Fragments para que los resultados de sus consultas sean más fáciles de leer.
fragment FullType on __Type { |
A continuación, pueden enviar una consulta para introspeccionar el __schema que está disponible en el tipo raíz de una consulta. La consulta GraphQL podría tener este aspecto:
{ |
Al enviar esa consulta, junto con las definiciones de fragmentos, a una API GraphQL con la introspección activada, un atacante recibirá una respuesta con un objeto JSON completo con todos los detalles de su API. Luego, pueden utilizar una herramienta como GraphQL Voyager para mostrar la API GraphQL como un gráfico interactivo.
He aquí un ejemplo de visualización de una API GraphQL basada en la respuesta a la consulta de introspección que mostramos anteriormente:
Como puede ver, esto revela gran parte de la estructura y los detalles relacionados con las operaciones de pago sensibles. Se trata de información extremadamente útil para un atacante que intente penetrar en su API. De nuevo: genial para los desarrolladores y, por desgracia, también genial para los atacantes.
Cuando dejas la introspección activada en producción, estos son los riesgos a los que te enfrentas:
- Exposición de la información: La información detallada del esquema puede proporcionar a los atacantes información sobre sus sistemas backend, modelos de datos y lógica empresarial. Al entregarles los planos de su castillo, les facilita la elaboración de ataques dirigidos.
- Facilitación de ataques: Armados con estos detalles sobre su API, los atacantes pueden crear consultas que exploten las vulnerabilidades. Esto puede provocar filtraciones de datos o interrupciones del servicio.
- Drenaje de recursos: Los atacantes también pueden utilizar este conocimiento para elaborar consultas maliciosas como ataques de denegación de servicio (DoS). Estos ataques consumen recursos y pueden provocar la caída total del sistema.
Pero no se desespere. Los pasos para mitigar este riesgo son simples y directos. Como primer paso para protegernos, veamos qué nos dice OWASP.
Guía de la hoja de trucos OWASP GraphQL
El OWASP GraphQL Cheat Sheet es un recurso valioso para asegurar sus APIs GraphQL. Proporciona orientación para ayudarle con las siguientes áreas:
- Validación de entradas
- Limitar o evitar las consultas costosas
- Garantizar controles de acceso adecuados
- Desactivación de configuraciones inseguras, como la introspección
La hoja de trucos tiene una sección dedicada a la Introspección y GraphiQL. GraphiQL es un IDE en el navegador para explorar GraphQL. Similar a las capacidades de introspección, GraphiQL puede exponer información detallada sobre el funcionamiento interno y el diseño de su API.
Si estás construyendo una API GraphQL, te recomendamos que te familiarices con la hoja de trucos de OWASP.
Cómo mitigar la vulnerabilidad de seguridad Introspection
Tomando como referencia la hoja de trucos de OWASP, seguiremos sus instrucciones para deshabilitar las consultas de introspección en entornos de producción o de acceso público. Esto es fundamental para evitar el acceso no autorizado a información detallada del esquema que podría ser explotada por los atacantes.
¿Cómo lo hacemos?
Aquí tienes un sencillo fragmento de código en JavaScript que demuestra cómo desactivar la introspección en producción si utilizas Apollo Server:
const { ApolloServer } = require('apollo-server'); |
Sí, eso es básicamente todo lo que hay que hacer. Este sencillo paso (configurar introspection a false al configurar una nueva instancia de ApolloServer) evitará que los usuarios accedan a información detallada del esquema a través de consultas de introspección. Esto reducirá el riesgo de que se filtre información sensible.
Cómo integrarlo en su proceso DevOps seguro
Si el paso es tan sencillo, ¿por qué lo olvidan tan a menudo los desarrolladores? Porque están centrados en otras cosas y ocupados intentando cumplir plazos críticos. No es de extrañar que ajustes de configuración aparentemente menores se pasen por alto de vez en cuando.
Por eso existen las pruebas automatizadas y la canalización DevOps, para evitar los errores humanos y los olvidos.
¿Cómo podría integrar esta medida de seguridad en su proceso DevOps? He aquí dos sugerencias:
- Escribe una prueba de pre-despliegue que compruebe explícitamente la configuración de tu servidor GraphQL para asegurar que la introspección está desactivada en el despliegue de producción.
- Escriba una prueba posterior al despliegue que intente realizar una consulta de introspección en el entorno de producción. Cuando su intento se encuentra con una respuesta de error (como
Cannot query field '__schema' on type 'Query'), la prueba debería pasar.
Aproveche las herramientas de canalización CI/CD como Jenkins, GitHub Actions o CircleCI para ejecutar secuencias de comandos que comprueben la configuración de su API GraphQL como parte del proceso CI/CD.
Conclusión
Construir APIs GraphQL puede ser una gran forma de innovar para tu empresa, pero requiere que seas proactivo en tus prácticas de seguridad. Un pequeño descuido podría exponer tu API a enormes vulnerabilidades. En este post, hemos cubierto un buen ejemplo de esto: desactivar la introspección para despliegues de producción, para que los atacantes no tengan acceso a información detallada sobre tu esquema GraphQL.
Para obtener más orientación y recursos, consulte la completa biblioteca de guías de Linoderelacionadas con la seguridad, el desarrollo de GraphQL y https://www.linode.com/docs/guides/platform/.
Comentarios (1)
Integrating security into your DevOps pipeline is essential for identifying vulnerabilities early and ensuring robust protection throughout the development cycle. Emphasizing automated security checks and continuous monitoring helps mitigate risks and enhances overall system resilience.