Les codeurs conquièrent l'infrastructure de sécurité sous forme de séries de codes en utilisant des composants provenant de sources non fiables

Nous approchons de la fin de notre série Infrastructure as Code, mais cela a été formidable d'aider les développeurs comme vous dans leur transition vers la sécurité de l'IaC.

Avez-vous déjà relevé les défis ? Quel est ton score jusqu'à présent ? Avant de commencer, voyons ce que vous savez déjà sur les pièges liés à l'utilisation de composants provenant de sources non fiables :

Vous avez encore du travail à faire ? Lisez la suite :

Le comportement générateur de vulnérabilités sur lequel nous allons nous concentrer aujourd'hui consiste à utiliser du code provenant de sources non fiables, une pratique apparemment bénigne qui pose de gros problèmes. L'utilisation de code et de ressources open source présente de nombreux avantages. En général, cela permet aux experts d'apporter leurs idées, leurs travaux et même leur code complet à des référentiels tels que GitHub pour être utilisés par d'autres personnes qui ont du mal à faire fonctionner correctement un programme ou une application. L'utilisation de code complet pour régir les fonctions du programme évite aux développeurs de devoir réinventer la roue chaque fois qu'ils ont besoin de créer une nouvelle application.

Cependant, l'utilisation d'extraits de code provenant de sources peu fiables, non vérifiées ou même potentiellement dangereuses comporte de nombreux risques. En fait, l'utilisation de code provenant de sources non fiables est l'une des manières les plus courantes d'introduire des failles de sécurité majeures et mineures dans des applications par ailleurs sécurisées. Parfois, ces vulnérabilités sont induites accidentellement par leurs créateurs. Il est également arrivé que du code malveillant ait été écrit par des attaquants potentiels. Le code est ensuite partagé dans l'espoir de piéger les victimes qui l'ajouteront à leurs applications.

Pourquoi l'utilisation de code provenant de sources non fiables est-elle dangereuse ?

Supposons qu'un développeur soit pressé et doive configurer une application qu'il développe. Cela peut être un processus délicat. Ainsi, au lieu de passer beaucoup de temps à essayer de trouver toutes les configurations possibles, ils font une recherche sur Google et trouvent quelqu'un qui a déjà rempli un fichier de configuration apparemment parfait. Même si le développeur ne sait rien de la personne qui a écrit le code, l'ajouter à une nouvelle application est relativement facile. Cela peut être fait dans l'environnement Docker en utilisant deux lignes :

EXÉCUTEZ cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/ \
9d372cfa8855a6be74bcca86efadfbbf/raw/ \
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Maintenant, l'image Docker va extraire dynamiquement le fichier de configuration tiers. Et même si le fichier est testé et qu'il s'avère correct à ce moment-là, le fait que le pointeur soit désormais intégré dans le code de la nouvelle application signifie qu'il existe une dépendance permanente. Des jours, des semaines ou des mois plus tard, le fichier peut être modifié par l'auteur d'origine ou par un attaquant qui a compromis le référentiel de code. Soudainement, le fichier de configuration partagé peut indiquer à l'application de fonctionner très différemment de celle prévue, en donnant éventuellement accès à des utilisateurs non autorisés ou même en volant directement des données et en les exfiltrant.

Une meilleure façon d'utiliser les ressources partagées

Si votre organisation autorise l'utilisation de code provenant de sources externes, des processus doivent être mis en place pour garantir que cela se fait en toute sécurité. Lorsque vous évaluez un code externe pour une utilisation potentielle, assurez-vous d'acquérir des composants provenant de sources officielles uniquement à l'aide de liens sécurisés. Et même dans ce cas, vous ne devez jamais créer de lien vers une source externe pour extraire ce code, car cela vous enlève le contrôle du processus. Au lieu de cela, le code approuvé doit être transféré dans une bibliothèque sécurisée et utilisé uniquement à partir de cet emplacement protégé. Ainsi, dans un environnement Docker, le code ressemblerait à ceci :

COPIEZ src/config/default-ssl.conf /etc/apache2/sites-available/

Au lieu de s'appuyer sur des fichiers de configuration tiers distants, cela s'appuierait plutôt sur une copie locale de ces fichiers. Cela permettra d'éviter toute modification inattendue ou malveillante.

Outre l'utilisation d'une bibliothèque de code sécurisée, un processus de gestion des correctifs doit être mis en place pour surveiller en permanence les composants tout au long du cycle de vie du logiciel. Tous les composants côté client et côté serveur doivent également être vérifiés pour détecter les alertes de sécurité à l'aide d'outils tels que NVD ou CVE. Enfin, supprimez toutes les dépendances et fonctionnalités inutilisées ou inutiles qui pourraient être associées au code externe.

En suivant ces étapes, les développeurs peuvent utiliser des ressources externes de manière plus sûre sans induire accidentellement des vulnérabilités dans leurs applications et leur code.

Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo des défis IaC de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.