Utiliser des librairies ou des frameworks est très pratique. Avec ces composants externes, les développement deviennent plus rapides, l’équipe de développement peut dégager du temps pour d’autres projets, et bénéficie généralement de l’appui d’un communauté active.

Cependant, comme tout logiciel ou portion de code, ces composants externes sont exposés à des attaques web. Pire, plus un composant devient populaire, plus il est sujet aux attaques. Les pirates se concentrent généralement sur des librairies ou frameworks très largement utilisés, afin de lancer des attaques de grande envergure.
Lorsqu’une faille de sécurité est découverte sur un de ces composants, la vulnérabilité devient souvent publique, un patch est développé afin de corriger les failles dans la nouvelle version, qui doit normalement être installée par les développeurs utilisant ces composants externes.

Illustration - Composant vulnérable
Composant vulnérable

Le problème avec ce type de fonctionnement est que les pirates eux aussi attendent les mises à jours, avec les détails des vulnérabilités découvertes, et lancent des attaques dès que possible (en quelques heures ou quelques jours sur des composants critiques).

Ce type de faille de sécurité est classé #9 dans l’OWASP Top 10 2013.

Quels types d’attaques?

Les possibilités de failles sur ces librairies ou frameworks sont infinies, il peut s’agir par exemple de failles d’injection SQL, XSS, failles d’authentification… N’importe quel type de faille peut être présent dans les lignes de code, comme sur toute autre application.

Attaques connues

Certaines attaques ont récemment fait parler d’elles, comme par exemple Heartbleed ou Drupal.

Heartbleed

Cette faille affecte la librairie OpenSSL dans ses versions 1.0.1 à 1.0.1f. Les attaquants peuvent en extraire des données issues de communications cryptées.
Lorsque la faille a été dévoilée, celle-ci a été exploitée largement, compromettant une grosse quantité de données sur de nombreux site.

Vous souhaitez en apprendre plus sur Heartbleed?
http://fr.wikipedia.org/wiki/Heartbleed

Drupal

Une faille de type injection SQL a été récemment découverte sur une version de Drupal, et annoncée par l’équipe sécurité de Drupal.
Les versions jusqu’à 7.31 sont affectées, et les pirates peuvent l’exploiter par exemple pour installer un “backdoor” sur le système. Le plus gros souci avec cette faille est que mettre à jour la version de Drupal sur son système ne permet pas de savoir si le système a été piraté, et si des backdoors ont été installées.

Comment éviter ce type de failles?

La première chose à effectuer est de maintenir une liste des composants tiers utilisés sur une plateforme donnée, et leurs versions.
Cela permettra de plus facilement identifier les composants vulnérables, et l’équipe de développement pourra agir si besoin, en ayant une connaissance précise des éléments utilisés.

Ilustration - Mettre à jour ses librairies
Mettre à jour ses librairies

Ensuite, mettre en place un process visant à surveiller les nouvelles versions disponibles et vulnérabilités connues est important.
En s’inscrivant à des mailing lists projets (celles des librairies ou composants utilisés), à des mailings lists de sécurité, et en consultant les bases de données de vulnérabilités, les développeurs pourront rester à jour et savoir quelle faille les guette.

Par exemple, l’équipe sécurité de Drupal possède un blog que vous pouvez suivre :
https://www.drupal.org/security/psa
Il est également possible de les suivre sur Twitter.
Quelques bases de données CVE (Common Vulnerabilities and Exposures) :
http://cve.mitre.org/
http://nvd.nist.gov/home.cfm
http://www.cvedetails.com/

Ces bases permettent de repérer des versions vulnérables et d’avoir des détails sur les failles.

Désactiver les composants inutilisés est également important. Si une librairie ou composant n’est pas utilisé dans une application web, la supprimer permettra d’éviter d’éventuels problèmes.

Pourquoi les équipes techniques ne gèrent-elle pas ces failles correctement?

Télécharger et installer des librairies, frameworks ou composants est facile, rapide, et permet de gagner du temps.
Mais n’oubliez pas de gérer correctement ces éléments externes, même si cela prend du temps et peut être assez ennuyant.

C’est le prix à payer pour les composants Open Source! (et un coût additionnel pour les composants propriétaires…)

Autres articles dans cette série :