Les 10 principales menaces sur les applications Web

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Ce document décrit différentes approches que vous pouvez utiliser dans Apigee pour corriger les failles de sécurité identifiées par l'OWASP. Pour découvrir d'autres approches documentées pour Apigee, consultez la section Top 10 des options d'atténuation de l'OWASP de 2021 sur Google Cloud.

Présentation

Les écosystèmes d'API font l'objet de diverses attaques de la part de clients externes et internes. L'offre et l'utilisation d'API génèrent d'énormes opportunités pour les fournisseurs de services, mais elles présentent également des risques de sécurité. Les développeurs doivent être conscients de ces défis et les résoudre lorsqu'ils créent et utilisent des API.

OWASP est une communauté ouverte qui aide les organisations à développer, acheter et gérer des applications et des API fiables. Par le biais du projet OWASP sur la sécurité des API, l'OWASP publie les risques de sécurité les plus critiques pour les applications Web et les API REST, et fournit des recommandations pour y remédier.

Avec Apigee, la couche proxy d'API peut détecter, bloquer et signaler les requêtes API mal formées du client avant qu'elles ne soient traitées sur les systèmes backend, ce qui réduit les risques et protège vos services. Les requêtes mal formées peuvent inclure n'importe quel composant du protocole HTTP au niveau de l'application:

  • URL
  • En-têtes
  • Chemin
  • Charge utile

Les requêtes API mal formées peuvent provenir de clients connus ou inconnus développés par des développeurs externes, des développeurs internes ou des bots malveillants.  Ces types de requêtes représentent la majorité des menaces OWASP, mais d'autres composants de la couche proxy d'API sous-jacente peuvent atténuer les risques, tels que le masquage des données, la journalisation, l'administration, etc.

La plate-forme de gestion d'API intelligente d'Apigee vous permet de résoudre facilement les principales failles de sécurité des API OWASP, en adoptant une approche axée sur la consommation pour concevoir vos API et les connecter à vos systèmes backend. Vous trouverez ci-dessous une liste de règles/configurations recommandées par Apigee pour les principales menaces OWASP REST.

Solutions Apigee pour le Top 10 de l'OWASP 2017

De nombreux problèmes de sécurité se posent lors de la création et de la sécurisation d'applications Web. L'OWASP a publié sa liste des 10 principales menaces de sécurité OWASP pour 2017 pour les applications Web.  Bien qu'une application Web comporte de nombreuses parties, la plupart des applications Web modernes reposent fortement sur les API REST.  Apigee n'est pas conçu pour gérer tous les besoins de sécurité d'une application Web, mais il peut jouer un rôle essentiel dans la sécurisation des API REST. Vous trouverez ci-dessous les principales menaces de sécurité OWASP, ainsi que des descriptions de la façon dont vous pouvez utiliser Apigee pour les contrer.

A1:2017 – Injection

Pour vous protéger contre l'injection de données non approuvées telles que SQL, NoSQL, LDAP et JavaScript, qui peut entraîner l'exécution de commandes non intentionnelles ou un accès non autorisé aux données, Apigee fournit plusieurs stratégies de validation des entrées pour vérifier que les valeurs fournies par un client correspondent aux attentes avant d'autoriser le traitement ultérieur. Apigee Edge, agissant en tant que serveur pour les requêtes API entrantes, vérifie que la structure de la charge utile se situe dans une plage acceptable, également appelée vérification de limite. Vous pouvez configurer un proxy d'API pour que la routine de validation des entrées transforme l'entrée afin de supprimer les séquences de caractères à risque et de les remplacer par des valeurs sécurisées.

Il existe plusieurs approches pour valider les entrées avec la plate-forme Apigee :

Validez les types de contenu:

A2:2017 – Authentification et gestion des sessions défaillantes

Les pirates informatiques peuvent accéder aux mots de passe, aux jetons de session et aux clés pour usurper l'identité d'autres utilisateurs en profitant des failles d'implémentation des applications. Il s'agit plutôt d'un problème d'implémentation et non d'un problème de produit.  Apigee fournit des règles ValidApiKey, OAuth et des jetons Web JSON (JWT), qui contribuent à la protection contre cette faille.

Validation des clés API

La validation par clé API est la forme de sécurité la plus simple qui peut être configurée pour une API. Une application cliente présente simplement une clé API avec sa requête, puis Apigee Edge, via une stratégie associée à un proxy d'API, vérifie que la clé API est dans un état approuvé pour la ressource demandée.

Apigee prend en charge la génération et la validation des clés API. Apigee génère une clé API et un secret lorsqu'une application de développeur est créée et approuvée, et qu'elle est associée à un ou plusieurs produits d'API.

Le terme "clés API" peut parfois avoir plusieurs significations. Dans Apigee, lorsque la relation entre l'application et le produit est établie, Apigee génère un ID client et un secret client.  Certains désignent à la fois l'ID et le secret comme clé API. Certains ne désignent que l'ID client comme clé API. Dans l'interface utilisateur d'Edge, vous verrez "clé client" et "secret client".

Dans la règle VerifyAPIKey, seul l'ID client ou "clé client" est validé. Les développeurs reçoivent une clé client lorsqu'ils enregistrent leur application auprès d'Apigee et l'associent à un produit d'API. Les développeurs incluent la clé client dans les appels que l'application effectue aux proxys d'API inclus dans le produit d'API.

Apigee permet également d'importer des clés API existantes à partir de sources externes.

Pour les types d'autorisation OAuth, l'ID client et le code secret sont tous deux utilisés.

OAuth 2.0

Le framework d'autorisation OAuth 2.0 permet à une application tierce d'obtenir un accès limité à un service HTTP, soit au nom d'un propriétaire de ressources en orchestrant une interaction d'approbation entre le propriétaire de ressources et le service HTTP, soit en autorisant l'application tierce à obtenir l'accès en son nom.

Les règles OAuth 2.0 d'Apigee vous permettent d'implémenter et de personnaliser les quatre types d'autorisation OAuth 2.0. L'application des jetons d'accès OAuth peut être effectuée à l'aide de la règle OAuth V2. Le consommateur doit être enregistré et disposer d'une application approuvée qui lui a accordé l'accès à l'API. En retour, il recevra un ID client et un code secret client de l'API. Le client doit passer par l'une des autorisations OAuth pour être authentifié, ce qui lui accorde un jeton d'accès opaque. Ce jeton peut être utilisé pour contrôler l'accès à l'API.

JWT

Les jetons Web JSON, ou JWT, sont couramment utilisés pour partager des revendications ou des assertions entre des applications connectées. Apigee est compatible avec JWT au moyen de trois stratégies.

  • Jetons GenerateJWT (compatibles avec les signatures HS256 et RS256)
  • Valider les jetons ValidateJWT
  • Décoder les jetons DecodeJWT sans validation

A3:2017 – Exposition de données sensibles

Les pirates informatiques ciblent les données sensibles telles que les informations de carte de crédit, les numéros de sécurité sociale, les identifiants de connexion, les informations permettant d'identifier personnellement l'utilisateur et les numéros d'identification fiscale pour commettre des vols d'identité, des vols d'argent, des fraudes et d'autres crimes. Les applications Web doivent implémenter le chiffrement, à la fois au repos et en transit, ainsi que d'autres stratégies pour assurer la protection des données sensibles.

TLS (Transport Layer Security, dont SSL est le prédécesseur) est la technologie de sécurité standard permettant d'établir un lien chiffré entre un serveur Web et un client Web, tel qu'un navigateur ou une application. Apigee est compatible avec le protocole TLS à sens unique et bidirectionnel.

Le TLS nord-sud (client se connectant à l'API en tant que serveur) est pris en charge via une configuration d'hôte virtuel. Un hôte virtuel peut être configuré pour le protocole TLS unidirectionnel ou bidirectionnel.

Le protocole TLS vers le sud (Apigee en tant que client se connectant au service de backend) est compatible avec l'utilisation d'une configuration de serveur cible.  Un serveur cible peut être configuré pour TLS unidirectionnel ou bidirectionnel.

Apigee est compatible avec de nombreuses options de configuration TLS.

L'application du TLS bidirectionnel garantit que le client utilise un certificat déjà intégré à Apigee. L'OWASP fournit également des bonnes pratiques TLS.

Dans Apigee hybrid, TLS est disponible à l'entrée via un alias d'hôte, un concept semblable à celui d'un hôte virtuel.

Voici quelques consignes pour sécuriser les données sensibles:

  • Utilisez une plate-forme compatible avec les protocoles TLS unidirectionnel et bidirectionnel, qui assurera la protection au niveau du protocole.
  • Utilisez des stratégies telles que la règle AssignMessage et la règle JavaScript pour supprimer des données sensibles avant qu'elles ne soient renvoyées au client.
  • Utilisez les techniques OAuth standards et envisagez d'ajouter des techniques HMAC, de hachage, d'état, nonce, PKCE ou autres pour améliorer le niveau d'authentification de chaque requête.
  • Utilisez les paramètres de masquage des données pour masquer les données sensibles dans l'outil Edge Trace.
  • Veillez à ne pas stocker de données sensibles dans le cache (ou à chiffrer les données sensibles stockées dans le cache). Dans Edge, vous pouvez chiffrer les données sensibles au repos dans des mappages clé-valeur.

A4:2017 – Entités externes XML

Les systèmes ou applications qui traitent le format XML doivent gérer les "références d'entités externes" au format XML, c'est-à-dire les références à des fichiers ou des données qui sont remplacées par les données réelles lors du traitement XML. Si les applications ou les processeurs XML sont obsolètes ou mal implémentés, les pirates informatiques peuvent pirater les données et les utiliser pour voler des informations ou lancer divers types d'attaques sur le système, comme un déni de service.

La règle ExtractVariables d'Apigee vous permet d'extraire le contenu d'une requête ou d'une réponse et de l'attribuer à une variable. Vous pouvez extraire n'importe quelle partie du message, y compris les en-têtes, les chemins d'URI, les charges utiles JSON/XML, les paramètres de formulaire et les paramètres de requête. La règle fonctionne en appliquant un modèle textuel au contenu du message et, lorsqu'elle trouve une correspondance, définit une variable avec le contenu du message spécifié.

Apigee dispose d'un analyseur XML intégré à la plate-forme qui utilise XPath pour extraire les données. Il dispose également d'une règle XMLThreatProtection pour protéger contre les charges utiles XML malveillantes.

A5:2017 – Contrôle des accès défaillant

Une fois que les utilisateurs se sont connectés et ont accédé à un système, des contrôles d'autorisation appropriés doivent être en place pour qu'ils ne voient et ne fassent que ce qui leur est autorisé. Sans contrôle strict des accès, les pirates informatiques peuvent consulter des données non autorisées et souvent sensibles, ou manipuler de manière malveillante les données et le comportement du système.

Apigee est compatible avec une approche multicouche permettant de mettre en œuvre des contrôles d'accès afin d'empêcher les acteurs malintentionnés d'apporter des modifications non autorisées ou d'accéder au système.

Contrôles des accès pour l'interface utilisateur d'Edge

Contrôles des accès au portail des développeurs Apigee

  • Configurez l'authentification unique avec le fournisseur d'identité de votre entreprise.
  • Configurez le contrôle des accès basé sur les rôles (RBAC) pour autoriser uniquement les utilisateurs à accéder à la fonctionnalité et à la configuration dont ils ont besoin sur les portails de développement basés sur Drupal.
  • Configurez les portails des développeurs pour afficher des produits d'API spécifiques en fonction du rôle utilisateur.
  • Configurez le portail pour afficher ou masquer le contenu en fonction du rôle de l'utilisateur.

Contrôles des accès à l'API d'exécution Apigee

  • L'accès aux API peut être appliqué à l'aide de clés API, de jetons OAuth, de niveaux d'accès OAuth, de certificats et d'autres techniques.
  • Le fournisseur d'API configure les ressources disponibles en définissant un produit d'API. L'accès est accordé manuellement dans l'UI, via l'API de gestion ou via le portail des développeurs. Lorsqu'une application de développeur reçoit l'accès à un produit d'API, elle reçoit un ID client et un secret qui sont utilisés lors du processus d'authentification.
  • Apigee peut s'intégrer à n'importe quel fournisseur d'identité pour effectuer OAuth.
  • Apigee peut générer des jetons JWT ou d'autres techniques pour envoyer l'identité de l'utilisateur aux services cibles. Les services cibles peuvent utiliser cette identité pour restreindre l'accès aux services et aux données si nécessaire.

A6:2017-Security Misconfiguration

Les mauvaises configurations de sécurité sont faciles à ignorer, souvent parce que les administrateurs et les développeurs pensent à tort que les systèmes qu'ils utilisent sont intrinsèquement sécurisés. Une erreur de configuration de sécurité peut se produire de différentes manières, par exemple en faisant confiance aux configurations par défaut, en créant des configurations partielles susceptibles d'être non sécurisées, en laissant les messages d'erreur contenir des informations sensibles, en stockant des données dans le cloud sans contrôles de sécurité appropriés ou en cas de mauvaise configuration d'en-têtes HTTP, etc. La plate-forme Apigee fournit un certain nombre de mécanismes qui vous permettent de contrôler, de gérer et de surveiller les configurations de sécurité, y compris les flux partagés réutilisables.

Un flux partagé permet aux développeurs d'API de combiner des règles et des ressources dans un groupe réutilisable. En capturant les fonctionnalités réutilisables au même endroit, un flux partagé vous permet d'assurer la cohérence, de raccourcir le temps de développement et de gérer plus facilement le code. Vous pouvez inclure un flux partagé dans des proxys d'API individuels, ou aller plus loin et placer des flux partagés dans des hooks de flux pour exécuter automatiquement une logique de flux partagé pour chaque proxy d'API déployé dans le même environnement qu'un flux partagé.

Les versions des produits Apigee permettent de protéger contre les bibliothèques présentant des failles. Apigee peut publier des correctifs ou des mises à jour supplémentaires si de nouvelles failles sont détectées. Le cloud public Edge est automatiquement mis à jour. Les clients Edge pour le cloud privé (sur site) doivent appliquer eux-mêmes les correctifs de produit.

A7:2017-Script intersites (XSS)

Le script intersites (XSS) permet aux pirates informatiques d'exécuter des scripts dans les navigateurs Web des utilisateurs afin de contrôler leurs sessions, de manipuler des sites Web ou d'affecter les utilisateurs de manière malveillante. Les problèmes XSS ne sont pas nécessairement liés aux API, mais Apigee fournit des règles de protection contre les menaces qui peuvent être utilisées pour se protéger contre les attaques XSS dans l'API.  À l'aide d'expressions régulières, vérifiez la charge utile et les valeurs de paramètre pour JavaScript et tout autre type d'injection à l'aide de la règle RegularExpressionProtection ou de la règle JavaScript.

CORS, l'une des solutions couramment mises en œuvre pour la règle de même origine appliquée par tous les navigateurs, peut être implémenté à l'aide de la stratégie AssignMessage.

A8:2017 – Désérialisation non sécurisée

Les pirates informatiques peuvent utiliser des failles dans la désérialisation pour différents types d'attaques, tels que la répétition, l'élévation des privilèges et l'injection. La désérialisation non sécurisée peut également activer l'exécution de code à distance.

Apigee ne recommande pas la désérialisation. Toutefois, les règles JSONThreatProtection et RegularExpressionProtection peuvent vous aider à vous protéger contre les charges utiles JSON malveillantes. La règle JavaScript peut également être utilisée pour analyser les charges utiles à la recherche de contenu malveillant. Le cache et d'autres règles peuvent être utilisés pour se protéger contre les attaques par rejeu. Au niveau de l'infrastructure, la plate-forme Apigee intègre également des garde-fous pour protéger les processus en cours d'exécution.

A9:2017 – Utilisation de composants présentant des failles connues

Étant donné que les frameworks, les bibliothèques et les modules s'exécutent avec un accès CRUD et d'exécution complet, les pirates informatiques peuvent exploiter les failles des composants pour attaquer les systèmes.

Les versions régulières des produits Apigee permettent de protéger contre les failles de composants, en particulier lorsque des failles spécifiques sont détectées. Le cloud public Apigee est mis à jour automatiquement, et Apigee avertit les clients Edge pour Private Cloud lorsque des correctifs sur site sont disponibles à l'installation.

A10:2017 : Supervision et journalisation insuffisantes

Lorsque vous ne consignez, ne surveillez et ne gérez pas correctement les incidents dans vos systèmes, les pirates informatiques peuvent effectuer des attaques plus approfondies et plus longues sur les données et les logiciels.

Apigee propose plusieurs méthodes pour effectuer la journalisation, la surveillance, la gestion des erreurs et la journalisation d'audit.

Journalisation

  • Les messages de journal peuvent être envoyés à Splunk ou à d'autres points de terminaison syslog à l'aide de la stratégie MessageLogging.
  • Les données d'analyse des API peuvent être extraites par le biais de l'API d'analyse et importées ou exportées dans d'autres systèmes.
  • Dans Edge pour Private Cloud, vous pouvez utiliser la stratégie MessageLogging pour écrire dans des fichiers journaux locaux. Les fichiers journaux de chacun des composants en cours d'exécution sont également disponibles.
  • La stratégie JavaScript peut être utilisée pour envoyer des messages de journal à un point de terminaison de journalisation REST de manière synchrone ou asynchrone.

Surveillance

  • Utilisez l'interface utilisateur ou l'API API Monitoring pour surveiller régulièrement les API et les backends, et déclencher des alertes.
  • Utilisez la surveillance de l'état pour surveiller régulièrement les backends du serveur cible.
  • Apigee fournit des recommandations pour surveiller Edge pour Private Cloud.
  • Apigee fournit également des bonnes pratiques que votre équipe peut exploiter pour surveiller votre programme d'API.

Gestion des erreurs

Apigee propose un mécanisme de gestion des pannes puissant et polyvalent pour les proxys d'API. De la même manière qu'un programme Java intercepterait les exceptions, les proxys d'API pourraient détecter les défaillances et déterminer comment renvoyer les réponses appropriées aux clients. La gestion personnalisée des erreurs par Apigee vous permet d'ajouter des fonctionnalités telles que la journalisation des messages chaque fois qu'une erreur se produit.

Journaux d'audit

La plate-forme Apigee conserve un journal d'audit qui suit les modifications apportées aux proxys d'API, aux produits et à l'historique de l'organisation.  Ce journal est disponible via l'interface utilisateur ou via l'API Audits.

Solutions Apigee pour les failles OWASP de 2013

Lorsque l'OWASP a mis à jour sa liste pour 2017, certaines failles de la liste de 2013 ont été omises. Il s'agit néanmoins de menaces valides. Les sections suivantes décrivent comment gérer ces menaces avec Apigee.

A8:2013 – Falsification de requête intersites (CSRF)

Les requêtes de falsification intersites permettent aux pirates informatiques de transmettre les informations d'authentification, le cookie de session et d'autres données d'un utilisateur à une application Web vulnérable via HTTP, en lui faisant croire qu'il s'agit de requêtes légitimes de l'utilisateur.

Consignes :

  • Il s'agit plutôt d'un problème de navigateur, et non d'un problème lié au produit d'API. Vous pouvez remédier à cette faille à l'aide d'OpenID Connect, d'OAuth et d'autres techniques.
  • Envisagez d'utiliser des techniques HMAC, d'état, de hachage, de nonce ou de PKCE pour éviter les attaques de falsification et de rejeu.

A10:2013 – Redirections et transferts non validés

Si une application Web effectue des redirections, mais qu'elle ne vérifie pas que les redirections envoient les utilisateurs vers des sites Web fiables et prévus, les pirates informatiques peuvent rediriger les utilisateurs vers des destinations malveillantes pour effectuer des attaques par hameçonnage, l'exécution de logiciels malveillants et d'autres attaques.

Consignes :

  • Utilisez OAuth et appliquez la validation à chaque requête.
  • Évitez les redirections 302 inattendues en vérifiant les codes de réponse dans la logique du proxy d'API et en gérant les redirections de manière appropriée.