par Marco Cantù
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 isolée sans connexion Internet, vous avez certainement entendu parler de la Problèmes liés à Log4j qui a affecté un grand nombre d'applications et de services internet au cours des dix derniers jours. La découverte fortuite de ce bogue critique dans le contexte des messages de la console Minecraft (la saisie d'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é Log4jEn raison de ce problème, toutes les sociétés informatiques et toutes les entreprises utilisant des applications logicielles ont dû vérifier si le problème affectait les logiciels, les services hébergés, les sites web internes et tout autre scénario d'utilisation de l'entreprise.
La liste des applications logicielles concernées (il y a un icipar exemple) est assez impressionnant, car même s'il a perdu un peu de sa popularité et de sa force marketing, Java est et reste l'un des langages les plus populaires au monde, et la JVM l'un des environnements d'exécution les plus populaires.
RAD Studio Code natif et pas de dépendance Java
Qu'est-ce que cela signifie pour le Embarcadero en général et le RAD Studio en particulier ? Directement, pas grand-chose. Software construit en Delphi ou C++Builder n'utilise pas ou ne dépend pas de Java (à l'exception des applications Android) et n'utilise donc pas Log4j. Plus généralement, Delphi et C++Builder créent des applications compilées nativement, qui sont 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 ne concernait pas l'environnement d'exécution, mais une bibliothèque populaire, et les développeurs RAD Studio utilisent des composants complémentaires et des bibliothèques tierces, comme le fait toute autre communauté de développeurs.
Permettez-moi de clarifier encore une fois : Un serveur ou un service web construit en Delphi ou C++Builder (ou C++ en général) n'est pas concerné 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 y a beaucoup de logiciels Java, comme indiqué ci-dessus.
Pour en revenir à Delphi et C++Builder, le fait de disposer d'un code compilé contribue à la sécurité, mais 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 (en exigeant au minimum que le code source soit inclus). En outre, il est également important pour un développeur d'écrire du code en mettant l'accent sur la sécurité. Comme nous l'avons mentionné la semaine dernière, codage par copier-coller (bien qu'il ne soit pas directement responsable du problème Log4j) est un style de codage à l'opposé de l'écriture d'applications sécurisées.
Contribuer à l'Open Source
Il y a également un autre problème clé que les problèmes de Log4j ont mis en évidence : il y a 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 qu'il est possible d'utiliser des logiciels libres pour réduire les coûts sans consacrer du temps, des ressources ou de l'argent aux projets sur lesquels on s'appuie est en train de devenir un énorme problème dans l'industrie.
Cela vaut également 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 professionnelles qui exploitent de manière significative les bibliothèques et outils Delphi à source ouverte à y contribuer, y compris par le biais d'évaluations de sécurité !
Combien de projets open-source utilisez-vous pour vos applications professional et quand avez-vous fait un don à l'un d'entre eux pour la dernière fois ?
La sécurité a de multiples facettes
La sécurité est un continuum qui nécessite de multiples angles d'approche et chacun des éléments ci-dessous peut s'avérer utile :
- Applications compilées nativement
- Pas de dépendance à l'égard d'un environnement d'exécution
- Utilisation de bibliothèques et de composants tiers approuvés et fiables
- S'engager à contribuer aux projets open-source que vous exploitez
- Accent mis sur la sécurité lors de l'écriture du code (pas de codage par copier-coller)
- Outil de vérification du 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 générale à l'incident Log4j vous aideront, vous et votre organisation, à repenser la sécurité et à valoriser le 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 😉
