Les 10 principales menaces sur les applications Web

Vous consultez la documentation Apigee Edge.
Accéder à la documentation d'Apigee X en savoir plus

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 connaître les approches supplémentaires documentées pour Apigee, consultez le document OWASP Top 10 2021 options options on Google Cloud.

Présentation

Les écosystèmes d'API font l'objet de diverses attaques de la part des clients externes et internes. Proposer et utiliser des API offre d'immenses opportunités aux fournisseurs de services, mais présente également des risques de sécurité. Les développeurs doivent être conscients de ces défis et les relever lorsqu'ils créent et utilisent des API.

OWASP est une communauté ouverte qui vise à aider les organisations à développer, acheter et gérer des applications et des API fiables. Dans le cadre du projet de sécurité de l'API OWASP, l'équipe OWASP publie les risques de sécurité les plus critiques dans 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 formulées du client avant qu'elles ne soient traitées sur les systèmes backend. Cela réduit les risques et protège vos services. Un format de requête incorrect peut inclure n'importe quel composant faisant partie du protocole HTTP au niveau de l'application:

  • URL
  • En-têtes
  • Chemin d'accès
  • Charge utile

Les requêtes API mal formées peuvent provenir de clients connus ou inconnus développés par des développeurs externes ou internes, ou des bots malveillants. Ces types de requêtes constituent la majorité des menaces OWASP, mais des composants supplémentaires 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 intelligente de gestion des API d'Apigee vous permet de corriger 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 dans le top 10 de l'OWASP 2017

Le développement et la sécurisation des applications Web posent de nombreux problèmes de sécurité. L'OWASP a publié sa liste des 10 principales menaces de sécurité OWASP 2017 pour les applications Web. Bien qu'une application Web comporte de nombreux éléments, la plupart des applications Web modernes s'appuient en grande partie sur les API REST. Apigee n'est pas conçu pour répondre à 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, accompagnées d'une description expliquant comment utiliser Apigee pour gérer ces menaces.

A1:2017 - Injection

Pour se protéger contre les injections de données non fiables telles que SQL, NoSQL, LDAP et JavaScript, qui peuvent entraîner l'exécution de commandes non désirées ou un accès non autorisé aux données, Apigee fournit plusieurs règles de validation des entrées qui permettent de vérifier que les valeurs fournies par un client correspondent aux attentes avant d'autoriser un traitement ultérieur. Apigee Edge, qui agit 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 des limites. Vous pouvez configurer un proxy d'API de sorte que la routine de validation des entrées transforme l'entrée pour supprimer les séquences de caractères à risque et les remplacer par des valeurs sûres.

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

Validez les types de contenu:

A2:2017 – Authentification et gestion de session interrompues

Des 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 exploitant des failles d'implémentation dans les applications. Il s'agit davantage d'un problème d'implémentation, et non de produit. Apigee fournit des règles VerifyApiKey, OAuth et JSON Web Token (JWT), qui contribuent à la protection contre cette faille.

Validation des clés API

La validation des clés API est la forme la plus simple de sécurité basée sur l'application pouvant être configurée pour une API. Une application cliente présente simplement une clé API avec sa demande, puis Apigee Edge, via une stratégie attachée à un proxy d'API, vérifie que la clé API est dans un état approuvé pour la ressource demandée.

Apigee propose une assistance pour la génération et la validation des clés API. Apigee génère une clé API et un code secret lorsqu'une application de développement est créée et approuvée, associée à un ou plusieurs produits d'API.

Le terme "clés API" peut parfois avoir des significations différentes. Dans Apigee, lorsque la relation entre l'application et le produit est établie, Apigee génère un ID et un code secret du client. Certains font référence à la fois à l'ID et au code secret en tant que clé API. Certains se réfèrent uniquement à l'ID client comme clé API. Dans l'interface utilisateur Edge, vous trouverez "clé client" et "code 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 auprès des proxys d'API regroupés dans le produit d'API.

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

Pour les types d'authentification OAuth, l'ID client et le code secret sont 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 pour le compte d'un propriétaire de la ressource en orchestrant une interaction d'approbation entre le propriétaire de la ressource et le service HTTP, soit en autorisant l'application tierce à obtenir l'accès pour son propre compte.

Les stratégies OAuth 2.0 d'Apigee vous permettent de mettre en œuvre et de personnaliser les quatre types d'autorisation OAuth 2.0. L'application du jeton d'accès OAuth peut être appliquée à l'aide de la stratégie OAuthv2. Le consommateur doit être enregistré et disposer d'une application approuvée lui permettant d'accéder à l'API. En échange, ils recevront un ID client d'API et un code secret du client. Le consommateur doit passer par l'une des authentifications 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 les jetons JWT à l'aide de trois règles.

  • Générer des jetons JWT (accepte les signatures HS256 et RS256)
  • Valider les jetons JWT
  • Décoder les jetons JWT sans les valider

A3:2017 – Exposition aux données sensibles

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

Le protocole TLS (Transport Layer Security, prédécesseur, SSL) est la technologie de sécurité standard permettant d'établir une liaison chiffrée entre un serveur Web et un client Web, tel qu'un navigateur ou une application. Apigee est compatible avec les protocoles TLS unidirectionnel et bidirectionnel.

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

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

Apigee est compatible avec de nombreuses options de configuration TLS.

L'application du protocole TLS à deux voies garantit que le client utilise un certificat qui a déjà été intégré à Apigee. OWASP fournit également des bonnes pratiques TLS.

Dans Apigee hybrid, TLS est disponible au niveau de 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 le protocole TLS unidirectionnel et bidirectionnel, qui assurera la protection au niveau du protocole.
  • Utilisez des règles telles que AssignMessage et JavaScript pour supprimer les données sensibles avant qu'elles ne soient renvoyées au client.
  • Utilisez les techniques OAuth standards, et envisagez d'ajouter des techniques HMAC, un hachage, un état, un nonce, une clé PKCE ou d'autres techniques 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 ni à chiffrer les données sensibles qui y sont stockées. Dans Edge, vous pouvez chiffrer les données sensibles au repos dans les mappages clé-valeur.

A4:2017 – Entités XML externes

Les systèmes ou les applications qui traitent des fichiers XML doivent gérer des "références d'entité externe" en XML, c'est-à-dire des références aux fichiers ou aux données qui sont remplacées par les données réelles lors du traitement XML. Si les applications ou les processeurs XML sont anciens ou mal implémentés, des pirates informatiques peuvent pirater les données et les utiliser pour voler des informations ou lancer différents 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. Cette règle applique un format de texte au contenu du message et, lorsqu'une correspondance est trouvée, elle 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 assurer une protection contre les charges utiles XML malveillantes.

A5:2017 – Contrôle d'accès non fonctionnel

Une fois que les utilisateurs se connectent et ont accès à un système, des contrôles d'autorisation appropriés doivent être mis en place pour qu'ils ne puissent voir et faire que ce qu'ils sont autorisés à faire. Sans contrôles d'accès renforcé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 prend en charge une approche multicouche pour 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 d'accès pour l'interface utilisateur Edge

Contrôles des accès pour le 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 n'autoriser l'accès des utilisateurs qu'aux fonctionnalités et à la configuration dont ils ont besoin sur les portails de développeurs basés sur Drupal.
  • Configurez des portails pour les développeurs afin d'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 utilisateur.

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

  • L'accès aux API peut être appliqué via des clés API, des jetons OAuth, des champs d'application OAuth, des 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'interface utilisateur, via l'API de gestion ou via le portail des développeurs. Lorsque l'application d'un développeur obtient l'accès à un produit d'API, elle reçoit un ID client et un code secret utilisés dans le processus d'authentification.
  • Apigee peut s'intégrer à n'importe quel fournisseur d'identité pour exécuter OAuth.
  • Apigee peut générer des jetons JWT ou d'autres techniques pour envoyer l'identité d'un 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 – Mauvaise configuration de la sécurité

Les erreurs de configuration liées à la sécurité sont faciles à négliger, souvent parce que les administrateurs et les développeurs pensent à tort que les systèmes qu'ils utilisent sont intrinsèquement sécurisés. Les erreurs de configuration liées à la sécurité peuvent se produire de différentes manières, par exemple en faisant confiance aux configurations par défaut ou en effectuant des configurations partielles potentiellement 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, en cas de configuration incorrecte des en-têtes HTTP, etc. La plate-forme Apigee offre 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 en un seul endroit, un flux partagé vous aide à assurer la cohérence, à raccourcir le temps de développement et à gérer plus facilement le code. Vous pouvez inclure un flux partagé à l'intérieur de 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 garantissent la protection 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 en périphérie est appliqué automatiquement. Les clients Edge for Private Cloud (sur site) doivent appliquer eux-mêmes les correctifs du produit.

A7:2017 – Script intersites (XSS)

Les scripts intersites (XSS) permettent aux pirates informatiques d'exécuter des scripts dans les navigateurs Web des utilisateurs pour contrôler les sessions utilisateur, manipuler des sites Web ou avoir un impact malveillant sur les utilisateurs. 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 exploitées pour se prémunir contre les attaques XSS dans l'API. À l'aide d'expressions régulières, à l'aide de la règle RegularExpressionProtection ou JavaScript, vérifiez les valeurs de charge utile et de paramètres pour JavaScript et d'autres attaques par injection.

CORS, l'une des solutions couramment implémentées pour les règles d'origine identique appliquée par tous les navigateurs, peut être implémenté à l'aide de la règleAssignMessage.

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

Les pirates informatiques peuvent exploiter les failles de la désérialisation pour différents types d'attaques, tels que la relecture, l'élévation des privilèges et l'injection. Une désérialisation non sécurisée peut également permettre l'exécution de code à distance.

Apigee ne recommande pas la désérialisation. Toutefois, la règle JSONThreatProtection et la règle RegularExpressionProtection peuvent aider à se prémunir contre les charges utiles JSON malveillantes. Vous pouvez également utiliser la règle JavaScript 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 dispose également de garde-fous intégrés pour protéger les processus en cours d'exécution.

A9:2017 – Utiliser des composants présentant des failles connues

Étant donné que les frameworks, les bibliothèques et les modules s'exécutent de manière complète et bénéficient d'un accès CRUD, les pirates informatiques peuvent exploiter les failles des composants pour attaquer des systèmes.

Les versions régulières du produit Apigee offrent une protection contre les failles de composants, en particulier lorsque des failles spécifiques sont découvertes. Le cloud public Apigee est corrigé automatiquement, et Apigee avertit Edge for Private Cloud lorsque des correctifs sur site sont disponibles pour l'installation.

A10:2017 – Journalisation et surveillance insuffisantes

Si la journalisation, la surveillance et la gestion des incidents ne sont pas correctement effectuées dans vos systèmes, les pirates informatiques peuvent procéder à des attaques plus profondes et plus longues sur les données et les logiciels.

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

Journalisation

  • Les messages de journal peuvent être envoyés à Splunk ou à un autre point de terminaison syslog à l'aide de la règle MessageLogging.
  • Les données d'analyse de l'API peuvent être extraites via l'API Analytics et importées ou exportées dans d'autres systèmes.
  • Dans Edge for Private Cloud, vous pouvez utiliser la stratégie MessageLogging pour écrire dans les fichiers journaux locaux. Les fichiers journaux de chacun des composants en cours d'exécution sont également disponibles.
  • La règle JavaScript permet d'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 alets.
  • Utilisez la surveillance de l'état pour surveiller régulièrement les backends des serveurs cibles.
  • Apigee fournit des recommandations pour surveiller Edge pour le cloud privé.
  • Apigee fournit également des bonnes pratiques dont votre équipe peut se servir pour surveiller votre programme d'API.

Gestion des erreurs

Apigee offre 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 détecte les exceptions, les proxys d'API peuvent détecter les pannes et déterminer comment renvoyer des réponses appropriées aux clients. La gestion personnalisée des pannes d'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 2013

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

A8:2013 – Contrefaçon de demande sur plusieurs sites (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 la faisant croire à l'application Web qu'il s'agit de requêtes légitimes émanant de l'utilisateur.

Recommandations :

  • Il s'agit davantage d'un problème lié au navigateur, et non à un produit d'API. Vous pouvez corriger cette faille avec OpenID Connect, OAuth et d'autres techniques.
  • Pensez à utiliser des techniques HMAC, état, hachage, nonce ou PKCE pour empêcher les attaques par falsification et par rejeu.

A10:2013 – Redirections et transferts non validés

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

Recommandations :

  • 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 de proxy d'API et en gérant les redirections de manière appropriée.