Header Ads Widget

Ticker

6/recent/ticker-posts

Puntos de seguridad a considerar antes de implementar GraphQL


 GraphQL es un lenguaje de consulta muy poderoso que hace muchas cosas bien. Cuando se implementa correctamente, GraphQL ofrece una metodología extremadamente elegante para la recuperación de datos , más estabilidad de backend y una mayor eficiencia de consultas .

Sin embargo, la clave aquí es esa simple frase, cuando se implementa correctamente . GraphQL ha tenido una especie de adopción de la fiebre del oro, con desarrolladores más pequeños respondiendo a la exageración de los medios y los primeros usuarios de renombre con sus propias implementaciones. El problema es que muchas personas no están considerando lo que realmente significa la adopción de GraphQL para su sistema y las implicaciones de seguridad que conlleva esta adopción.

GraphQL es un cambio de paradigma en muchos sentidos, y con eso, las preocupaciones de seguridad han cambiado. Si bien algunas preocupaciones de seguridad han desaparecido, reemplazadas por diferencias y matices arquitectónicos, otras preocupaciones se han ampliado .

En este artículo, hablaremos sobre esos problemas, destacando las preocupaciones de seguridad que un sistema API que admita GraphQL debería reconocer. Si bien GraphQL en sí no es el principal impulsor de todas estas preocupaciones, estos problemas deben abordarse dentro del marco más amplio de un sistema GraphQL.

GraphQL: un resumen

Rápidamente, resumamos qué es GraphQL y cómo hace lo que hace. En pocas palabras, GraphQL es un lenguaje de consulta de capa de aplicación diseñado para interpretar una cadena de un servidor o cliente y devolver esos datos al cliente solicitante en la forma que solicite.

GraphQL fue desarrollado por Facebook como un medio para pasar de las aplicaciones HTML5 en dispositivos móviles a aplicaciones nativas sólidas. Esto se facilitó al permitir consultas de backend más sencillas a través de la unificación de múltiples extremos interiores en un único extremo orientado hacia adelante .

Con eso en mente, ¿cuáles son algunas de las preocupaciones con respecto a la seguridad y las mejores prácticas en términos de GraphQL?

Para obtener una introducción a GraphQL, lea: 5 beneficios potenciales de integrar GraphQL

Documentación implícita frente a documentación real

Una preocupación seria al implementar GraphQL es cómo se maneja la documentación entre versiones. GraphQL no tiene soporte de versiones de la misma manera que lo hacen otros sistemas. Eso no quiere decir que no pueda realizar una versión en GraphQL, sino simplemente que, por diseño, GraphQL está diseñado para la evolución de API sin que se requiera control de versiones.

Si bien este es ciertamente un enfoque justo, hay un buen número de desarrolladores que dependen del control de versiones para comunicar los cambios en los valores de campo, puntos finales y declaraciones. Si bien esta no es una buena práctica, eso no impide que sea relativamente común y, desafortunadamente, cuando GraphQL se incorpora a la mezcla, el problema solo empeora.

Digamos que una API cambia un punto final fundamental o una construcción interna. En una API tradicional, este cambio se documentaría como un cambio de versión , con documentación incorporada como tal. En las implementaciones de GraphQL, este no es el caso, y muchos desarrolladores pueden aprender acerca de este punto final obsoleto al intentar usarlo y ser rechazados.

Entonces, ¿cuál es el problema de seguridad aquí? El problema es que, sin la documentación adecuada, puede encontrarse rápidamente con una situación en la que un punto final ya no es válido, pero aún se envían y solicitan datos desde ese punto final. Esto puede resultar en colisiones y funcionalidad no deseada. Más concretamente, si su aplicación todavía intenta sondear un punto final GraphQL inexistente, un punto final emulado de un ataque man-in-the-middle teóricamente podría entrar casi sin problemas en el flujo de datos.

Hay muchas formas de mitigar esto , y la adopción de una estrategia de control de versiones continua es absolutamente fundamental como solución. Aunque GraphQL amplía este problema drásticamente, esto es mucho más un problema con las prácticas de los desarrolladores que GraphQL en sí.

Fallos unificados

Quizás el mayor problema con una implementación GraphQL es inherente al enfoque en sí. GraphQL tiene la capacidad extremadamente poderosa de unificar múltiples puntos finales en un solo punto consultable; este es el quid de lo que hace que GraphQL sea poderoso. Sin embargo, el problema aquí es el hecho de que un solo punto final, incluso si se conecta a varios puntos finales internos, funciona como un solo punto para el consumidor.

A menudo consideramos que las API funcionan desde el interior hasta el borde , en otras palabras, desde la base del código hasta la experiencia del consumidor. Por lo general, esto está bien, ya que el consumidor es un solo punto que accede a múltiples puntos finales, que luego llaman a múltiples funciones, que podrían retransmitir incluso a más bases de datos o recursos. Sin embargo, cuando hablamos de GraphQL, en realidad estamos creando un sistema de interior a borde a interior , en el que el código base se reduce a un solo punto o una colección de puntos únicos, que luego se expande al usuario.

En una solicitud GraphQL mal definida del consumidor (o, para el caso, un punto final GraphQL mal formado definido por el desarrollador), una sola falla significa una falla total para acceder a los recursos internos. Si se extrae, documenta y especifica incorrectamente, básicamente está poniendo todos sus huevos en una canasta.

Hablando funcionalmente, todo este problema podría resumirse de la siguiente manera: las fallas en las llamadas equivalen a inseguridad para el consumidor desarrollador . Minimizar estas fallas es toda una industria en sí misma, y ​​una mala adopción de GraphQL niega gran parte de los esfuerzos que los desarrolladores han hecho con este fin.

Volúmenes de transacciones de datos y servidor

GraphQL tiene otro problema fundamental relacionado con sus aspectos fundamentales: las consultas suelen ser más grandes y más complejas que en las API REST tradicionales . En GraphQL, una sola solicitud puede combinar varias solicitudes a varios puntos finales, lo que da como resultado una cantidad impredecible de datos para cada solicitud a lo largo del tiempo.

Los consumidores tienen el control de sus solicitudes y, de alguna manera, esto es peligroso . No todos los proveedores van a tener una enorme infraestructura escalable o servidores en la nube en reserva y, por lo tanto, no todos los proveedores se sentirán cómodos con la idea de permitir solicitudes de contenido variable según el capricho de un usuario.

También existe la preocupación de limitar la solicitud real de una manera razonable. Los consumidores no siempre son los más juiciosos con sus solicitudes; a veces, un consumidor puede solicitar más datos de los que realmente necesita, y durante un tiempo prolongado y una gran cantidad de solicitudes, esto se suma a una sobrecarga significativa que no existía en una Solución GraphQL.

Relacionado: Los beneficios de un backend de API sin servidor

Ocultación de información y charla

Ni GraphQL ni REST imponen una cantidad significativa de ocultación de datos . El problema con GraphQL surge específicamente cuando las personas se apresuran a adoptarlo y, en lugar de pensar lógicamente en el mapeo de puntos finales públicos a modelos privados, simplemente mapean una relación 1: 1.

Si bien esto es funcional, es increíblemente peligroso. El objetivo de GraphQL es permitir opciones de personalización para solicitar datos, pero esto también significa que GraphQL permite el acceso a los datos de una manera que puede no ser la prevista, y cuando se establecen relaciones 1: 1, se pierde un control muy importante de los activos internos. .

Esto es, al igual que con cualquier API REST, completamente manejable con un diseño de esquema GraphQL adecuado . Los clientes y las API de terceros deberían poder interactuar con su punto final GraphQL sin conocer el funcionamiento interno de la API.

GraphQL se puede diseñar de manera que esto sea una limitación del punto final, pero esto viene con la amenaza de una adopción apresurada, lo que posiblemente resulte en exponer mucho más de lo que se pretendía. Dependiendo de cómo esté configurado GraphQL y cómo se manejen las consultas, los puntos finales reales definidos pueden insistir en la " charla ", en lugar de permitirla.

Esto tampoco es solo una cuestión de revelación de esquemas. Cuando un endpoint unifica múltiples endpoints y funcionalidades internas, este endpoint puede implementarse incorrectamente para recuperar muchos más datos de los que se pretendía. Esto tiene serias implicaciones.

Primero, está la implicación del servidor. Si los datos se recuperan primero y luego se eliminan los datos irrelevantes antes de transferirlos al cliente, estamos siendo un desperdicio extremo. Imagínese si cada vez que quiera conducir, tuviera que quemar un tanque completo de gasolina, independientemente de la distancia recorrida.

En algunos casos, esto tendría sentido: un viaje de trescientos kilómetros fácilmente devoraría su tanque y posiblemente más. Para un viaje corto, esto sería absolutamente un desperdicio y, con el tiempo, conduciría a un desgaste excesivo. Limitar esta charla es increíblemente importante .

Luego está el problema de exposición interna de seguridad antes mencionado. Esto ya se ha discutido un poco, pero vale la pena repetirlo: permitir el acceso ilimitado a una variedad de puntos finales de una manera manipulable es la tormenta perfecta para las pruebas de penetración y hace que la identificación de la estructura y el esquema del backend sea trivial en muchos casos.

Autorización y GraphQL

Otro punto de posible problema es la implementación incorrecta de la autorización en las API dependientes de GraphQL. Nuevamente, esto es mucho menos un problema con GraphQL en sí, y más un problema con la adopción.

En GraphQL, la autenticación se puede manejar mediante el contexto de consulta . La idea básica aquí es que la solicitud puede inyectarse con código arbitrario que luego se pasa a la solicitud, lo que permite un control muy fino y granular de la autorización por parte del desarrollador. Este es un sistema muy seguro, posiblemente mucho más fuerte que otras soluciones cuando se trata de inyección SQL y problemas de Langsec .

El problema viene con los desarrolladores que no comprenden realmente que esta es una posibilidad. Los desarrolladores pueden mirar su lógica de autorización actual, decidir que no quieren cambiar nada fundamentalmente y, en su lugar, insertar esta lógica en la capa GraphQL en sí en lugar de la capa de lógica empresarial.

Esto es fundamentalmente defectuoso y se desaconseja en la propia especificación GraphQL . Al colocar esta lógica en la capa GraphQL, el sistema de seguridad se abre a la inyección de código, el rastreo y otros ataques que podrían exponer fácilmente la estructura de autorización interna, volviéndola nula.

Optimismo medido

Esto no quiere decir que GraphQL sea una mala elección, o que deba tener cuidado de implementarlo. De hecho, todo lo contrario: la implementación adecuada de GraphQL es posiblemente una de las mejores cosas que se pueden hacer para una API grande cuando tiene una variedad de datos en el backend que deben entregarse de una manera sensata y controlada por el consumidor.

Sin embargo, lo que esto quiere decir es que nuestro optimismo debe moderarse. Al igual que con cualquier nueva tecnología o implementación, debemos demostrar que lo teórico se puede demostrar en la implementación real. Con tantos problemas potenciales que surgen de una implementación incorrecta, es increíblemente importante para los desarrolladores mirar GraphQL en el marco de "cómo me aseguro de hacer esto bien" en lugar de " moverse rápido y romper cosas ".

Tampoco estamos solos en este consejo de optimismo mesurado.

ThoughtWorks, una compañía de software que entrega veredictos a la industria sobre nuevas tecnologías, recomendó que los desarrolladores "evalúen" si GraphQL es o no la solución correcta dado su caso de uso. El API Evangelist Kin Lane también fue cauteloso, afirmando que durante una conversación en el canal API Evangelist Slack :

"El consenso parecía ser que GraphQL es una forma de evitar el arduo trabajo que implica conocer adecuadamente los recursos de la API, y solo está abriendo una ventana técnica al backend a menudo desordenado de nuestros mundos basados ​​en bases de datos".

El simple hecho es que, como con cualquier solución, debemos ser cautelosos y asegurarnos de lo siguiente:

R. Estamos usando GraphQL para un uso apropiado, y no lo estamos adoptando en el sabor de la mentalidad de la semana ;
B. Nuestros puntos finales están bien documentados , con rutas secundarias en caso de falla;
C. Estamos ocultando correctamente el esquema interno y la estructura de nuestro servidor;
D. Finalmente, estamos limitando la cantidad de interacciones permitidas a una medida razonable.

Si se validan estas situaciones, GraphQL ofrece una implementación increíble.

Publicar un comentario

0 Comentarios