Sofern Sie nicht auf einer abgelegenen Insel ohne Internetverbindung leben, haben Sie sicherlich von den  Log4j-Problemen gehört  , die in den letzten 10 Tagen so viele Anwendungen und Internetdienste beeinträchtigt haben. Die zufällige Entdeckung dieses kritischen Fehlers im Zusammenhang mit Konsolennachrichten von Minecraft (das Eingeben einer Nachricht auf dem Minecraft-Spielclient könnte dazu führen, dass jemand Code auf einem Minecraft-Server ausführt) aufgrund der Verwendung einer äußerst beliebten Java-Protokollierungsbibliothek  namens Log4j , verursachte jeden einzelnen IT-Unternehmen und jedes Unternehmen, das Softwareanwendungen verwendet, um zu prüfen, ob das Problem die Software des Unternehmens, gehostete Dienste, interne Websites und andere Anwendungsszenarien betrifft.

Die Liste der betroffenen Softwareanwendungen (  hier gibt es zum Beispiel eine) ist ziemlich beeindruckend, denn obwohl sie etwas von dem Hype und dem Marketingschub verloren hat, ist und bleibt Java eine der weltweit beliebtesten Sprachen und die JVM eine der beliebtesten beliebte Laufzeitausführungsumgebungen.

Nativer RAD Studio-Code und keine Java-Abhängigkeit

Was bedeutet das nun für Embarcadero im Allgemeinen und RAD Studio im Besonderen? Direkt nicht viel. Software, die in Delphi oder C++Builder erstellt wurde, verwendet oder verlässt sich in keiner Weise auf Java (mit Ausnahme von Android-Anwendungen) und verwendet daher Log4j nicht. Allgemeiner gesagt erstellen Delphi und C++Builder nativ kompilierte Anwendungen, die weniger anfällig für Ausführungsumgebungsprobleme sind (hier beziehe ich mich auf Java-, .NET- oder JavaScript-Ausführungsumgebungen). In diesem Fall lag das Problem jedoch nicht in der Ausführungsumgebung, sondern in einer beliebten Bibliothek, und RAD Studio-Entwickler verwenden Add-On-Komponenten und Bibliotheken von Drittanbietern, wie es jede andere Entwickler-Community tut.

Lassen Sie mich noch einmal klarstellen: Ein in Delphi oder C++Builder (oder C++ im Allgemeinen) erstellter Webserver oder Webdienst ist von dem Log4j-Problem nicht betroffen. Dasselbe gilt natürlich für Webanwendungen, die in ASP.NET, Python oder PHP erstellt wurden. Das Problem ist spezifisch für in Java geschriebene Software – und es gibt eine Menge Java-Software, wie oben verlinkt.

Zurück zu Delphi und C++Builder, kompilierter Code hilft bei der Sicherheit, aber es reicht nicht aus. Es ist auch wichtig, nur Bibliotheken und Komponenten auszuwählen, denen Sie voll und ganz vertrauen können (wobei zumindest der Quellcode enthalten sein muss). Darüber hinaus ist es für einen Entwickler auch wichtig, Code mit einem besonderen Fokus auf Sicherheit zu schreiben. Wie letzte Woche erwähnt wurde, ist  Copy-and-Paste-Codierung  (obwohl sie nicht direkt für das Log4j-Problem verantwortlich ist) ein Codierungsstil auf der anderen Seite des Schreibens sicherer Anwendungen.

Zurück zu Open Source beitragen

Es gibt noch ein weiteres Schlüsselproblem, das die Log4j-Probleme deutlich gemacht haben: Es gibt Multi-Millionen-Dollar-Projekte, die von großen Unternehmen verwaltet werden, die auf Open-Source-Projekte ohne Finanzierung angewiesen sind, die von Entwicklern in ihrer Freizeit (außerhalb ihrer regulären Jobs) verwaltet werden. Die Idee, dass Sie Open Source verwenden können, um Kosten zu sparen, ohne Zeit, Ressourcen oder Geld für die von Ihnen genutzten Projekte zurückzugeben, entwickelt sich zu einem großen Problem in der Branche.

Dies gilt auch für das Delphi- und C++Builder-Ökosystem: Embarcadero hat damit begonnen, einige Open-Source-Bibliotheken zu finanzieren und zu spenden, aber wir sollten mehr tun. Wir ermutigen auch alle Geschäftsanwendungen, die Open-Source-Delphi-Bibliotheken und -Tools erheblich nutzen, dazu beizutragen – auch durch Sicherheitsbewertungen!

Wie viele Open-Source-Projekte nutzen Sie für Ihre professionellen Anwendungen und wann haben Sie das letzte Mal für eines davon gespendet?

Sicherheit hat viele Facetten

Sicherheit ist ein Kontinuum, das mehrere Blickwinkel erfordert, und jeder der folgenden Punkte kann helfen:

• Nativ kompilierte Anwendungen
• Keine Abhängigkeit von einer Laufzeit-Ausführungsumgebung
• Verwendung geprüfter und vertrauenswürdiger Bibliotheken und Komponenten von Drittanbietern
• Sich verpflichten, einen Beitrag zu Open-Source-Projekten zu leisten, die Sie nutzen
• Sicherheitsfokus beim Schreiben von Code (keine Copy-and-Paste-Codierung)
• Tools zum Verifizieren des Quellcodes einer Anwendung
• Sichere Speicherung des Quellcodes (um Quellcodeinjektion zu vermeiden)
• Sichere Build-Umgebung (um Binärcode-Injektion zu vermeiden)
• Signieren der ausführbaren Anwendung

Wir hoffen, dass diese Liste und die allgemeine Reaktion auf den Log4j-Vorfall Ihnen und Ihrer Organisation dabei helfen können, Sicherheit zu überdenken und der Rolle der Entwickler mehr Wert zu verleihen – auch wenn sie nicht umfassend ist und eine Tendenz zu kompiliertem Code aufweist (wir glauben wirklich, dass dies wichtig ist). die der Eckpfeiler jedes sicheren Entwicklungsszenarios sind.

Viel Spaß beim Programmieren mit Ihrem Log4j-freien RAD Studio 😉