5 vulnérabilités récurrentes dans les applications Delphi. Et pourquoi elles pourraient passer inaperçues pour la sécurité des applis ?

Les vulnérabilités des applications Delphi apparaissent rarement dans le périmètre de surveillance des équipes de sécurité, mais cela ne signifie pas qu’elles n’existent pas. Les systèmes développés en Delphi sont présents dans des opérations critiques au sein des banques, des compagnies d’assurance, des établissements de santé et des entreprises industrielles. Nombre d’entre eux sont en production depuis plus de dix ans. Il s’agit de code stable, éprouvé dans le temps et difficile à remplacer.

Mais « stable » ne signifie pas « sécurisé ».

Le problème réside dans le fait que la majeure partie du marché de l’AppSec — outils SAST, équipes de sécurité et contenus techniques — traite très peu, voire pas du tout, de Delphi. Par ailleurs, les plateformes les plus connues — Fortify, Checkmarx, HCL AppScan et Synopsys Coverity — ne prennent pas en charge ce langage. Par conséquent, les systèmes Delphi restent en dehors du radar de sécurité, non pas parce qu’ils sont moins vulnérables, mais parce que personne ne les analyse.

Dans cet article, nous avons réuni les vulnérabilités les plus couramment rencontrées dans les applications Delphi historiques. Il s’agit des principaux points que toute équipe informatique ou de sécurité devrait examiner avant un audit, une certification de conformité ou, idéalement, avant qu’un incident ne survienne.

Pourquoi ces vulnérabilités passent-elles inaperçues ?

1. Injection SQL par concaténation directe des requêtes

Il s’agit, de loin, de l’une des vulnérabilités les plus courantes dans les anciennes applications Delphi. Les composants d’accès aux données tels que BDE, ADO ou dbExpress ont souvent été implémentés au moyen de requêtes construites par concaténation de chaînes de caractères, sans utilisation de paramètres (Params) ni de requêtes préparées.Cette pratique ouvre la voie à des injections SQL directement depuis les champs de formulaire, en particulier dans les systèmes où la validation des entrées a été mise en œuvre de manière incohérente d’un écran à l’autre.Comment l’identifier : rechercher dans le code les expressions « SQL.Text := » ou « SQL.Add » concaténant directement des variables, sans utilisation de ParamByName.

2. Identifiants et secrets stockés sans protection

Il n’est pas rare de trouver des chaînes de connexion, des mots de passe de bases de données ou des clés d’API directement intégrés au code source, stockés en clair dans des fichiers .ini/.cfg ou même enregistrés dans des propriétés de fichiers .dfm.Cette pratique était courante dans les applications développées avant l’adoption de méthodes modernes de gestion des secrets. Elle représente donc un risque critique dès lors que l’exécutable ou le code source peut être consulté, notamment au moyen de techniques de rétro-ingénierie du fichier binaire.Comment l’identifier : rechercher des chaînes de caractères suspectes — mots de passe, chaînes de connexion et jetons — dans les fichiers sources ainsi que dans les fichiers .dfm, .ini et .reg du projet.

3. Absence de chiffrement des communications réseau

Les applications Delphi utilisant des composants de socket, tels que ceux de la bibliothèque Indy, pour les communications entre clients et serveurs transmettent parfois des données sensibles sans TLS ou au moyen de versions obsolètes de TLS, conservées pour assurer la compatibilité avec d’anciens clients.Cette situation est particulièrement critique dans les systèmes financiers et de santé, où les données des clients circulent souvent entre les postes de travail et les serveurs internes sur la base de l’hypothèse erronée selon laquelle « il s’agit d’un réseau interne, il n’est donc pas nécessaire de chiffrer les échanges ».Comment l’identifier : examiner la configuration des composants TIdTCPClient/TIdTCPServer et vérifier si TIdSSLIOHandlerSocketOpenSSL, ou un composant équivalent, est utilisé avec des versions de protocole à jour.

4. Règles métier et contrôles de sécurité mis en œuvre côté client

Dans de nombreuses applications de bureau Delphi, les règles d’autorisation — qui peut consulter quelles informations ou valider quelles opérations — ont été implémentées dans la couche de présentation, directement dans l’exécutable client, au lieu d’être vérifiées par le serveur ou la base de données.

Cela signifie qu’en théorie, la modification du comportement d’un écran ou l’interception d’un appel peut suffire à contourner une règle métier censée constituer une barrière de sécurité.

Comment l’identifier : cartographier l’emplacement des contrôles de permissions et d’autorisations du système. S’ils sont principalement concentrés côté client, cela doit être considéré comme un signal d’alerte.

5. Composants et bibliothèques tierces obsolètes

De nombreux systèmes Delphi historiques dépendent de composants tiers — DLL, packages VCL ou bibliothèques d’intégration — qui ne sont plus mis à jour depuis plusieurs années. Dans certains cas, cette situation s’explique par le fait que l’éditeur n’existe plus.Cela crée un risque lié à la chaîne d’approvisionnement : les vulnérabilités connues dans les anciennes versions de ces dépendances restent exploitables, même lorsque le code propriétaire de l’entreprise a été correctement développé.Comment l’identifier : la création d’un inventaire des composants, ou d’une nomenclature logicielle (SBOM), constitue la première étape. Sans cet inventaire, il est pratiquement impossible de déterminer quelles dépendances sont obsolètes ou compromises.

6. Absence de tests de sécurité automatisés dans le cycle de développement

Il ne s’agit pas à proprement parler d’une vulnérabilité dans le code, mais plutôt de la cause profonde de presque toutes celles présentées précédemment : la plupart des équipes chargées de maintenir des systèmes Delphi ne disposent d’aucun outil SAST exécuté en continu, tout simplement parce que les solutions les plus connues du marché ne prennent pas en charge ce langage.Sans analyse statique récurrente, chacun des problèmes mentionnés ci-dessus ne peut être découvert que manuellement. Cela se produit généralement trop tard, lors d’un test d’intrusion ponctuel, d’un audit de conformité ou, dans le pire des cas, après un incident.

Comment exploiter cette liste

Aucun de ces problèmes ne justifie à lui seul de réécrire intégralement le système. Dans les faits, cette option est rarement réaliste pour les entreprises qui dépendent d’une application Delphi critique en production. L’approche la plus pragmatique consiste à identifier ces vulnérabilités au moyen d’une solution d’analyse statique de la sécurité du code (SAST) compatible avec Delphi, à hiérarchiser les corrections en fonction du niveau de risque réel et, lorsque le code source n’est plus disponible, à recourir à l’analyse binaire.C’est précisément cette lacune que les solutions AppSec traditionnelles ne permettent pas de combler. C’est pourquoi Better Now a introduit DerScanner sur le marché brésilien, l’un des rares outils SAST du marché proposant une prise en charge native de Delphi parmi 43 langages compatibles, ainsi qu’une fonctionnalité d’analyse binaire pour les situations dans lesquelles le code source n’est plus disponible.

Si votre entreprise exploite des systèmes Delphi critiques qui n’ont jamais fait l’objet d’une évaluation de sécurité structurée, découvrez notre solution → Better Now & DerScanner