Comment protéger les API GraphQL du langage de requête populaire contre les exploits

De nombreuses entreprises, dont GitHub, Credit Karma, Intuit et PayPal utilisent GraphQL, qui est un langage de requête pour les interfaces de programmation d’application (API) et un runtime pour répondre aux requêtes avec des données existantes.

Un récent rapport de Gartner a partagé que d’ici 2025, plus de 50 % des entreprises utiliseront GraphQL en production, contre moins de 10 % en 2021. Développé à l’origine par Facebook, GraphQL est utilisé pour créer des interfaces de programmation d’applications (API) comme alternative. aux plus connus REST et SOAP.

Le langage open source a gagné en popularité depuis sa création en 2012 en raison de ce que sa flexibilité native offre à ceux qui créent et appellent l’API. Les serveurs et les clients GraphQL fonctionnent ensemble afin que les clients spécifient les requêtes et que les serveurs valident les données avec les implémentations GraphQL fonctionnant dans différents langages.

Voyons donc les problèmes de sécurité des API liés aux API GraphQL et les meilleures pratiques pour protéger les API GraphQL, y compris les menaces couvertes dans le Top 10 de la sécurité des API Open Web Application Security Project OWASP.

GraphQL permet de faire plusieurs demandes de ressources en un seul appel de requête, ce qui permet d’économiser du temps et de la bande passante en réduisant le nombre d’allers-retours réseau vers le serveur. Cela permet également d’économiser les requêtes réseau en cascade, où le service informatique doit résoudre les ressources dépendantes des requêtes précédentes.

Cela simplifie l’extraction de grandes ressources de données dans un cadre permettant des pages comme Facebook qui ont votre profil, les données de vos amis, des publicités en ligne et des cartes.

Des problèmes de sécurité potentiels peuvent survenir, car les API GraphQL peuvent être codées de manière incorrecte, ce qui entraîne une compromission des données, des problèmes de contrôle d’accès et d’autres vulnérabilités à haut risque. En abordant certains éléments de la feuille de triche GraphQL publiée par l’Open Web Application Security Project (OWASP), nous pouvons voir ce qui est nécessaire au minimum pour sécuriser les API GraphQL.

L’injection peut inclure l’injection de commande du système d’exploitation, l’injection de style SQL et les injections de type d’inclusion de fichier. Cela signifie que la validation des entrées est extrêmement importante. Faire confiance aux données fournies par le client, sans validation d’un certain type, peut entraîner l’un de ces styles d’injection.

Le plus gros point à retenir de la feuille de triche OWASP GraphQL est de n’autoriser que certaines entrées via une liste blanche tout en rejetant gracieusement les entrées médiocres sans détails excessifs.

Presque toutes les attaques par déni de service sont basées sur la consommation de ressources. Si le serveur est occupé à répondre à un milliard de requêtes par seconde, le serveur devient lent et plantera, ce qui entraînera une plus grande consommation de ressources sur les périphériques de sauvegarde ou d’équilibrage de charge.

Heureusement, il est possible d’arrêter les attaques par déni de service, y compris les attaques de récursivité ainsi que les attaques standard de consommation de ressources avec des limites de profondeur et de demande simples. De même, l’ajout de pagination signifie que le serveur n’occupe pas de mémoire avec d’énormes extractions de données, mais ne récupère qu’une page à la fois.

De nombreuses autres techniques telles que les délais d’attente sont simples à mettre en œuvre ainsi que le passage à un fournisseur frontal de réseau de diffusion de contenu (CDN).

La règle simple d’autorisation est de valider que l’utilisateur final est autorisé à afficher/modifier/créer/supprimer, tout ce qu’il touche, et ils doivent être validés à chaque demande. Cela empêche les attaques par références directes d’objets non sécurisées (IDOR) ainsi que les attaques par mutation.

Pour les attaques par lots, il est possible de déterminer quelques requêtes qui fonctionnent et de les jeter dans une grande requête pour que le serveur récupère les données par lots. Cela permettrait des choses comme l’extraction de données pour tous les enregistrements d’un certain type. Le traitement par lots permet une exfiltration massive de données à l’aide de l’API victime pour faire le gros du travail.

Ma principale suggestion est de s’assurer que l’introspection n’est pas activée et de s’assurer que le terrain de jeu GraphQL est désactivé ou, au minimum, non public. Lorsque vous testez des API ou que vous examinez simplement les demandes et les réponses des API, pensez à ce qui pourrait être fait pour exploiter l’API. Si un message d’erreur apparaît, lisez-le. Cela aide-t-il, avez-vous encore des erreurs excessives activées ?

En regardant la feuille de triche OWASP GraphQL et en comparant un environnement GraphQL aux suggestions qui s’y trouvent, vous conseillerez certainement quelques bonnes premières étapes. La prochaine étape dépend de la tolérance au risque et du parcours de sécurité de chacun.

La protection complète des API nécessite une approche axée sur la prévention qui combine une visibilité complète des API, une évaluation des risques d’exécution et une correction avec une prévention des attaques en ligne native. J’ai rassemblé les meilleures pratiques qui vous aideront à minimiser les événements de sécurité potentiels associés à vos API GraphQL :

Étape 1: Découverte d’API et suivi des stocks : nous ne pouvons pas protéger ce que nous ne pouvons pas voir. L’intégration avec n’importe quel élément de l’infrastructure de gestion des API à l’aide d’une collecte de données en ligne ou hors bande garantit que toutes les API, y compris les API GraphQL, sont trouvées, suivies, catégorisées et attribuées à un propriétaire respectif.

Étape 2: Évaluation des risques et correction des API : agir comme un contrôle de sécurité final, en utilisant des règles d’évaluation des risques prédéfinies ou personnalisées, permet de découvrir et de corriger les API avec une authentification faible, exposant des données sensibles, utilisant des messages d’erreur détaillés ou non conformes aux spécifications publiées.

Étape 3: Protection native en ligne contre les attaques et les exploits de vulnérabilité : même une API parfaitement codée peut être attaquée, ce qui renforce la nécessité d’analyser activement et de prévenir les attaques en temps réel, en utilisant des politiques prédéfinies et personnalisables avec des options de réponse qui incluent le journal, le blocage, la limite de débit, clôture géographique, injection d’en-tête ou tromperie configurée par application ou API.

Lorsqu’il s’agit de protéger les API GraphQL contre les attaques, une solution de protection des API doit inclure une protection complète et native contre toutes les menaces répertoriées dans le Top 10 de la sécurité des API OWASP.

Pièges à éviter

# Évitez les outils basés sur les signatures comme les WAF que les attaquants peuvent facilement contourner.

# Éloignez-vous des outils uniquement axés sur DevOps et manquez d’une approche équilibrée pour prévenir les menaces pendant la correction du code.

# Évitez d’utiliser la propre suite de tests d’un fournisseur pour valider cette fonctionnalité. Créez une batterie de tests basés sur vos API et les menaces qui peuvent les cibler.

# Évitez les outils de sécurité des API qui ne peuvent pas atténuer les menaces de manière native et s’appuyer uniquement sur des outils tiers tels que les WAF. De tels outils entraînent un délai entre la détection et la réponse et des faux positifs supérieurs à la moyenne, ce qui laisse les API vulnérables à la compromission.

Pour sélectionner une solution de protection unifiée des API (UAP), recherchez-en une qui traite toutes les phases du cycle de vie de la sécurité des API afin de protéger les API GraphQL des attaquants et d’éliminer les risques de sécurité inconnus et non atténués qui peuvent entraîner la perte de données, la fraude et l’interruption des activités.

Un UAP complet doit créer un inventaire d’exécution complet de toutes les API gérées et non gérées, connues et inconnues auparavant. Les risques d’API découverts doivent être signalés pour être corrigés tandis que les menaces sophistiquées sont détectées et atténuées en temps réel.

Le résultat sera une protection complète contre les menaces d’API qui causent la perte de données, le vol, la fraude et l’interruption des activités.

.

Leave a Comment

Your email address will not be published. Required fields are marked *