Catégories
Start-up et applications

Cinq vulnérabilités majeures dans GraphQL

GraphQL (GQL) est un langage de requête de données couramment utilisé dans les applications Web et mobiles modernes comme élément clé de la pile technologique. GQL simplifie la récupération des données d'un serveur vers un client via un appel API. Cet article récapitule quelques réflexions d'un article de carvesystems.com, couvrant les cinq vulnérabilités GraphQL les plus courantes, comment utiliser une «chèvre» GQL pour illustrer les vulnérabilités et certains outils pour évaluer la mise en œuvre de GQL.

Comprendre un peu plus ce qu'est GQL aidera à clarifier les concepts de cet article. Le contributeur de CarveSystems, Aiden, élabore:

"GraphQL est un langage standardisé pour décrire et faire des requêtes aux API. Initialement construit par Facebook en 2015 pour une utilisation dans leurs applications mobiles, GraphQL offre un certain nombre d'avantages aux développeurs d'applications par rapport à une API REST traditionnelle":

  • "Les applications clientes ne peuvent demander que les informations dont elles ont besoin, ce qui minimise la quantité de données envoyées."
  • "GraphQL permet de représenter des requêtes plus compliquées, ce qui réduit le nombre de demandes d'API qui doivent être effectuées."
  • "Toutes les données d'entrée sont vérifiées par rapport à un schéma défini par le développeur, aidant à la validation des données."
  • Les avantages accompagnant GQL s'accompagnent d'un niveau de complexité et de vulnérabilités de sécurité associés.

Explorez une API de démonstration

Pour illustrer ces vulnérabilités, Carve a construit un exemple d'API avec les problèmes intégrés à titre d'exemple, en utilisant un service de notes minimal (cela permet aux clients de l'API de créer leurs propres notes publiques et privées, ainsi que de voir les publications publiques d'autres utilisateurs ). Vous pouvez trouver le code source de l'exemple d'API ici. Vous pouvez exécuter votre propre instance localement avec Node ou avec un conteneur Docker (disponible sur carvesystems / vulnérable-graphql-api sur Docker Hub. "L'application de démonstration expose un serveur Web avec une instance de l'IDE GraphiQL pour l'expérimentation, qui est disponible sur le port 3000. "

Vulnérabilité 1: contrôles d'autorisation incohérents

Le problème le plus fréquemment rencontré dans les applications basées sur GraphQL est une logique d'autorisation défectueuse. Carve précise: «Bien que GraphQL aide à implémenter une validation des données appropriée, les développeurs d'API sont laissés à eux-mêmes pour implémenter des méthodes d'authentification et d'autorisation par-dessus. Pire encore, les «couches» de résolveurs typiques d'une API GraphQL rendent cela plus compliqué – les contrôles d'autorisation doivent être présents non seulement au niveau des résolveurs au niveau de la requête, mais aussi pour les résolveurs qui chargent des données supplémentaires (par exemple, pour charger tous des messages pour un utilisateur donné). "

Les failles de l'API GQL se présentent généralement sous deux formes. Carve explique: «Le premier, et le plus courant, se produit lorsque la fonctionnalité d'autorisation est gérée directement par les résolveurs au niveau de la couche API GraphQL. Lorsque cela est fait, les vérifications d'autorisation doivent être effectuées séparément dans chaque emplacement, et tout cas où cela est oublié pourrait conduire à une faille d'autorisation exploitable. La probabilité que cela se produise augmente à mesure que la complexité du schéma d'API augmente, et il existe des résolveurs plus distincts chargés de contrôler l'accès aux mêmes données. »

L'API de démonstration créée par Carve décrit plusieurs méthodes de récupération de la liste des objets Post: un client peut récupérer une liste d'utilisateurs, puis récupérer tous leurs messages publics, ou simplement récupérer un message par son ID numérique. Une vulnérabilité exposée dans l'API de démonstration offre la possibilité de récupérer une publication par ID, où il n'y a pas de vérification d'autorisation. Les vulnérabilités dans cette veine sont simples et se retrouvent généralement dans les déploiements GQL réels.

Les guides de conception de GraphQL conseillent sur la façon d'effectuer une autorisation en toute sécurité: la logique doit être appliquée par la couche de logique métier, ce qui ouvre la voie à des contraintes d'autorisation appliquées de manière cohérente.

Vulnérabilité 2: couches proxy REST fragiles

Une API sous-jacente adaptée pour être utilisée par les clients GraphQL avec des proxys REST peut être «implémentée dans la couche proxy GraphQL en faisant une demande à GET / api / users / 1 sur l'API backend. S'il est implémenté de manière non sécurisée, un attaquant peut être en mesure de modifier le chemin ou les paramètres transmis à l'API backend, présentant une forme limitée de falsification de requête côté serveur. »

Le bon codage des URL et les paramètres de validation transmis à un autre service peuvent protéger contre ce type de vulnérabilité. Tirer parti du schéma GraphQL pour exiger un numéro pour le nom de fichier serait un moyen de résoudre cette vulnérabilité. Une tactique alternative consisterait à implémenter la validation des valeurs d'entrée. «GraphQL va valider les types pour vous, mais vous laisse la validation du format. Un type scalaire personnalisé (par exemple, un scalaire AssetId) pourrait être utilisé pour appliquer de manière cohérente toutes les règles de validation personnalisées qui s'appliquent à un type couramment utilisé. »

Vulnérabilité 3: Ignorer la validation Skalar personnalisée

Les données brutes avec GQL sont représentées avec un type Skalar et sont finalement transmises en tant que données d'entrée ou retournées en sortie. Carve le décompose, expliquant qu'il existe cinq types scalaires intégrés – Int, Float, Boolean, String et ID (qui n'est en réalité qu'une chaîne). Cet ensemble de base de types scalaires est suffisant pour de nombreuses API simples, mais pour les scénarios où des types de données bruts supplémentaires sont utiles, GraphQL prend en charge les développeurs d'applications pour définir leurs propres types scalaires. Par exemple, une API peut inclure son propre type scalaire DateTime ou un type scalaire étendu qui fournit une validation d'entrée étendue, comme des «entiers impairs» ou des «chaînes alphanumériques».

Si un développeur implémente son propre type Skalar, il sera alors responsable de suivre la désinfection et la validation de type. Une démo extraite de la bibliothèque graphql-type-json est disponible ici.

Vulnérabilité 4: limitation de débit désorganisée

L'implémentation de protections de limitation de débit et d'autres dénis de service reflète les API GraphQL dans leur complexité et leur difficulté. Le nombre d'actions effectuées par la requête GQL est par nature modifiable et prend donc une quantité irrégulière de ressources serveur. C'est pourquoi les techniques de limitation de débit utilisées pour les API REST ne sont pas destinées à être utilisées pour les API GQL – les stratégies d'API REST sont insuffisantes pour les API GQL.

Vulnérabilité 5: la fonction d'introspection démasque les données publiques

Tacking sur les fonctionnalités voilées aux points de terminaison API est une perspective attrayante pour les développeurs qui veulent un peu de fonctionnalités cachées du public. Ces fonctionnalités peuvent être protégées de la vue du public avec une protection d'accès administrateur ou avec un autre point de terminaison API. Carve indique qu '«une fonctionnalité GraphQL appelée introspection facilite la découverte de points de terminaison cachés. Dans le cadre d'un effort pour être convivial pour les développeurs, la fonction d'introspection, qui est activée par défaut dans la plupart des implémentations GraphQL, permet aux clients API d'interroger dynamiquement des informations sur le schéma, y ​​compris la documentation et les types de chaque requête et mutation définis dans le schéma . Il est utilisé par des outils de développement, comme l'IDE GraphiQL, pour récupérer dynamiquement le schéma s'il n'est pas fourni. » L'API de démonstration développée par Carve éclaire davantage ces idées avec une mutation cachée.

Dernières pensées

L'utilisation d'une solution plus complexe comme GraphQL entraîne des problèmes plus complexes. Dans cet esprit, il résout bon nombre des problèmes fondamentaux de validation des données que l'on trouve couramment dans les API REST. Ces points communs sont disponibles pour l'exploration avec l'API de démonstration Carve.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *