Les composants tierces parties (composants tiers) jouent un rôle souvent central dans les applications web. Librairies, frameworks et composants système sont utilisés sur la grande majorité des sites web et des applications métiers.
En effet, l’utilisation des composants tiers permet de réduire les coûts et de faciliter les développements.

Mais quel est l’impact en termes de sécurité ?

Qu’est qu’un composant tiers ?

Un composant tiers est un code ou logiciel qui peut être réutilisé et qui est développé par une autre entité. Il peut s’agir d’un composant open-source, ou d’un composant commercial. Nous pouvons trouver différentes catégories de composants tiers, comme par exemple :

  • Composants système (ex : OpenSSL)
  • Serveurs web (ex : Apache httpd, Nginx, IIS, Tomcat…)
  • Moteurs d’exécution, interpréteurs, environnements back-end (ex : .net, Java, PHP, Ruby, Python…)
  • Frameworks (ex : Symfony, CakePHP, .Net, Spring, GWT, Rails…)
  • Librairies (ex : Assetic, Validation, jQuery, JUnit, Lucene, PDFSharp…)

Quels sont les principaux risques liés aux composants tiers ?

Les utilisateurs ne sont généralement pas au courant de la mise à disposition de mises à jour. Certains composants vulnérables peuvent ainsi rester sur un serveur de production pendant des semaines, voire des mois ou des années.
Pour être au courant de la disponibilité des mises à jour, il faut une approche proactive. Hélas, en téléchargeant et installant un composant, les développeurs ne sont pas systématiquement inscrits à un système de notification des mises à jour de sécurité.

De plus, appliquer les mises à jour suppose du temps et du budget, pour les nécessaires validations fonctionnelles, techniques et les déploiements vers les serveurs de production.

Failing third party component, gear - illustration

Le turnover dans les équipes techniques et le manque de documentation n’arrange pas le sort de ces composants tiers, qui ont tendance à vieillir et à périmer rapidement dans les applications web.

En conséquence, les applications web qui utilisent ces composants tiers et profite des avantages de l’open-source héritent également de failles de sécurité plus ou moins dangereuses.
La nature exacte de ces vulnérabilités et l’impact concret dépend du composant affecté, de la façon dont il est intégré à l’application et du contexte métier.

Exemples de failles de sécurité liées aux composants tiers

jQuery DOM XSS, via le sélecteur #

Certaines vieilles version de jQuery sont vulnérables à des attaques de type XSS – https://www.cvedetails.com/cve/CVE-2011-4969/
Le lien suivant liste les versions de la librairie affectées par cette faille : http://domstorm.skepticfx.com/modules?id=53990c76fd987e64ab000002

ExtJS

Comme de nombreuses autres librairies, ExtJS a été livré à un certain moment avec des vulnérabilités.
La CVE détaillée sur cette page (http://www.cvedetails.com/cve/CVE-2007-2285/) nous donne des indications sur une vulnérabilité qui affecte les fichiers d’exemples fournis avec la librairie.

En exploitant la vulnérabilité et sous certaines conditions, il est possible d’accéder à tous les fichiers présents sur le système (comme /etc/passwd, ou au code source d’une application hébergée sur le serveur).

Conseils de sécurité au sujet de l’utilisation de composants tiers

Nous vous conseillons fortement de mettre en place des processus afin de maximiser votre contrôle sur le code tiers. Traquer quels composants sont téléchargés, incorporés dans les projets, mais également lesquels d’entre eux nécessitent des mises à jour ou doivent être supprimés.

Cela requiert à la fois des process et des outils, avec des responsabilités clairement définies au sein des équipes de développement. Voici une proposition d’organisation visant à maîtriser le flux de code externe et à réduire la probabilité que des vulnérabilités tierces se retrouvent dans vos applications en production :

Quatre objectifs : Cataloguer, Analyser, Contrôler et Monitorer.
Chaque objectif comprend différentes actions (process).

  • Cataloguer
    • Identifier les composants utilisés dans les projets
    • Maintenir un catalogue central des composants
  • Analyser
    • Détecter les vulnérabilités dans les composants
    • Se séparer des composants inutilisés (par projet)
  • Contrôler
    • Créer un dépôt (repository) central de composants
    • Etablir une politique globale de gestion des composants
    • Contrôler les projets lors de la sortie de nouvelles versions
  • Monitorer
    • Détecter les mises à jour de composants tiers
    • Mettre les composants non maintenus sur liste noire

L’objectif global est de mettre en place un suivi complet des composants utilisés dans vos projets, depuis la sélection initiale du composant, jusqu’à la planification de son retrait.

Plusieurs solutions sont disponibles afin de gérer ces composants tiers, et peuvent être séparés en deux catégories : manuelles et automatisées, avec bien entendu des solutions intermédiaires mixant les deux approches.
Si vous partez de zéro sur ce sujet, mettre en place ces process est un bon investissement qui vous permettra de faire une grande avancée.

Automatiser

Il existe différentes solutions sur le marché afin d’automatiser et de renforcer ces contrôles.
Certains de ces outils sont open-source, d’autres sont commerciaux. Certains sont limités à un certain type de composants tiers, d’autres incluent des vérifications et contrôles complémentaires tels que les licences.

Nous passerons en revue ces différentes solutions dans un de nos prochains articles. Stay tuned!