Les applications PowerBuilder sont orientées base de données et traitent de grands volumes de données métier critiques, ce qui en fait des cibles de choix pour les attaquants. Les vulnérabilités de sécurité dans le code PowerBuilder passent souvent inaperçues pendant des années, accumulées silencieusement au fil des cycles de maintenance, des intégrations tierces et des pratiques héritées d'époques de développement antérieures.
Visual Expert traite la sécurité du code PowerBuilder à plusieurs niveaux grâce aux tests de sécurité des applications statiques (SAST) :
- Détecte les vulnérabilités de sécurité dans le code PowerBuilder - identifiants codés en dur, failles d'injection, cryptographie non sécurisée, et bien plus encore.
- Réduit la surface d'attaque en identifiant le code mort, dupliqué et obsolète qui augmente inutilement l'exposition.
- Signale les mauvaises pratiques qui dégradent les performances ou facilitent les attaques par déni de service (DoS).
- Propose des correctifs concrets pour chaque problème identifié.
- Couvre à la fois le client PowerBuilder et tout code de base de données Oracle ou SQL Server connecté dans une seule analyse.
Les équipes qui planifient un effort de remédiation structuré peuvent trouver une approche de séquençage complète — couvrant le code, le déploiement, le contrôle d'accès et la préparation aux audits dans le guide pour sécuriser les applications PowerBuilder.
Catégories de vulnérabilités de sécurité PowerBuilder
Les plus de 300 règles d'inspection de Visual Expert couvrent cinq catégories distinctes de vulnérabilités de sécurité PowerBuilder.
Les sections ci-dessous détaillent les règles les plus critiques de chaque catégorie.
- Identifiants codés en dur et données sensibles
- Faiblesses de chiffrement et de cryptographie
- Failles d'injection et de validation des entrées
- Composants obsolètes et hérités
- Contrôle d'accès et exposition du code
Identifiants codés en dur et données sensibles
Les secrets codés en dur figurent parmi les vulnérabilités de sécurité PowerBuilder les plus courantes et les plus dangereuses. Ils persistent silencieusement dans les exécutables compilés, où des outils de décompilation peuvent les exposer. Toute violation du binaire — physique ou à distance — devient une fuite d'identifiants.
- Les identifiants et mots de passe ne doivent pas être codés en dur
Le codage en dur d'informations sensibles, telles que les noms d'utilisateur ou les mots de passe, les adresses IP et les clés de chiffrement, peut les exposer aux pirates. Toute personne accédant aux fichiers exécutables peut les décompiler et trouver ces informations sensibles. La divulgation de données protégées par des réglementations officielles telles que le RGPD, SOX ou HIPAA peut entraîner de graves conséquences juridiques.
Visual Expert recherche les identifiants et mots de passe codés en dur afin de vous permettre de supprimer ces failles de sécurité. - Les clés de chiffrement ne doivent pas être codées en dur
La règle de code PowerBuilder « Les clés de chiffrement ne doivent pas être codées en dur » stipule que toute clé de chiffrement utilisée dans le code PowerBuilder ne doit pas être stockée en texte clair dans le code. Les clés de chiffrement doivent plutôt être stockées dans un emplacement sécurisé en dehors du code et référencées depuis cet emplacement. Cela garantit que les clés de chiffrement restent sécurisées et ne sont pas exposées aux attaquants potentiels qui pourraient accéder au code. Cela facilite également la gestion des clés en cas de besoin de modification ou de mise à jour. - Les adresses IP ne doivent pas être codées en dur
Le codage en dur d'informations sensibles telles que les adresses IP, les clés de chiffrement ou les codes d'accès peut les exposer aux pirates. Si quelqu'un peut accéder à vos fichiers d'exécution, il peut les décompiler et exposer ces informations. La divulgation d'informations protégées par des réglementations officielles telles que le RGPD, SOX ou HIPAA peut entraîner de graves conséquences juridiques.
Visual Expert recherche toute adresse IP codée en dur pour vous permettre de supprimer cette faille de sécurité. - Ne jamais utiliser la journalisation console en production
La journalisation console est une méthode permettant de suivre discrètement le comportement du code et d'avertir en cas de problème. Elle doit être désactivée en production, car elle pourrait exposer des données sensibles et révéler des informations sur le fonctionnement interne de votre application. Visual Expert détecte ces problèmes dans votre code PowerBuilder pour vous aider à les désactiver avant la mise en production.
Faiblesses de chiffrement et de cryptographie
Un chiffrement faible ou mal configuré est l'une des catégories de vulnérabilités de sécurité PowerBuilder les plus techniquement subtiles. Une application peut sembler utiliser le chiffrement tout en restant pratiquement non protégée si les algorithmes, les modes ou les longueurs de clés sont incorrects.
- Toujours utiliser l'algorithme de chiffrement AES dans un mode sécurisé
AES propose plusieurs modes (ECB, CBC, CFB…), certains étant plus rapides ou plus sécurisés que d'autres.
Si vous utilisez AES dans votre code PowerBuilder, vos appels doivent utiliser les modes les plus sécurisés.
Visual Expert analysera votre application, identifiera les appels moins sécurisés et les mettra en évidence dans votre code. - Les algorithmes de chiffrement doivent être utilisés avec le mode sécurisé et le schéma de rembourrage appropriés
Lors de la sécurisation de votre code avec des algorithmes de chiffrement, les modes d'opération et les schémas de rembourrage doivent être utilisés correctement. En fonction de l'algorithme de chiffrement utilisé, Visual Expert déterminera les valeurs de rembourrage et de mode appropriées, et vérifiera qu'elles sont correctement utilisées dans votre code PowerBuilder. - Les clés de chiffrement doivent être suffisamment longues
Pour rendre les clés cryptographiques robustes contre les attaques par force brute, elles doivent avoir une taille de clé suffisante. Visual Expert vous indiquera si des clés non robustes sont utilisées dans votre code PowerBuilder. - DES (Data Encryption Standard) ou 3DES ne doit pas être utilisé
Le Data Encryption Standard (DES) est un algorithme à clé symétrique pour le chiffrement des données numériques.
Sa courte longueur de clé de 56 bits le rend non sécurisé. Il ne doit plus être utilisé.
Visual Expert identifiera tous les appels DES dans votre code PowerBuilder afin que vous puissiez les supprimer. - Les fonctions de hachage cryptographique ne doivent pas utiliser SHA-1 ou les algorithmes Message-Digest
Les algorithmes SHA-1 et Message-Digest : MD2, MD4, MD5 et MD6 ne sont plus considérés comme sécurisés. Visual Expert vérifiera si de tels algorithmes sont utilisés dans votre code PowerBuilder et localisera les appels correspondants, afin de vous aider à les remplacer par des alternatives plus sécurisées.
Failles d'injection et de validation des entrées
Les applications PowerBuilder sont, par nature, orientées base de données — ce qui fait de l'injection SQL l'une des catégories de vulnérabilités de sécurité PowerBuilder les plus conséquentes. Les entrées utilisateur non validées qui atteignent les requêtes de base de données ou les commandes système peuvent permettre à des attaquants de lire, modifier ou détruire des données, ou d'exécuter des opérations non autorisées sur le système sous-jacent.
- Les requêtes de base de données ne doivent pas être vulnérables aux attaques par injection
L'injection de code est une attaque qui consiste à injecter du code malveillant qui sera interprété/exécuté par l'application. En particulier, l'injection de code SQL permet d'effectuer des opérations illégales dans votre base de données (accès à des données sensibles, prise de contrôle ou arrêt du serveur…).
Par nature, les applications PowerBuilder sont orientées base de données et critiques pour l'entreprise.
Elles traitent de grands volumes de données importantes, ce qui en fait des cibles de premier choix pour les pirates.
Par exemple, Visual Expert recherche les concaténations de chaînes utilisées pour construire des requêtes SQL, qui ne sont pas correctement validées ou échappées. Elles peuvent créer des failles importantes pour l'injection SQL. Identifier et refactoriser ces requêtes renforcera la protection de votre base de données. En savoir plus : Comment protéger les applications PowerBuilder contre les attaques par injection de code. - Les entrées utilisateur ne doivent pas permettre les attaques par injection ou traversée de chemin
Les données saisies par les utilisateurs, telles que les paramètres d'URL ou les cookies, doivent être considérées comme suspectes. Si votre code génère dynamiquement un chemin de système de fichiers à partir de ces données, un pirate pourrait injecter des valeurs spécifiques telles que « ../ » et modifier le chemin initialement prévu.
Ces attaques sont souvent appelées « traversée de chemin » ou « traversée de répertoire ». Elles permettent à l'attaquant d'accéder à des répertoires interdits pour lire, modifier ou supprimer des données sensibles, ou exécuter des commandes du système d'exploitation.
Visual Expert identifiera le code introduisant de telles vulnérabilités pour vous permettre de l'assainir. Une stratégie de défense possible consiste à définir une liste blanche de chemins ou de caractères autorisés. - Les commandes OS ne doivent pas permettre les attaques par injection
Si votre code exécute des commandes du système d'exploitation basées sur des entrées utilisateur, il doit vérifier le nom de chaque commande. Sinon, un pirate pourrait injecter ses propres commandes pour effectuer des opérations illégales et compromettre votre système.
Visual Expert détectera ces failles dans votre code PowerBuilder afin que vous puissiez les corriger. Par exemple, vous pouvez définir une liste blanche de commandes sûres et assainir les méta-caractères shell. - Les expressions régulières ne doivent pas permettre les attaques par déni de service
Il est fortement déconseillé de générer des expressions régulières à partir de données utilisateur, car cela peut conduire à un déni de service par expression régulière (ReDoS). Ce type d'attaque exploite la possibilité de ralentir considérablement l'évaluation des expressions régulières en utilisant de manière malveillante des caractères spécifiques. Un attaquant peut induire cette situation lorsqu'un programme utilise une expression régulière et la bloque pendant un temps très long (d'où le déni de service).
Visual Expert localise ces appels dans votre code PowerBuilder, vous permettant de les supprimer ou d'assainir l'entrée en supprimant/neutralisant les méta-caractères des expressions régulières. - Les exceptions génériques ne doivent pas être ignorées
En matière de gestion des exceptions, les blocs CATCH doivent toujours disposer d'un mécanisme de capture approprié. Visual Expert identifie les blocs catch vides pour sécuriser votre code avec une gestion des exceptions significative.
Composants obsolètes et hérités
De nombreuses applications PowerBuilder contiennent encore des composants qui étaient des pratiques standard dans les versions antérieures, mais qui ont depuis été dépréciés ou se sont révélés présenter des risques de sécurité significatifs. Ces composants constituent une source fréquente de vulnérabilités de sécurité PowerBuilder dans les bases de code héritées, notamment parce qu'ils sont difficiles à identifier sans analyse automatisée.
- Les objets SOAP et INET ne doivent pas être utilisés
Les objets PowerBuilder SOAP et INET ne supportent pas l'utilisation de TLS 1.2, ce qui les rend vulnérables aux attaques. - Le navigateur web OLE ne doit plus être utilisé (non sécurisé)
La règle de code PowerBuilder stipule que le navigateur web OLE ne doit plus être utilisé, car il n'est pas sécurisé. En effet, le navigateur web OLE est une technologie obsolète qui n'est plus prise en charge ni mise à jour, et qui est donc vulnérable aux failles de sécurité. Il est recommandé aux développeurs d'utiliser des alternatives plus sécurisées telles que HTML ou JavaScript. - EAServer — plus pris en charge — ne doit pas être utilisé
EAServer n'est plus pris en charge depuis PowerBuilder 2017. L'objet SSLServiceProvider fournit des services SSL/TLS dans les versions plus anciennes de PowerBuilder. Il peut ne pas prendre en charge les protocoles de sécurité modernes, le rendant inadapté aux communications sécurisées contemporaines. L'objet CORBACurrent fait partie du standard CORBA pour les objets distribués. CORBA est obsolète et peu utilisé dans les architectures d'applications modernes. CORBAObject représente des objets distants dans un système CORBA. Son utilisation est déconseillée en raison de problèmes de performances et d'obsolescence. L'objet TransactionServer gère les transactions dans les applications distribuées. Les frameworks modernes offrent des solutions plus robustes et évolutives. - Ne jamais utiliser CoSetProxyBlanket ou CoInitializeSecurity
Les appels aux sous-routines CoSetProxyBlanket, CoInitializeSecurity et CoInitializeSecurityAlias peuvent générer des failles de sécurité. Visual Expert identifiera ces appels dans le code PowerBuilder pour vous aider à les supprimer.
Contrôle d'accès et exposition du code
Ces règles traitent de la façon dont la structure du code peut elle-même créer une exposition en matière de sécurité, via une accessibilité aux champs trop permissive qui permet des modifications de données non intentionnelles depuis l'extérieur d'une classe.
- Les champs ne doivent pas avoir une accessibilité publique
Cette règle stipule que les champs du code PowerBuilder ne doivent pas être rendus publiquement accessibles. Cela signifie qu'ils ne doivent pas être déclarés comme des variables publiques, et doivent plutôt être déclarés comme des variables privées ou protégées. Ceci est important car rendre les champs publiquement accessibles pourrait exposer le code à des risques de sécurité potentiels, car cela permettrait à du code externe d'accéder aux champs et de les modifier sans aucune restriction. Il est également important de s'assurer que les champs ne sont accessibles que par le code appartenant à la même classe, afin de garantir la sécurité du code et de s'assurer qu'il n'est modifié que de la manière prévue.