Renforcer la sécurité de votre Gemfile Ruby : guide étape par étape avec Snyk

Ruby est un langage bien défini et mûrement réfléchi, qui existe depuis le milieu des années 1990. En 2004, Ruby a intégré RubyGems comme gestionnaire de paquets. RubyGems sert à gérer les bibliothèques et les dépendances dans un format autonome appelé gem. RubyGems s’utilise via un outil en ligne de commande qui s’intègre à l’environnement d’exécution Ruby et permet d’ajouter ou de mettre à jour des Gemfiles dans un projet.

J’ai examiné trois plateformes Ruby et découvert des vulnérabilités qui m’ont surpris, moi aussi. Voici ce qu’il faut rechercher pour mieux sécuriser votre Gemfile Ruby, et comment réagir si vous découvrez des vulnérabilités.

Le rôle de la gestion des paquets

Comme d’autres langages, Ruby propose plusieurs options de gestion des paquets. L’une des plus utilisées pour gérer les applications est Bundler, qui est en fait installé à l’origine sous forme de gem Ruby.

Un gestionnaire de paquets comme Bundler peut installer de nombreuses gems figurant dans un Gemfile, tandis qu’avec RubyGems, il faut les installer une par une à l’aide de gem install. Cela simplifie la gestion des paquets Ruby lorsque vous devez maintenir ou installer un grand nombre de gems dans une application.

Les gestionnaires de paquets facilitent indéniablement la maintenance des bibliothèques et des dépendances d’une application. Toutefois, il est important de savoir ce que vous utilisez et quels risques peuvent apparaître dans votre stack. Un simple scan de sécurité permet d’identifier rapidement les problèmes éventuels et de gagner du temps et de l’argent, tout en préservant la confiance de vos utilisateurs finaux.

Examen des vulnérabilités

Avant d’aborder les résultats de mes scans sur des plateformes que j’ai utilisées par le passé, je tiens à préciser quelques points :

• En tant qu’utilisateur et développeur de ces plateformes, j’ai été surpris par mes résultats. Cela confirme qu’il est essentiel de sensibiliser et de former en continu pour développer des logiciels de manière sécurisée.

• Dans tous les cas ci-dessous, j’ai contacté les communautés concernées pour discuter des vulnérabilités et m’assurer qu’elles en avaient connaissance, même si beaucoup disposaient déjà de correctifs.

Spree Commerce

Spree est l’une des plateformes de commerce en ligne les plus utilisées dans l’écosystème Ruby. C’est depuis toujours l’une de mes solutions open source de prédilection pour le commerce en ligne. Spree existe depuis 2007 et bénéficie d’une vaste communauté de développeurs et d’entreprises qui contribuent à sa maintenance.

La première étape du scan consiste à créer un manifeste Gemfile.lock qui pourra être analysé avec l’outil Snyk CLI. Après avoir cloné le dépôt Spree et lancé Bundle install, le fichier de verrouillage est créé à partir des bibliothèques et dépendances requises indiquées dans le manifeste Gemfile du projet.

Un conseil aux utilisateurs d’OSX et de brew avec MariaDB installé : l’installation de la gem MySQL2 peut générer une erreur pendant le processus d’installation de Bundler. J’ai dû commencer par exécuter brew install openssl, puis définir le chemin à l’aide de export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/opt/openssl/lib/

Une fois le fichier de verrouillage créé, exécutez [snyk test](https://snyk.io/blog/snyk-cli-cheat-sheet/). Le scan a révélé les vulnérabilités de gravité moyenne suivantes :

1Tested 142 dependencies for known issues, found 2 issues, 84 vulnerable paths.
2
3Issues with no direct upgrade or patch:
4  ✗ Information Exposure [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-ACTIONCABLE-20338] in actioncable@6.1.4
5    introduced by spree@4.3.0.alpha > spree_core@4.3.0.alpha > active_storage_validations@0.9.5 > rails@6.1.4 > actioncable@6.1.4 and 1 other path(s)
6  No upgrade or patch available
7  ✗ Web Cache Poisoning [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-RACK-1061917] in rack@2.2.3
8    introduced by actionpack@6.1.4 > rack@2.2.3 and 81 other path(s)
9  No upgrade or patch available

Le scan ci-dessus a identifié deux problèmes de gravité moyenne.

La vulnérabilité d’exposition d’informations est introduite par une dépendance indirecte via une gem appelée alpha, avec spree_core. Comme son nom l’indique, elle peut permettre la récupération à distance de données depuis la plateforme principale.

Empoisonnement du cache Web est l’autre vulnérabilité identifiée, introduite par une dépendance indirecte via une gem appelée actionpack. Elle permet essentiellement à un attaquant de manipuler le cache du serveur afin qu’il renvoie des réponses malveillantes à des requêtes légitimes. Pour en savoir plus, consultez cet article sur l’empoisonnement du cache.

Sinatra

Sinatra est un serveur Web léger et portable. C’est l’un de mes outils préférés pour les démos et les petites applications, et il permet aussi de démarrer des applications très rapidement et facilement. Avec plus de 160 millions de téléchargements à ce jour, il est largement utilisé pour une grande variété de projets.

Cette fois, j’ai utilisé Bundler pour exécuter bundle init dans un nouveau répertoire et créer un Gemfile vierge, puis j’ai modifié le fichier pour ajouter gem 'sinatra' à la fin. J’ai également ajouté une gem appelée erubis, couramment utilisée pour la création de modèles HTML et permettant un développement frontend rapide (elle fonctionne très bien avec Sinatra).

1# frozen_string_literal: true
2
3source "https://rubygems.org"
4
5gem 'sinatra'
6gem 'erubis'

Une fois le Gemfile enregistré, installez toutes les dépendances requises en exécutant bundler install. Après quelques secondes, le gestionnaire de paquets crée un manifeste Gemfile.lock : le projet est alors prêt pour un scan de sécurité. Voici les résultats de mon scan :

1Tested 7 dependencies for known issues, found 2 issues, 3 vulnerable paths.
2
3Issues with no direct upgrade or patch:
4  ✗ Cross-site Scripting (XSS) [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-ERUBIS-20482] in erubis@2.7.0
5    introduced by erubis@2.7.0
6  No upgrade or patch available
7  ✗ Web Cache Poisoning [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-RACK-1061917] in rack@2.2.3
8    introduced by sinatra@2.1.0 > rack@2.2.3 and 1 other path(s)
9  No upgrade or patch available

J’ai examiné la vulnérabilité de la gem erubis (CWE-79). La documentation présente une méthode d’échappement incorrecte qui pourrait exposer l’application à une attaque XSS. Dans la documentation d’erubis, de nombreux exemples utilisent <%= expr %>, ce qui n’échappe pas les variables de modèle enregistrées. Pour effectuer correctement l’échappement et éviter que des éléments HTML enregistrés ne soient générés dans les modèles, il faut les échapper comme ceci : <%== expr %>.

En tant que développeur, il est important non seulement de rechercher les vulnérabilités dans le code, mais aussi de comprendre les menaces dans le cadre des bonnes pratiques de sécurité du développement.

Ruby on Rails

Rails est l’une des gems les plus utilisées de tout l’écosystème Ruby. Avec plus de 293 millions de téléchargements au total sur RubyGems, c’est un choix évident et populaire pour le développement d’applications Web.

En effectuant quelques vérifications dans la Snyk Vulnerability Database, j’ai constaté que plusieurs versions étaient à éviter. Toutefois, la version actuelle (6.1.4 au moment de la rédaction) ne présente aucune vulnérabilité connue.

Exécutez gem install rails_,_puis créez un projet Rails vierge en exécutant rails new myapp. Vous obtenez ainsi un nouveau modèle Rails vierge sur lequel créer une application. Après avoir configuré les bibliothèques et les dépendances, j’ai effectué un scan de sécurité avec [snyk test](https://snyk.io/blog/snyk-cli-cheat-sheet/). Le scan a détecté les vulnérabilités suivantes dans le manifeste de paquets.

1Tested 72 dependencies for known issues, found 2 issues, 36 vulnerable paths.
2
3Issues with no direct upgrade or patch:
4  ✗ Information Exposure [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-ACTIONCABLE-20338] in actioncable@6.1.4
5    introduced by rails@6.1.4 > actioncable@6.1.4
6  No upgrade or patch available
7  ✗ Web Cache Poisoning [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-RACK-1061917] in rack@2.2.3
8    introduced by capybara@3.35.3 > rack@2.2.3 and 34 other path(s)
9  No upgrade or patch available

En examinant ces résultats de plus près, je constate que la gem Action Cable, une dépendance de Rails, signale un risque potentiel d’exposition d’informations. Ce problème semble avoir été identifié en 2016, sans qu’aucun correctif n’ait été apporté à la bibliothèque principale du framework. En examinant plus attentivement la PR répertoriée dans la Snyk Vulnerability Database, j’ai trouvé une solution de contournement au niveau du code qui atténue le problème. Elle a été proposée en 2019.

L’autre problème est introduit par la gem Rack et concerne, là encore, l’empoisonnement du cache Web, comme dans le cas de Spree Commerce mentionné plus haut.

Aidez les communautés en contribuant à leurs projets

J’aime toujours mettre les mains dans le code, en particulier pour examiner les vulnérabilités détectées et les comprendre au niveau du code après quelques recherches.

Un scan ne prend que quelques instants et permet de vérifier si les bibliothèques, le code ou les plateformes que vous utilisez présentent des vulnérabilités connues. Vous pouvez ainsi gagner du temps et protéger vos utilisateurs finaux. Un développeur, une équipe ou une entreprise qui utilise ces plateformes en production sans en connaître les risques peut ne pas se rendre compte de ce qu’il laisse entrer. J’espère que cet article aidera certaines équipes à rester en sécurité.

N’oubliez pas non plus que ces communautés font un travail remarquable en créant des bibliothèques que nous pouvons tous utiliser. Il est donc important de contribuer à votre tour lorsque vous le pouvez. Même une aide à la documentation ou aux tests d’une version candidate peut être utile. Je ne suis qu’un développeur et ceci n’est qu’un article. Pour avoir un véritable impact sur la sécurité, je vous encourage à tester vous-même les projets et à contribuer aux correctifs.