Bonjour, Habr! Je vous présente la traduction de l'article Protéger votre API GraphQL des vulnérabilités de sécurité .

GraphQL devient rapidement le choix des développeurs qui ont besoin de créer une API pour leur application client. Mais, comme toutes les nouvelles technologies, GraphQL est soumis à certains risques de sécurité inhérents. Que vous construisiez un projet tiers ou une application d'entreprise à grande échelle, vous devez vous assurer de vous protéger contre ces menaces.

Bien que les menaces répertoriées dans cet article soient spécifiques à GraphQL, votre implémentation introduira un nouvel ensemble de menaces qui devront être traitées. Il est également important que vous compreniez les menaces auxquelles sont exposées les applications en cours d'exécution sur le réseau.

Menace: grandes requêtes profondément imbriquées et coûteuses à calculer

Solution : limitation de la profondeur d'imbrication

La puissance fournie par GraphQL est associée à de nouvelles menaces de sécurité. Les plus courantes sont les requêtes profondément imbriquées, qui conduisent à des calculs coûteux et à un énorme JSON, qui peuvent nuire au réseau et à sa bande passante.

La bonne façon de protéger votre API contre ce type d'attaque est de limiter la profondeur des demandes afin que les demandes profondes malveillantes soient bloquées jusqu'à ce que le résultat soit calculé.

GraphQL Depth Limit fournit une interface simple pour limiter la profondeur des requêtes.

import depthLimit from 'graphql-depth-limit' import express from 'express' import graphqlHTTP from 'express-graphql' import schema from './schema' const app = express() app.use('/graphql', graphqlHTTP((req, res) => ({ schema, validationRules: [ depthLimit(10) ] }))) 

Menace: demandes de mutation vulnérables à la force brute

Solution : limiter le nombre de demandes

La recherche de connexions et de mots de passe est la plus ancienne astuce de l'histoire du piratage. Au cours de la dernière décennie, il y a eu tellement de fuites de données sur Internet qu'une base de données de 772 904 991 e-mails uniques et 21 222 975 mots de passe uniques a récemment été trouvée. Pour vérifier si des informations sur votre e-mail et votre mot de passe avaient été divulguées, Troy Hunt a même créé un site Web Have I been Pwned , pour lequel, entre autres, il a utilisé cette base de données.

Heureusement, vous avez un moyen facile de rendre le contournement vraiment difficile et coûteux pour les attaquants, ce qui fera de vous une cible moins attrayante pour eux.

Le plugin GraphQL Rate Limit vous permet de spécifier des restrictions pour vos requêtes de trois manières différentes: en utilisant des directives graphql-shield personnalisées ou en utilisant la fonction pour limiter le nombre de base de requêtes.

Ce plugin vous permettra de définir une fenêtre de temps et une limite sur le nombre de demandes pour cela. La définition d'une grande fenêtre temporelle pour les demandes très vulnérables, telles que la connexion, et de petites fenêtres temporelles pour les demandes moins vulnérables vous aidera à maintenir une expérience agréable pour les utilisateurs ordinaires et deviendra un cauchemar pour les attaquants.

Créez une directive pour limiter le nombre de demandes:

Ici, vous aurez besoin d'un identifiant unique pour chaque demande. Vous pouvez utiliser l'adresse IP de l'utilisateur ou un autre identifiant, unique pour chaque utilisateur et correspondant à chaque demande.

 const rateLimitDirective = createRateLimitDirective({ identifyContext: (context) => { return context.id }, }) 

Ajoutez une directive à votre schéma:

 import { createRateLimitDirective } from 'graphql-rate-limit' export const schema = { typeDefs, resolvers, schemaDirectives: { rateLimit: rateLimitDirective, }, } export default schema 

Enfin, ajoutez une directive à votre requête vulnérable:

 #        60  Login(input: LoginInput!): User @rateLimit( window: "60s" max: 10 message: "You are doing that too often. Please wait 60 seconds before trying again." ) 

Menace: permettre à l'utilisateur d'influencer les données spécifiques à l'utilisateur

Solution : prenez ces données d'une session utilisateur lorsque cela est possible

Il est facile de supposer que si vous souhaitez autoriser l'utilisateur à mettre à jour une ressource, cela vaut la peine de laisser l'utilisateur décider de la ressource qu'il souhaite mettre à jour. Mais que se passe-t-il si un utilisateur obtient un identifiant de ressource auquel il ne devrait vraiment pas avoir accès?

Supposons que nous ayons une demande de mutation updateUser qui permet à l'utilisateur de mettre à jour son profil.

 mutation UpdateUser($input: {"id": "test123" , "email": "test@example.com"}) { UpdateUser(input: $input) { id firstName lastName } } 

S'il n'y a pas de protection côté serveur, l'attaquant, disposant d'une liste d'identifiants, pourrait potentiellement mettre à jour l'adresse e-mail de tout utilisateur. La solution évidente ici consiste à ajouter une vérification pour vous assurer que l'ID de l'utilisateur actuel correspond à l'ID dans les champs de saisie.

Ne faites pas ceci:

 function updateUser({ id, email }) { return User.findOneAndUpdate({ _id: id }, { email }) .catch(error => { throw error; }); } 

Une manière moins évidente mais correcte de résoudre ce problème consiste à empêcher l'identifiant d'être utilisé comme entrée et à utiliser l'identifiant utilisateur de l'objet contextuel.

Faites ceci:

 function updateUser({ email }, context) { return User.findOneAndUpdate({ _id: context.user._id }, { email }) .catch(error => { throw error; }); } 

C'est peut-être un exemple assez banal, mais effectuer de telles actions pour chacun des objets avec lesquels l'utilisateur interagit directement peut vous protéger contre de nombreuses erreurs risquées.

Exécution simultanée de plusieurs requêtes coûteuses

Solution : limite de coût des requêtes

En attribuant un prix à chaque demande et en indiquant le prix maximum par demande, nous pouvons nous protéger contre les intrus qui pourraient essayer de répondre à trop de demandes coûteuses en même temps.

Le plugin GraphQL Cost Analysis est un moyen facile de spécifier le coût des requêtes et la limite de coût maximum.

Déterminez le coût maximum:

 app.use( '/graphql', graphqlExpress(req => { return { schema, rootValue: null, validationRules: [ costAnalysis({ variables: req.body.variables, maximumCost: 1000, }), ], } }) ) 

Déterminez le coût de chaque demande:

 Query: { Article: { multipliers: ['limit'], useMultipliers: true, complexity: 3, }, } 

Menace: divulgation des détails d'implémentation de GraphQL

Solution : désactiver l'introspection dans le code "combat"

GraphQL est un outil de développement extrêmement utile. Il est si puissant qu'il documente même votre schéma, vos demandes et vos abonnements pour vous. Ces informations peuvent être une mine d'or pour les attaquants qui souhaitent trouver des vulnérabilités dans votre application.

Le plugin GraphQL Display Introspection empêchera votre schéma de fuir vers le public. Importez simplement le plugin et appliquez-le à vos règles de validation.

 import express from 'express'; import bodyParser from 'body-parser'; import { graphqlExpress } from 'graphql-server-express'; + import NoIntrospection from 'graphql-disable-introspection'; const myGraphQLSchema = // ...    ! const PORT = 3000; var app = express(); app.use('/graphql', bodyParser.json(), graphqlExpress({ schema: myGraphQLSchema, validationRules: [NoIntrospection] })); app.listen(PORT);