Série « Les développeurs à la conquête de la sécurité de l'infrastructure en tant que code » - Logique métier

C'est tout pour le moment. Nous sommes arrivés au terme de notre série sur l'Infrastructure as Code. Nous espérons que vous avez pris plaisir à résoudre les problèmes de sécurité dans Docker, Ansible, Kubernetes, Terraform et CloudFormation. Avant de nous quitter, nous avons une dernière vulnérabilité à vous présenter : les failles de logique métier.

Vous pensez être prêt à tester vos compétences ? Essayez le défi ludique final :

Si certains points restent flous, continuez votre lecture :

Les vulnérabilités sur lesquelles nous souhaitons nous concentrer aujourd'hui sont les failles de logique métier. Elles peuvent survenir lorsque les développeurs ne parviennent pas à implémenter correctement les règles de logique métier, ce qui pourrait rendre leurs applications vulnérables à divers types d'attaques si un utilisateur malveillant choisissait de les exploiter. Selon l'objectif et les fonctionnalités implémentées dans chaque application, une faille de logique métier peut permettre une élévation de privilèges, une utilisation inappropriée des ressources ou l'exécution de tout un ensemble de processus métier non intentionnels.

Contrairement à de nombreuses vulnérabilités, une implémentation incorrecte des règles de logique métier peut être étonnamment subtile. Une vigilance particulière est requise pour éviter qu'elles ne se glissent dans les applications et le code.

Quels sont quelques exemples de failles de logique métier ?

Pour illustrer la facilité avec laquelle des failles de logique métier peuvent être induites, prenons l'exemple suivant dans un environnement Docker défini par un fichier Docker Compose. Pour préparer les conteneurs à remplir leurs fonctions, un développeur peut utiliser une politique de ressources standard, définie dans le fichier Docker Compose, comme dans l'exemple ci-dessous :

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"

Bien que cela semble correct en apparence, cette politique de ressources pour les conteneurs ne limite pas correctement l'utilisation des ressources. Un attaquant pourrait tirer parti de cette faille de logique métier pour mettre en œuvre une attaque par déni de service (DoS).

Pour tenter d'empêcher les utilisateurs de consommer trop de ressources, un développeur pourrait essayer de mieux définir ce que chaque conteneur peut supporter. Le nouveau code pourrait donc inclure une contrainte de placement :

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"
   placement:
     constraints:
       - "node.labels.limit_cpu == 100M"
       - "node.labels.limit_memory == 0.5"

À première vue, cela semble résoudre la faille de logique métier. Cependant, la nouvelle contrainte de placement n'affecte pas la limite d'utilisation des ressources pour le service de conteneur Docker. Elle est uniquement utilisée pour sélectionner un nœud sur lequel planifier le conteneur. Dans ce cas, une attaque DoS reste possible. L'attaquant devrait d'abord compromettre un conteneur Docker, mais serait ensuite en mesure d'épuiser les ressources sans aucune limite.

Comme vous pouvez le constater, réfléchir aux failles de logique métier et programmer pour les éliminer peut être une tâche délicate.

Éliminer les failles de logique métier

Avec les failles de logique métier, la clé est d'avoir conscience de leur existence. Vous devez rester vigilant pour les exclure de votre environnement pendant l'écriture du nouveau code. Les règles métier et les meilleures pratiques doivent être clairement définies et vérifiées à toutes les phases du processus de développement de l'application, y compris la conception, l'implémentation et les tests.

Par exemple, pour éviter qu'une faille de logique métier ne permette une attaque DoS comme dans l'exemple ci-dessus, une bonne pratique consiste à limiter la quantité de ressources que chaque conteneur Docker que vous créez peut utiliser. Plus précisément, la section des limites doit spécifier le nombre de processeurs et la quantité de mémoire qu'un conteneur Docker peut utiliser. Voici un exemple :

deploy:
 resources:
   limits:
     cpus: "0.5"
     memory: 100M
   reservations:
     cpus: "0.5"
     memory: 50M

L'utilisation d'un code tel que l'exemple ci-dessus comme politique supprimerait une faille de logique métier majeure de l'environnement et empêcherait les attaques DoS. Cela fonctionnerait même si un attaquant compromettait l'un des conteneurs Docker. Dans ce cas, l'attaquant ne pourrait toujours pas utiliser son point d'ancrage pour épuiser les ressources.

La modélisation des menaces permet de définir le déroulement des différentes attaques et de garantir que les règles de logique métier sont appliquées pour les prévenir et les limiter. Des tests basés sur des règles de conformité et des cas d'abus connus peuvent également aider à détecter les failles de logique métier qui passeraient entre les mailles du filet.

Les failles de logique métier comptent parmi les vulnérabilités les plus subtiles pouvant s'immiscer dans les applications, mais elles n'en sont pas moins dangereuses que d'autres risques plus médiatisés. Comprendre leur origine et appliquer les meilleures pratiques permet de les écarter lors du développement, garantissant qu'elles n'atteignent jamais l'environnement de production où elles pourraient être exploitées par des attaquants aguerris.

Consultez les pages du blog Secure Code Warrior pour en savoir plus sur cette vulnérabilité et découvrir comment protéger votre organisation et vos clients contre les ravages d'autres failles de sécurité. Vous pouvez également demander une démonstration de ce défi IaC sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.