Réflexions sur les problèmes de sécurité de Log4j, ce qu’ils impliquent pour la communauté des développeurs en général, et l’effet spécifique sur les développeurs RAD Studio.
À moins que vous ne viviez sur une île éloignée sans connexion Internet, vous avez certainement entendu parler des problèmes de Log4j qui ont affecté tant d’applications et de services Internet au cours des 10 derniers jours. La découverte fortuite de ce bogue critique dans le contexte des messages de la console Minecraft (taper un message sur le client du jeu Minecraft pourrait permettre à quelqu’un d’exécuter du code sur un serveur Minecraft) en raison de l’utilisation d’une bibliothèque de journalisation Java extrêmement populaire appelée Log4j , a causé chaque Société informatique et toute entreprise utilisant des applications logicielles pour vérifier si le problème affectait le logiciel de l’entreprise, les services hébergés, les sites Web internes et tout autre scénario de cas d’utilisation.
La liste des applications logicielles concernées (il y en a une ici , par exemple) est assez impressionnante, car bien qu’ayant perdu une partie du battage médiatique et de la poussée marketing, Java est et reste l’un des langages les plus populaires au monde, et la JVM l’un des plus populaires. environnements d’exécution populaires.
Code natif RAD Studio et aucune dépendance Java
Maintenant, qu’est-ce que cela signifie pour Embarcadero en général et RAD Studio en particulier ? Directement, pas grand-chose. Les logiciels construits en Delphi ou C++Builder n’utilisent ni ne reposent en aucune façon sur Java (à l’exception des applications Android) et n’utilisent donc pas Log4j. Plus généralement, Delphi et C++Builder créent des applications compilées nativement, moins sujettes aux problèmes d’environnement d’exécution (je fais ici référence aux environnements d’exécution Java, .NET ou JavaScript). Cependant, dans ce cas, le problème n’était pas dans l’environnement d’exécution, mais dans une bibliothèque populaire, et les développeurs de RAD Studio utilisent des composants complémentaires et des bibliothèques tierces, comme toute autre communauté de développeurs.
Permettez-moi de clarifier une fois de plus : un serveur Web ou un service Web construit dans Delphi ou C++Builder (ou C++ en général) n’est pas affecté par le problème Log4j. Il en va de même, bien sûr, pour les applications Web construites en ASP.NET, Python ou PHP. Le problème est spécifique aux logiciels écrits en Java – et il existe de nombreux logiciels Java, comme indiqué ci-dessus.
Pour en revenir à Delphi et C++Builder, avoir du code compilé aide à la sécurité, mais ce n’est pas suffisant. Il est également important de ne choisir que des bibliothèques et des composants auxquels vous pouvez faire entièrement confiance (au minimum, nécessitant l’inclusion du code source). De plus, il est également important pour un développeur d’écrire du code avec un accent particulier sur la sécurité. Comme mentionné la semaine dernière, le codage par copier-coller (bien qu’il ne soit pas directement responsable du problème de Log4j) est un style de codage à l’opposé de l’écriture d’applications sécurisées.
Contribuer à l’Open Source
Il y a aussi un autre problème clé que les problèmes de Log4j ont rendu évident : il existe des projets de plusieurs millions de dollars gérés par de grandes entreprises qui s’appuient sur des projets open source sans financement, gérés par des développeurs pendant leur temps libre (en dehors de leur travail régulier). L’idée que vous pouvez utiliser l’open source pour réduire les coûts sans contribuer en temps, en ressources ou en argent aux projets que vous exploitez devient un énorme problème dans l’industrie.
C’est également vrai pour l’écosystème Delphi et C++Builder : Embarcadero a commencé à financer et à faire des dons à quelques bibliothèques open source, mais nous devrions faire plus. Nous encourageons également toutes les applications métier qui exploitent de manière significative les bibliothèques et les outils Delphi open source à y contribuer, y compris par le biais d’évaluations de sécurité !
Combien de projets open-source utilisez-vous pour vos applications professionnelles et à quand remonte la dernière fois que vous avez fait un don à l’un d’entre eux ?
La sécurité a plusieurs facettes
La sécurité est un continuum nécessitant plusieurs angles et chacun des éléments ci-dessous peut aider :
- Applications compilées nativement
- Aucune dépendance à un environnement d’exécution d’exécution
- Utilisation de bibliothèques et de composants tiers approuvés et approuvés
- S’engager à contribuer aux projets open source dont vous tirez parti
- Focus sur la sécurité lors de l’écriture de code (pas de codage par copier-coller)
- Outils pour vérifier le code source d’une application
- Stockage sécurisé du code source (pour éviter l’injection de code source)
- Environnement de construction sécurisé (pour éviter l’injection de code binaire)
- Signature de l’exécutable de l’application
Bien qu’elle ne soit pas exhaustive et qu’elle privilégie le code compilé (nous pensons vraiment que c’est important), nous espérons que cette liste et la réaction globale à l’incident Log4j pourront vous aider, vous et votre organisation, à repenser la sécurité et à ajouter plus de valeur au rôle des développeurs – qui sont la pierre angulaire de tout scénario de développement sécurisé.
Bon codage avec votre RAD Studio sans Log4j 😉
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition