Les 10 principales menaces sur les applications Web

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

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

Présentation

Les écosystèmes d'API sont la cible de diverses attaques de clients externes et internes. L'offre et l'utilisation d'API créent d'énormes opportunités pour les fournisseurs de services, mais présentent également certains 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 aide les organisations à développer, acheter et maintenir des applications et des API fiables. Par le biais du projet OWASP API Security, 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 de proxy d'API peut détecter, bloquer et signaler les requêtes d'API mal formées du client avant qu'elles ne soient traitées sur les systèmes de backend, ce qui réduit les risques et protège vos services. Les requêtes mal formées peuvent inclure n'importe quel composant constituant le protocole au niveau de l'application HTTP :

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

Les requêtes d'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 robots malveillants. Ces types de requêtes représentent la majorité des menaces OWASP, mais d’autres composants de la couche de 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 de manière transparente les principales failles de sécurité des API OWASP tout en adoptant une approche axée sur la consommation pour concevoir vos API et les connecter à vos systèmes de backend. Vous trouverez ci-dessous une liste des règles/configurations recommandées par Apigee pour les principales menaces OWASP REST.

Solutions Apigee pour le top 10 de l'OWASP 2017

La création et la sécurisation d'applications Web soulèvent de nombreuses préoccupations en matière 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 nombreuses parties, la plupart des applications Web modernes reposent fortement 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, ainsi qu'une description de la manière dont vous pouvez utiliser Apigee pour y faire face.

A1:2017 – Injection

Pour vous protéger contre l'injection de données non approuvées telles que SQL, NoSQL, LDAP et JavaScript, qui peuvent entraîner l'exécution de commandes non intentionnelles ou l'accès non autorisé aux données, Apigee fournit plusieurs règles de validation d'entrée 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 d'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, puis 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 – Gestion des sessions et authentification défaillante

Les pirates informatiques peuvent accéder aux mots de passe, aux jetons de session et aux clés pour se faire passer pour d'autres utilisateurs en exploitant les failles d'implémentation des applications en prenant avantage. Il s'agit davantage d'un problème d'implémentation que 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 que vous pouvez configurer pour une API. Une application cliente présente simplement une clé API avec sa requête, puis Apigee Edge, via une règle associée à un proxy d'API, vérifie que la clé API est dans un état approuvé pour la ressource demandée.

Apigee est compatible avec 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é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 différentes significations. Dans Apigee, lorsque la relation entre l'application et le produit est établie, Apigee génère un ID client et un code secret client. Certains appellent l' ID et le code secret la clé API. D'autres appellent uniquement l'ID client la clé API. Dans l'interface utilisateur Edge, vous verrez "clé client" et "code secret client".

Dans la règle VerifyAPIKey, seul l'ID client, ou "clé client", est vérifié. 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 vers les 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 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 en son nom.

Les règles OAuth 2.0 d'Apigee vous permettent d'implémenter et de personnaliser les quatre types d'attribution OAuth 2.0. L'application du jeton d'accès OAuth peut être effectuée à l'aide de la règle OAuthV2. Le consommateur doit être enregistré et disposer d'une application approuvée qui lui donne accès à l'API. En retour, il recevra un ID client et un code secret client pour l'API. Le consommateur 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, servent couramment à partager des revendications ou des assertions entre des applications connectées Apigee est compatible avec JWT au moyen de trois règles.

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

A3:2017 – Exposition de données sensibles

Les pirates informatiques ciblent les données sensibles telles que les informations relatives à la carte de crédit, les numéros de sécurité sociale, les identifiants de connexion, les informations permettant d'identifier personnellement l'utilisateur (PII) 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, au repos et en transit, ainsi que d'autres stratégies pour assurer la protection des données sensibles.

TLS (Transport Layer Security, dont le prédécesseur est SSL) est la technologie de sécurité standard pour é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 unidirectionnel et bidirectionnel.

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

Le protocole TLS en aval (Apigee en tant que client se connectant au service de backend) est compatible grâce à 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 bidirectionnel garantit que le client utilise un certificat qui a déjà été intégré à Apigee. L'OWASP fournit également des bonnes pratiques TLS.

Dans Apigee hybrid, le protocole TLS est disponible au niveau de l' entrée via un alias d'hôte, qui est un concept similaire à celui d'un hôte virtuel.

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

  • Utilisez une plate-forme compatible avec le protocole TLS unidirectionnel et bidirectionnel, qui protège au niveau du protocole.
  • Utilisez des stratégies telles que la règle d'affectation de message et 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 les mappages de clés.

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" dans 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 anciens ou mal implémentés, les 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, telles que le 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. Lorsqu'elle est exécutée, la règle applique un modèle de texte au contenu du message et, lors de la recherche d'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 se protéger contre les charges utiles XML malveillantes.

A5:2017 – Contrôle d'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 que les utilisateurs ne puissent voir et faire que ce qui leur est autorisé. Sans contrôles d'accès stricts, les pirates informatiques peuvent afficher 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 d'accès pour l'interface utilisateur Edge

Contrôles d'accès pour le portail des développeurs Apigee

Contrôles d'accès pour l'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é soit manuellement dans l'interface utilisateur, via l'API de gestion ou via le portail des développeurs. Lorsqu'une application de développeur est autorisée à accéder à un produit d'API, elle reçoit un ID client et un code secret qui sont utilisés dans le processus d'authentification.
  • Apigee peut s'intégrer à n'importe quel fournisseur d'identité pour effectuer l'authentification 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 limiter l'accès aux services et aux données selon les besoins.

A6:2017 – Erreur de configuration de sécurité

Les erreurs de configuration de 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. 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, et ainsi de suite. 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 les 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 de 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 Edge est corrigé automatiquement. Les clients d'Edge pour Private Cloud (sur site) doivent appliquer eux-mêmes les correctifs du produit.

A7:2017 – Script intersites (XSS)

Le script intersites (XSS) permet aux pirates informatiques d'exécuter des scripts dans des navigateurs Web afin de contrôler les sessions utilisateur, de manipuler les sites 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 stratégie RegularExpressionProtection ou de la stratégie JavaScript.

CORS, l'une des solutions couramment mises en œuvre en réponse à la règle de même origine appliquée par tous les navigateurs, peut être implémentée à l'aide de la règle 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 distant.

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 vous protéger contre les attaques par relecture. 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 – 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 complet à l'exécution et à la création, la lecture, la mise à jour et la suppression (CRUD), les pirates informatiques peuvent exploiter les failles des composants pour attaquer les systèmes.

Les versions régulières des produits Apigee garantissent la protection contre les failles des composants, en particulier lorsque des failles spécifiques sont découvertes. Le cloud public Apigee est corrigé automatiquement, et Apigee informe les clients d'Edge pour Private Cloud lorsque des correctifs sur site sont disponibles pour l'installation.

A10:2017 – Journalisation et surveillance insuffisantes

Si vous n'effectuez pas correctement la journalisation, la surveillance et la gestion des 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

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 2013

Lorsque l'OWASP a mis à jour sa liste pour 2017, certaines failles de la liste de 2013 ont été supprimées. Elles constituent toujours des menaces valides. Les sections suivantes décrivent comment gérer ces menaces avec Apigee.

A8:2013 – Falsification de requêtes 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 faisant croire à l'application Web que les requêtes sont légitimes.

Recommandations :

  • Il s'agit davantage d'un problème de navigateur que d'un problème de produit d'API. Vous pouvez résoudre cette faille avec OpenID Connect, OAuth et d'autres techniques.
  • Envisagez d'utiliser les techniques HMAC, d'état, de hachage, nonce ou PKCE pour éviter les attaques par falsification et par relecture.

A10:2013 – Redirections et transferts non validés

Si une application Web effectue des redirections, mais ne valide pas que les redirections envoient les utilisateurs vers des sites Web fiables et prévus, les pirates informatiques peuvent envoyer les utilisateurs vers des destinations malveillantes pour effectuer des attaques de phishing, exécuter des logiciels malveillants et d'autres attaques.

Recommandations :

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